As summary says, if hwclock is executed before mounting or checking local filesystems, time change can cause mount failure and automatic fsck failures due to last mount time in future. See URL (Debian bug) and screenshot. The easiest fix would be running /etc/init.d/hwclock AFTER /etc/init.d/fsck. Reproducible: Always
Created attachment 216498 [details] screenshot of the reproduced error inside VirtualBox.
Roy, Can you look into changing this? Thanks, William
the fsck init.d script already has "use clock" in it and it works for me: rc boot logging started at Mon Jan 11 16:41:07 2010 * Setting system clock using the hardware clock [Local Time] ... [ ok ] * Checking local filesystems ... /: clean, 2298043/9035776 files, 15566253/36142233 blocks [ ok ] * Remounting root filesystem read/write ... [ ok ]
oh, you want hwclock to run after fsck. that's wrong ... it was specifically changed to run before because of the clock skew issue.
(In reply to comment #3) > the fsck init.d script already has "use clock" in it and it works for me: > > rc boot logging started at Mon Jan 11 16:41:07 2010 > > * Setting system clock using the hardware clock [Local Time] ... [ ok ] > * Checking local filesystems ... > /: clean, 2298043/9035776 files, 15566253/36142233 blocks > [ ok ] > * Remounting root filesystem read/write ... [ ok ] > This is exactly the unwanted behaviour, because it breaks boot for dumb reasons.
(In reply to comment #4) > oh, you want hwclock to run after fsck. that's wrong ... it was specifically > changed to run before because of the clock skew issue. > Give me a valid technical reason for this apparent oddity.
why dont you try researching the issue instead of making claims you clearly know nothing about. there is plenty of documentation in bugzilla to explain this change. in fact, if you actually read the issues you referenced in Debian, you'd see none of it was because hwclock ran before fsck and they discuss in detail why the clock needs to come first. you've given no info on your system like what version of e2fsprogs or the status of your e2fsck.conf file. Tso mentioned fixing a kernel bug related to remounting r/o, but going by datestamps that's in 2.6.32 or maybe 2.6.33. you're apparently running 2.6.31 (which i only know because your prompt automatically includes the kernel version).
(In reply to comment #7) From a user POV, this only sounds very annoying. Many angry people that don't know anything (and don't want to!) about how things work under the hood just say "it's broken!" and they are right despite any technical explanation. So it's up to me to *try* to figure out what's wrong with limited info. Since I know my users can't provide valid info, I need to figure everything out myself, which is sometimes very frustrating. > > you've given no info on your system like what version of e2fsprogs or the > status of your e2fsck.conf file. Tso mentioned fixing a kernel bug related to > remounting r/o, but going by datestamps that's in 2.6.32 or maybe 2.6.33. > you're apparently running 2.6.31 (which i only know because your prompt > automatically includes the kernel version). e2fsprogs is at 1.41.9 and there's no e2fsck.conf around. I will try to reproduce the issue with 2.6.32 then. vapier, could you please stop being so frustrated for everybody's sake? Bug is open since the 14th, give me time to append more info.
(In reply to comment #7) > why dont you try researching the issue instead of making claims you clearly > know nothing about. there is plenty of documentation in bugzilla to explain > this change. in fact, if you actually read the issues you referenced in > Debian, you'd see none of it was because hwclock ran before fsck and they > discuss in detail why the clock needs to come first. > Why don't you append pointers instead of behaving like me (in your opinion)?
you might get a better response if you didnt go around telling people their changes are dumb and they have no technical grounds re-emerge e2fsprogs to get e2fsck.conf, or simply copy it from e2fsprogs FILESDIR
(In reply to comment #10) > you might get a better response if you didnt go around telling people their > changes are dumb and they have no technical grounds > When on Earth that happened? > re-emerge e2fsprogs to get e2fsck.conf, or simply copy it from e2fsprogs > FILESDIR > Otoh, you should have revision bumped es2fsprogs after this: 24 Sep 2009; Mike Frysinger <vapier@gentoo.org> +files/e2fsck.conf, e2fsprogs-1.41.9.ebuild: Install a default e2fsck.conf #142850. and this: 12 Oct 2009; Mike Frysinger <vapier@gentoo.org> files/e2fsck.conf: Add [options] stanza #142850#36 by Steven Wilson.
try reading your own comments and/or using "search" yes, e2fsprogs should have been revbumped, but you still havent stated whether it makes a difference. if it doesnt, then the revbump is irrelevant.
(In reply to comment #12) > try reading your own comments and/or using "search" I just wrote "dumb reasons" not "stupid devs" nor "I know more than you" nor wrote on cnn.com that you are dumb. This is kinda pathethic, please stop this kindergarden game, you really look like a 12 years old kid in all your replies. Calm down and let me do my part without jumping like a kid with ADHD. > > yes, e2fsprogs should have been revbumped, but you still havent stated whether > it makes a difference. if it doesnt, then the revbump is irrelevant. > Oh, sure I will, don't worry.
Created attachment 216580 [details] screenshot of fsck after updating e2fsprogs Provided e2fsck.conf works, even if I *think* (*think* == I could be wrong) it's not a perfect solution.
i think you need to read comments more carefully. "changes are dumb" != "dumb devs". the hwclock changes are not dumb, so you really should refrain from attempting to classify things you dont understand without trying to understand them first.
