Superblock last mount times cause fsck to fail

Bug #423247 reported by Dave Morley on 2009-09-02
140
This bug affects 18 people
Affects Status Importance Assigned to Milestone
clock-setup
New
Undecided
Unassigned
clock-setup (Ubuntu)
High
Colin Watson
Karmic
High
Colin Watson

Bug Description

New bug created to track down fsck issue on first boot after install.

Fsck line reads:

/dev/sda1: Superblock last mount time (Wed 2 17:32:09 2009, now = Wed Sep 2 16:33:11 2009) is in the future.

hwclock --debug --show reads:

hwclock from util-linux-ng 2.16
Using /dev interface to clock.
Last drift adjustment done at 1251905554 seconds after 1969
Last calibration done at 1251905554 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2009/09/02 15:39:16
Hw clock time : 2009/09/02 15:39:16 = 1251905956 seconds since 1969
Wed Sep 2 16:39:16 2009 -0.249657 seconds

grep UTC /etc/default/rcS reads:

UTC=yes

date reads:

Wed Sep 2 16:43:42 BST 2009

Changed in ubuntu:
status: New → Confirmed
importance: Undecided → High
Dave Morley (davmor2) on 2009-09-02
description: updated
Dave Morley (davmor2) wrote :
Changed in ubuntu:
assignee: nobody → Colin Watson (cjwatson)

Thanks for the log, Dave

Up to "During install", everything's fine:

  Hw clock time : 2009/09/02 17:10:18 = 1251911418 seconds since 1969
  Wed 02 Sep 2009 05:10:18 PM UTC -0.822584 seconds
  UTC=yes
  Wed Sep 2 17:10:35 UTC 2009

But then, once ubiquity has finished:

  Hw clock time : 2009/09/02 18:18:42 = 1251915522 seconds since 1969
  Wed 02 Sep 2009 06:18:42 PM UTC -0.935498 seconds
  UTC=yes
  Wed Sep 2 17:21:36 UTC 2009

The hardware clock has been moved an hour forwards. I would guess this is because hwclock --systohc has been called without --utc, but with TZ=Europe/London such that it stores LOCALTIME in the hardware clock.

Thus on the first reboot after install, the hardware clock is an hour fast, and so is the system clock:

  Hw clock time : 2009/09/02 18:27:21 = 1251912441 seconds since 1969
  Wed 02 Sep 2009 18:27:21 BST -0.060552 seconds
  UTC=yes
  Wed Sep 2 18:28:24 BST 2009

NTP will be run, will reset this back to sanity, and the hardware clock will be saved from the system clock; but the last mount time is still an hour in the future - so the next reboot:

  Hw clock time : 2009/09/02 17:33:13 = 1251912793 seconds since 1969
  Wed Sep 2 18:33:13 2009 -0.141580 seconds
  UTC=yes
  Wed Sep 2 18:33:56 BST 2009

Colin Watson (cjwatson) on 2009-09-03
affects: Ubuntu Karmic → clock-setup (Ubuntu Karmic)
Changed in clock-setup (Ubuntu Karmic):
status: Confirmed → Triaged
Jarmo Ilonen (trewas) wrote :

I am not certain if this is the same bug as the reported one, but the symptoms are similar and the ~bug only started happening in karmic this week (around beginning of september 2009). I changed nothing in the configs, just upgraded (it was karmic before, only few days worth of packages).

This is current karmic installed in Virtualbox running in Windows XP. In /etc/default/rcS UTC=yes and the timezone is UTC+3.

After I start virtualbox and boot karmic, everything goes fine. Then I immediately reboot karmic (still running in same Virtualbox instance) and on next reboot it stops when fsck whines:

Superblock last mount time (Thu Sep 3 21:27:09 2009, now = Thu Sep 3 18:31:30 2009) is in the future.

And I have to run fsck manually. Correct time is 18:31, btw.

This is actually quite logical. In first boot Virtualbox gives the hwclock to linux and linux thinks it is in UTC, then adds the time-zone +3. That's where the boot time three hours in the future comes from (21:27 localtime). Later in the boot sequence it gets the correct time from ntp and when the system is rebooted, that value is updated to hwclock, taking UTC setting into account. So on second reboot linux gets the correct time, 15:31 UTC (18:31 localtime).

If I change /etc/default/rcS UTC=no, which is correct because that is what the host OS uses, then karmic in virtualbox works fine on every boot. So arguably in my case this is not a bug, but I still wonder why I never saw that whine from fsck before now.

ShawnStarr (shawn-starr) wrote :

I can confirm this also from today's alternative amd64 build of Karmic Alpha 5. Testing in VirtualBox shows same error, running fsck will correct problem but this isn't good.

valerio (valerio-orlandini) wrote :

Same bug, and not only after the upgrade, but about every 2-3 boots.

[Ubuntu Karmic AMD64, GMT +1 Timezone]

I'm on this; no need for anyone else to report similar symptoms.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package clock-setup - 0.98ubuntu2

---------------
clock-setup (0.98ubuntu2) karmic; urgency=low

  * Pass --utc or --localtime option to hwclock as appropriate, as well as
    --noadjfile (LP: #423247).

 -- Colin Watson <email address hidden> Thu, 03 Sep 2009 21:23:59 +0100

Changed in clock-setup (Ubuntu Karmic):
status: Triaged → Fix Released
Max Bowsher (maxb) wrote :

Hm.... I'm running Karmic on real hardware, and getting this sometimes in regular operation - *not* first boot after install.

Martin Erik Werner (arand) wrote :

I also saw this on a virtualbox system, a considerable number of boots _after_ the install itself. System was updated just before reboot.

Colin Watson (cjwatson) wrote :

Perhaps we could separate out non-first-boot-after-install issues to a separate bug report? There's clearly more than one thing at work here.

Glenn Brumfield (gbrumfield) wrote :

In my case, leaving the system shut down for a day resulted in a clean boot, but subsequent boot/reboots threw the error message. I think that the non-first-boot-after-install issues may be because the system is not shut down long enough to get beyond the time error.

Julien Lavergne (gilir) wrote :

Still here for me in a virtualbox installation:
- Install alpha 5, reboot ==> OK
- After, upgrade the all system to up-to-date packages, reboot ==> fsck alert.

Max Bowsher (maxb) wrote :

non-first-boot-after-install issue appears to be bug 427822

smurf (luca-dgh) wrote :

the big problem is that there is no way to set/unset UTC time, gnome utlities for clock settings are not properly working.
I fixed the problem editing /etc/default/rcS, UTC=no.

zpon (zpon-dk) wrote :

I seem to have some of the same, but with some additional errors. Screenshot of terminal error: http://picasaweb.google.com/lh/photo/PoGSZCs0jxecU8t2xLpYog?authkey=Gv1sRgCM3I--H5qKjNCA&feat=directlink

Cristian Gafton (gafton) wrote :

related: #422869

Lidinei (lidinei-gmail) wrote :

- I have instaled alpha 5.
- reboot and reboot always OK.
- after upgrading all the system to up-to-date packages, I got a fsck alert.

Lidinei (lidinei-gmail) on 2009-09-16
Changed in clock-setup (Ubuntu Karmic):
status: Fix Released → Incomplete
Steve Langasek (vorlon) wrote :

As noted in https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/423247/comments/10, this bug is about a fsck on first reboot after install. There have been other (*many* other) bugs related to spurious fscking due to timezone problems, including one recent one that is a kernel bug. I'm re-closing this report as fixed; please make sure you're upgraded to the 2.6.31-10.34 kernel package and retest, and follow up to bug #427822 (or open a new bug report) if you're still having issues.

Changed in clock-setup (Ubuntu Karmic):
status: Incomplete → Fix Released
tags: added: iso-testing

since upgrading to karmic (release), I get the following very often:

 /dev/sda1: Superblock last mount time (Thu Sep 24 20:58:00 2009,
          now = Thu Sep 24 19:59:23 2009) is in the future.

  /dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
          (i.e., without -a or -p options)
  mountall: fsck / [93] terminated with status 4
  mountall: Filesystem has errors: /

I must add, that at times the bios complains before, and resets.
So maybe the hardware clock is wrong.
But that was no problem with jaunty.

The problem I was experiencing seems to be fixed with one of the recent updates.

knorr (a-sokolov) wrote :

I has made 3 Ubuntu 9.10 Installations (from disks shipped from shipit.ubuntu.com) for my friends. All 3 computers can't boot from time to time with "Superblock last mount time" error message. My friends can't solve this problem themselv, because of very low computer knowledge, Setting UTC=no in /etc/default/rcS doesn't help.

knorr (a-sokolov) wrote :

Sorry about my english

StefanPotyra (sistpoty) wrote :

reopening for karmic, as I've got a reproducable scenario:
-> use the most recent karmic cd to get a shell,
mount your unstable /, /boot, bind-mount /dev /sys, /proc
issue grub-install /dev/sda

result: unstable bails out with errors (where the time is set correctly), while the karmic cd sets the time on the fs mount point completely wrong (the local time *is* in fact correct for the karmic cd).

Changed in clock-setup (Ubuntu Karmic):
status: Fix Released → Confirmed
Rolf Leggewie (r0lf) on 2011-10-19
Changed in clock-setup (Ubuntu Karmic):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments