On Fri, Dec 16, 2005 at 04:16:42PM -0800, Andrew Sackville-West wrote:
> Package: e2fsprogs
> Version: 1.39
>
> This is specifically version 1.39 WIP (10-Dec-2005)
>
> /dev/hda3: Superblock last mount time is in the future
> /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
>
Are you using your system with hardware time set to some non-GMT local
time zone? (i.e. /etc/defaults/rcS has UTC="no")
I didn't test for this case, and so I didn't realize a problem --- the
timezone offset isn't corrected at the time when fsck is run (at least
not on Debian systems) and e2fsck depends on the time being correct.
In the past, we more or less got by with the time being wrong (for
systems who use a non-GMT hardware clock); it meant that the last
checked time was set incorrectly, and inode delete times would also be
set correctly, but the failures were more or less harmless.
Unfortunately, I added this test in order to address problems caused
by the last mount time not being correct (see Debian bug #327580) only
to realize this was a much larger issue.
This isn't an issue on Red Hat systems, because /etc/localtime is not
a symlink (into possibly a not-yet mounted /usr filesystem), and they
make sure the system clock is correct *before* running fsck on the
root filesystem. I personally keep my system clock on UTC, and so
this problem doesn't show up.
I think you can make the problem go away by making /etc/localtime
contain a copy of what it is currently symlinked to in
/usr/share/zoneinfo/<timezone>, and renaming
/etc/rcS.d/S22hwclockfirst.sh to /etc/rcS.d/S09hwclockfirst.sh. This
is obviously not the "proper" fix; since among other things if the
localtime file needs to get updated (for example if the US Congress
changes the definition of daylight savings time), we need a way to
make sure /etc/localtime gets updated when the package gets updated.
But I believe if you were to apply the above as a workaround, it
should address your problem. Fixing this in the more global sense
will require making changes in the overall Debian boot setup, and I'm
going to have to take this up on debain-devel and consult other Debian
developers.
Regards,
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
