Superblock last mount times cause fsck to fail

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

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.

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.

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.

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

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

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

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.

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.

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.

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

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.

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

related: #422869

- 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.

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.

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.

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.

Sorry about my english

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).