superblock last write time is in the future

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in SYSVINIT.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

I can confirm this, it is, in my opinion, a pretty nasty user experience actually!

My user experience:
1. Switch new PC to linux (note, the system clock was set to local (Amsterdam) time, which is 1 hour ahead of GMT)
2. Drop my shiny new daily build Karmic Netbook Remix cd in the drive, installing it (looks & went perfect, my compliments!)
3. Reboot system
4. Upon reboot stuck in the 'dos' screen with some 'vague' notion something went wrong (ofcourse I know wat it is, but your average joe will by this time switch off his PC, pull the ubuntu cd from the drive and ritually sacrifice it to the gods of the many windows)
5. Run fsck
6. reboot again
7. to my disbelief the message 'superblok time in future' appears again! so fixed that
8. reboot again
9. boot as it should have at point 4.

Could there be a way to have mountall perhaps automatically attempt to run fsck, specifically just to fix the superblock time issue after install? Or have the installer reset the hardware time BEFORE messing with the FS?

Most bizarre, as I was pretty confident that I'd already quite recently made ubiquity change the clock before doing filesystem operations. Please confirm the datestamp of the daily build you were using (and why a daily build rather than the beta?).

Please note that we don't use the upstream ubiquity project for bug tracking. I have moved the bug task to the ubiquity package in Ubuntu.

I'd have to take a look, but from memory it was from 2 or 3 days ago. I guess just out of habit I just downloaded the daily spin, will the beta be different? (I can try it later this day if you like)

This is still an issue. It often happens after installing a new kernel.

Regarding Stefans comment: please also look at Bug #440281 which was marked as a duplicate of this bug, but I believe it isn't.

Issues that happen after installing a new kernel are, of course, not installer bugs.

I also received a similar error after installing Ubuntu 9.10 on Sun Virtual Box 3.0.6 r52128. I never had this problem with Ubuntu 9.04 on VirtualBox. A screenshot of the error on my system is attached.

Of course, but partly it is because Ubiquity has set without asking UTC to yes. After changing it to no the problem seems to be gone. This might also a sysvinit bug because of the initializing.

I'm having this issue eventough independent of the time zone. I'm running on a laptop with a faulty battery (to be delivered soon). Therefore the system time is always reset to some date in 2008. Under Jaunty this caused a slightly annoying, yet automatic skipable fsck. Under Karmic, I need to set the time on the command line.

This happens to me because I dual boot, and Windows and Linux disagree about what time zone to set the system clock to. If Windows decides to change the time (which it sees as local EDT) to what the Internet says it is, and Linux is expecting to see UTC, then if I reboot into Linux after less than four hours in Windows I get dumped to the root shell and have to run fsck.

It seems like this didn't happen to me when I ran Jaunty, though, only after I upgraded to Karmic Beta.

Why does this error have to happen, anyway? System clocks are wrong much more often than superblocks, so the sane thing for Ubuntu to do in this situation is not "try to fix the superblock" but "try to fix the clock".

On Wed, 2009-10-07 at 09:14 +0000, Rob Speer wrote:

> This happens to me because I dual boot, and Windows and Linux disagree
> about what time zone to set the system clock to. If Windows decides to
> change the time (which it sees as local EDT) to what the Internet says
> it is, and Linux is expecting to see UTC, then if I reboot into Linux
> after less than four hours in Windows I get dumped to the root shell and
> have to run fsck.
>
You should make sure you have UTC=no in /etc/default/rcS - then Windows
and Linux will agree on the time.

Scott
--
Scott James Remnant
<email address hidden>

I interact with other computers that are on UTC. That strikes me as an undesirable workaround, when the bug is that dumping to a root shell and forcing a fsck is an inappropriate response to the clock being off by a few hours.

I second that, I can understand the behaviour on servers or other mission critical systems, but there seems to be no point forcing an fsck for such an issue on either desktops or mobile systems. Would be cool to be able to enable/disable this feature with a mount option (eg. mount=ignore_superbock_timestamp,defaults).

On Thu, 2009-10-08 at 16:48 +0000, Rob Speer wrote:

> I interact with other computers that are on UTC. That strikes me as an
> undesirable workaround, when the bug is that dumping to a root shell and
> forcing a fsck is an inappropriate response to the clock being off by a
> few hours.
>
You misunderstand the meaning of the setting.

Your *system clock* will always be in UTC, this setting refers to what
your hardware clock stores time in. Nominally we'd prefer that to be
UTC too, but this is not possible if we're sharing the machine with
Windows.

Scott
--
Scott James Remnant
<email address hidden>

I am on a desktop and this is a real pain I thought that it was an issue with a partition and it completely keeps me from loading kernel 28.12 or 28.13 I can work with in the 28.11 but that means that I have to catch it on load also I notice that this affects how x is loading my desktop the polkit for gnome and also the settings manager

Scott, that's a good explanation for how I can fix the situation in my case.

Still, I don't think it's desirable to bail out to a root prompt just because the hardware clock is wrong, no matter how that came to be.

I did this
gedit /usr/share/initscripts/default.rcS
changed UTC line to UTC=no
and no time issue that I see
it goes straight into fsck with me having to give the command
also no mention of mountall not loading so no double log in

On Sat, 2009-10-10 at 20:19 +0000, Rob Speer wrote:

> Scott, that's a good explanation for how I can fix the situation in my
> case.
>
> Still, I don't think it's desirable to bail out to a root prompt just
> because the hardware clock is wrong, no matter how that came to be.
>
I agree.

Scott
--
Scott James Remnant
<email address hidden>

This bug was fixed in the package e2fsprogs - 1.41.9-1ubuntu2

---------------
e2fsprogs (1.41.9-1ubuntu2) karmic; urgency=low

   * Applied patch (sent upstream) to ignore a future last mount, write or
     check time by up to 24 hrs when fsck called with -p ("preen", ie.
     fix minor problems without human intervention). LP: #268808.

 -- Scott James Remnant <email address hidden> Mon, 12 Oct 2009 16:35:14 +0100

all of my kernels load now
after I did the
gedit /usr/share/initscripts/default.rcS
changed UTC line to UTC=no
it ran fsck once and loaded system then all kernels seem fine
does not do it anymore

I believe that the ubiquity task is Invalid now that there is a fix in e2fsprogs.

I found this bug report through bug #432070, and after reading this – http://swiss.ubuntuforums.org/showthread.php?t=1330844 – topic on the Ubuntu forums.

It seems many people are still affected by this bug, including me, and it does not seem to be fixed in Ubuntu 9.10 as this bug report claims. I can not reliably reproduce it however, and can’t provide useful information regarding the ‘UNEXPECTED INCONSISTENCY’ error, unless someone would tell me if I could provide useful logs. Please read my comments on the second page of the forum topic I mentioned. I’m sure my hard disk drive is not the culprit because Disk Utility says my hard disk drive is healthy.

Alexander, please see my workaround posted with Bug #432070:
  WORKAROUND:
  Adding the following to "[options]" in /etc/e2fsck.conf, running update-initramfs and rebooting fixed it for me:
  buggy_init_scripts = 1