fsck halts bootup when checked file has timestamp in the future from other Ubuntu installation

At a guess, your Jaunty and Karmic installations disagree about whether the hardware clock should be to tick localtime or UTC time, and one of the things the shutdown scripts do is to set the hardware clock from the system clock. This causes the time at boot up to be incorrect until NTP has a chance to correct things.

This isn't an e2fsprogs bugs, but rather a system configuration error.

I acknowledge that, however I don't think it's a reasonable assumption for e2fsprogs to assume the system booting has the correct time in that way -- failing to bootup and dumping the user to a recovery terminal from the automatic check is probably the worst thing to do here.

There's an easy fix....

Put the following in /etc/e2fsck.conf

[options]
 buggy_init_scripts = 1

This used to be the default for Ubuntu systems, partially because Ubuntu's init scripts *were* buggy, way back when, but partially also because Ubuntu users don't seem to care about making sure their systems are appropriately set up, and they are much more likely to what to have their hardware clocks tick localtime (with all of the daylight savings time / summer time problems inherent in it) due a desire to be bug-for-bug compatible with Windows. I dropped this in because I was sick and tired of having Ubuntu users complain about this problem, when literally *no* *other* *distribution* seems to have issues with this except Ubuntu.

Scott Remnant decided to remove this in Karmic, although my upstream sources explicitly tests for the Ubuntu distribution and drops this in. (funny thing; Debian users don't complain about this) You'll have to take this up with Scott.

 status incomplete

On Tue, 2009-09-01 at 22:07 +0000, Theodore Ts'o wrote:

> At a guess, your Jaunty and Karmic installations disagree about whether
> the hardware clock should be to tick localtime or UTC time, and one of
> the things the shutdown scripts do is to set the hardware clock from the
> system clock. This causes the time at boot up to be incorrect until
> NTP has a chance to correct things.
>
Indeed, this is the most likely explanation.

Can you supply the contents of "grep UTC /etc/default/rcS" from your
jaunty and karmic installations.

Scott
--
Scott James Remnant
<email address hidden>

Jaunty: $ grep UTC /etc/default/rcS
UTC=no

Karmic: $ grep UTC etc/default/rcS
UTC=yes

Thanks.

That's a clear configuration issue.

You're dual-booting between two systems that are storing different values in the hardware clock, and expecting to find different values there.

It's no different to having UTC=yes and dual booting between Linux and Windows, the hardware clock will go all over the place. You're just compounding it by mounting the same filesystems in both, so not only is the hardware clock getting screwed, so is the filesystem.

Set UTC= to the same value on both systems.

Should it worry us that I don't remember ever actually set this manually myself?

On Wed, 2009-09-02 at 15:48 +0000, Scott Ritchie wrote:

> Should it worry us that I don't remember ever actually set this manually
> myself?
>
Did you originally dual-boot with Windows?

Scott
--
Scott James Remnant
<email address hidden>

I received my laptop with a windows installation on its first hard disk. I installed Jaunty on the second disk and never booted into Windows on the first, so I guess it was dual boot of sorts (albeit entirely different disks/filesystems)

When I later installed Karmic I wiped the Windows disk to install it on top of.

Right, this looks like a karmic installer bug ;)

I suspect Colin already fixed this and will mark this as a dup of another bug

>Right, this looks like a karmic installer bug ;)
I guess so: I've made a fresh install from karmic alpha 5 amd64 on a computer, and almost each time I boot I get the "timestamp in the future" error. I'm not dual booting with anything.

I am also getting this on my karmic upgrade from jaunty. I am running with UTC=yes in my rcS. The problem in my case seems to arise from the fact that the init scripts do not restore the system clock from the hardware clock before launching into fsck.

I had to put the following into my /etc/init/mountall.conf
pre-start script
    /sbin/hwclock -s
end script

However, that is a kludge, as mountall should really depend on getting the hwclock read and the system clock updated through the regular hwclock.sh script

When the hardware clock is stored in UTC, the issue is of particular visibility to those living in GMT-hh timezones and whose system clocks "go back" in time on every boot until they're re-adjusted from the hardware clock.

This issue has definitely been fixed.

If you are still seeing issues with the hardware or system clock, you do not have *this* bug. You should file a new bug, so we can triage your problems independently

Thanks