superblock last write time is in the future

Bug #268808 reported by Sid MacT on 2008-09-11
110
This bug affects 14 people
Affects Status Importance Assigned to Milestone
ubiquity
Invalid
Undecided
Unassigned
e2fsprogs (Ubuntu)
High
Scott James Remnant (Canonical)
Karmic
High
Scott James Remnant (Canonical)
ubiquity (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned

Bug Description

When /etc/default/rcS has the line
UTC=no
then when Ubuntu startup runs fsck one receives the message:
'superblock last write time is in the future. FIXED'
googling reveals the problem is the hardware clock is set to local time,
but the Ubuntu shutdown process writes the UTC, i.e., GMT time to the superblock.
So on reboot, when the fsck compares the hardware clock to the superblock,
the GMT time in the superblock is 'in the future'.

Note: my time zone is California, so GMT is 7 or 8 hours ahead of my local time.

All the google links talk about the problem being that the startup process does the
superblock compare, via fsck, before the routine runs that resets the system time.

My perception is that the real issue is that the shut-down scripts write the GMT time to
the superblock instead of the local time.

I know there is the work-around of setting UTC=yes; but this messes up people the dual-boot(ugh) Windows.

Related branches

description: updated
description: updated
Andres Mujica (andres.mujica) wrote :

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?

Colin Watson (cjwatson) wrote :

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.

Changed in ubiquity:
status: New → Invalid

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)

unggnu (unggnu) wrote :

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.

Colin Watson (cjwatson) wrote :

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

GaTechGrad (gatechgrad) wrote :

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.

unggnu (unggnu) wrote :

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.

David Ayers (ayers) wrote :

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.

Rob Speer (rspeer) 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.

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>

Rob Speer (rspeer) 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.

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>

Daniel Stone (danielstone) wrote :

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

Rob Speer (rspeer) 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.

Daniel Stone (danielstone) wrote :

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>

affects: sysvinit (Ubuntu) → e2fsprogs (Ubuntu)
Changed in e2fsprogs (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Scott James Remnant (scott)
Changed in e2fsprogs (Ubuntu Karmic):
milestone: none → ubuntu-9.10
Launchpad Janitor (janitor) wrote :

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

Changed in e2fsprogs (Ubuntu Karmic):
status: Triaged → Fix Released
Daniel Stone (danielstone) wrote :

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

Brian Murray (brian-murray) wrote :

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

Changed in ubiquity (Ubuntu Karmic):
status: New → Invalid
Alexander van Loon (avanloon) wrote :

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.

Daniel Hahler (blueyed) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers