Comment 13 for bug 373409

On Thu, Jul 16, 2009 at 10:28:17AM -0000, Scott James Remnant wrote:
>
> On Wed, 2009-07-15 at 17:58 +0000, Endolith wrote:
> > Here's what I get from this command:
> >
> > /m/E/newbackup> dumpe2fs -h Jimage
> >
> >
> > ** Attachment added: "dumpe2fs.txt"
> > http://launchpadlibrarian.net/29080242/dumpe2fs.txt
> >
> Thanks - any help Ted?

Yep, it looks like Ubuntu still needs "buggy init scripts", at least
on whatever system was run on.

Last mount time: Tue Jun 16 21:53:18 2009
Last write time: Tue Jun 16 19:54:51 2009
Mount count: 0
Maximum mount count: 33
Last checked: Tue Jun 16 19:54:51 2009
Check interval: 15552000 (6 months)
Next check after: Sun Dec 13 18:54:51 2009

The problem is the mount time is in the future; this is because of
Ubuntu's, well, buggy init scripts, which has the system clock set to
the hardware clock, which was ticking localtime, as if it were GMT.
This bug is especially bad for people living west of GMT, since the
system clock is temporarily ticking in the future. Proper init
scripts need to inform the system about the timezone (which is why the
Ubuntu installer needs to _set_ the timezone correctly) which can warp
the system clock to the correct time, ***before** e2fsck is run on the
root filesystem, and ***before*** the root filesystem is remounted.

This is why the last mount time is set in the future; because of
Ubuntu's buggy init scripts. (Or at least, they were buggy at the
time this filesystem was in use.) This problem tends not be noticed
in places east of GMT (i.e., in the US) since even with buggy init
scripts, the system clock error is in the opposite directory, so time
is ticking in the past when the root filesystem is mounted, and this
doesn't cause the problem. People who have their system clock tick
GMT (i.e. real Unix/Liunx time), instead of the localtime abomination
promoted by Windows (especially since the CMOS doesn't store the local
time zone, so there's no way of interpreting the hardware clock time,
and no way of knowing if the Daylight Savings Time / Summer Time
adjustment has been made), also don't have this problem.
Unfortunately, at least historically, Ubuntu was decided it was better
to follow Window's mistakes. :-(

Anyway, looking at this some more, I think the real problem is that
the "buggy init scripts" boolean not only suppressed the full check,
but it also suppressed e2fsck fixing the problem of the mount time
being in the future. This is what is causing resize2fs to constantly
complain about mount time being in the future. So what we need to do
is to change e2fsck to fix the problem, but not force a full check if
buggy_init_scripts is set.

Also, depending on what Ubuntu distribution was use for this
filesystem image, I might not be so quick to assume that Ubuntu really
has fixed all of the aspects of the the buggy init scripts. But I
suppose we'll know soon enough; if it hasn't been fixed, we'll get
tons of complaints from people in Western Europe, and hopefully this
time someone else will get to field the abuse from confused, clueless
Windows users. (I was really tired last time of people complaining
about e2fsck bugs last time in Launchpad, when it was completely not
in my control to fix the !$%#@! misdesigns in Ubuntu.)

Note, though, that if you really want to make sure this bug is fixed,
you might want to adjust the postinstall script to explicitly edit the
/etc/e2fsck.conf file to turn off buggy_init_scripts, and not just
avoid shipping the file. And it might be a good idea to explicitly
try configuring an Ubuntu machine to be in Central European Time, with
the hardware clock ticking local time, and then try rebooting the
machine a few times to make sure it really has been fixed.

                                 - Ted