Superblock last mount times cause fsck to fail
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
clock-setup |
New
|
Undecided
|
Unassigned | ||
clock-setup (Ubuntu) |
Fix Released
|
High
|
Colin Watson | ||
Karmic |
Won't Fix
|
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 |
description: | updated |
Changed in ubuntu: | |
assignee: | nobody → Colin Watson (cjwatson) |
affects: | Ubuntu Karmic → clock-setup (Ubuntu Karmic) |
Changed in clock-setup (Ubuntu Karmic): | |
status: | Confirmed → Triaged |
Changed in clock-setup (Ubuntu Karmic): | |
status: | Fix Released → Incomplete |
tags: | added: iso-testing |
Changed in clock-setup (Ubuntu Karmic): | |
status: | Confirmed → Won't Fix |
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