On Fri, Oct 09, 2009 at 12:13:38PM +0200, Marc Haber wrote: > On Thu, Sep 24, 2009 at 06:15:43PM -0400, Theodore Tso wrote: > > On Thu, Sep 24, 2009 at 12:25:00PM +0200, Marc Haber wrote: > > > I think that this timestamp check is too picky and should be removed > > > completely or relaxed in a way that it does only return a non-zero > > > exit code if the difference is more than could be explained by a > > > timezone issue. > > > > There is an easy fix for this, which used to be installed by default > > on Ubuntu (but not on Debian systems, where this hasn't been a > > problem). This was an automatic installation of the following in > > /etc/e2fsck.conf: > > > > [options] > > buggy_init_scripts = 1 > > I have set this now after the issue happening to me after a _CLEAN_ > shutdown of the system.
I'm starting to think more is going on here than 'buggy init scripts'. I have not set the above, as it's not the default and I don't think it's appropriate to have a broken bootup for the entire western hemisphere; so if this indeed is a case of broken init scritps, I wanted to find out what the real bug was, and fix it. Yesterday, my laptop ran out of power again. I was on the train, and had no power socket at hand. Usually when this happens, when I get home I immediately connect the machine to power and let it boot, so I can finish whatever I was trying to do, and/or redo the things I lost (as they'll be fresh in memory still). Yesterday, however, this did no happen, as I was on the last train home, it had been a busy day, and I was just idling a bit on the laptop, so when I got home I went straight to bed instead. This morning, when booting up the laptop, this bug was hit again. This was unexpected, since it had been over a night, and the difference between UTC and local time is only two hours. When inspecting the timings that were shown, an approximately two-hour difference was shown, again. As a result, I'm guessing that something like the following is happening: - The system boots, and does a jounal replay of the root filesystem - This replay process updates the last write time. The clock has not been set yet, so an incorrect timestamp is written. - The clock is set as part of /etc/init.d/hwclockfirst.sh, which is started before the checkroot.sh initscript - Then, checkroot.sh calls e2fsck, which finds a date that is in the future, and complains. If the above is accurate, then I call a bug in the kernel. It is correct for e2fsck to expect the clock to be set correctly when it is being called; otherwise, this would generate an unexpected inconsistency every time the system is booted when the time since last boot is shorter than the difference between local time and UTC time. On the other hand, it is not correct for the system to expect a clock to be accurate at root filesystem mount time -- otherwise non-initrd installs could not possibly work reliably, because that is where the clock would then have to be set. Please advise. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
signature.asc
Description: Digital signature
