[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[tytso@MIT.EDU: Re: Bug#343662: fsck errors halting boot after upgrade]

Fixing this the right way will require changing when Debian boot
scripts run hwclock (as the first very thing), and will require making
changes to util-linux, the installer (so that /etc/zoneinfo is not a
symlink, and so that the information about what the local timezone is
stored somewhere else other than the symlink), and libc (so that
/etc/zoneinfo can be refreshed as part of the postinstall package).

This is messy, but it's what Red Hat does, and fixes the bug reported
below.  It really is bad that the system clock is wrong for a large
part of the initial boot process (until possibly after
/etc/rcS.d/S50hwclock.sh is run, if /usr is a separately mounted
filesystem).  I can't see another way of fixing this, though; before I
start lobbying the maintainers of the above-mentioned packages, does
anyone have any suggestions about a better way to deal with this
issue?

Thanks, regards,

					- Ted
--- Begin Message --- 
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

--- End Message ---
Reply to: