fsck always fails (superblock last write time in future) on ext4

Bug #405828 reported by Alexander Hartl
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Binary package hint: util-linux

I have installed ubuntu 9.10 alpha 3 with the kernel 2.6.31-4-generic and I converted my partitions from ext3 to ext 4 following this manual: http://biete.com/?p=182. With my home partition this worked without any trouble, but when I tried it with my root partition I got the error
"/dev/sda1: Superblock last write time is in the future. FIXED." when I rebooted. Then the system restarted. But during this restart the error occurs again, so I am not able to boot ubuntu anymore, because it always reboots.

When I run fsck.ext4 from a ubuntu 8.10 live cd it tells me that the filesystem is clean.

There are some similar bugs concerning UTC and the local time zone (I have UTC+2) but I don't think that it's this bug because I tried to set the time to a point in the future (one month) using the bios, which didn't change anything.

The version of util-linux-ng which fsck is part of is 2.16.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 405828] [NEW] fsck always fails (superblock last write time in future) on ext4

On Tue, 2009-07-28 at 14:16 +0000, Alexander Hartl wrote:

> I have installed ubuntu 9.10 alpha 3 with the kernel 2.6.31-4-generic and I converted my partitions from ext3 to ext 4 following this manual: http://biete.com/?p=182. With my home partition this worked without any trouble, but when I tried it with my root partition I got the error
> "/dev/sda1: Superblock last write time is in the future. FIXED." when I rebooted. Then the system restarted. But during this restart the error occurs again, so I am not able to boot ubuntu anymore, because it always reboots.
>
> When I run fsck.ext4 from a ubuntu 8.10 live cd it tells me that the
> filesystem is clean.
>
From the sound of it, you don't have a UTC/localtime issue (in any case
they always affected people WEST of UTC), but let's just verify that.

Before AND after you run fsck.ext4 on the Live CD, please run the
following two commands and provide the output:

 date

 sudo hwclock --show

Then reboot the full system and press ESCAPE at the GRUB menu, highlight
the "(recovery mode)" option, *EDIT* it (don't boot), *EDIT* the
"linux"/"kernel" line and add " init=/bin/bash" to the end.

Boot that, it'll drop you into a shell fairly quickly.

Run those two commands again, also provide the output of

 grep UTC /etc/default/rcS

Now "reboot -f", select recovery mode again (boot it this time) and
allow the fsck to run. After it completes, before rebooting, run the
three commands again and provide the output.

Scott
--
Scott James Remnant
<email address hidden>

Changed in util-linux (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Alexander Hartl (alx321) wrote :

Ok, here you are:

Live CD:
ubuntu@ubuntu:~$ date
Mi 29. Jul 14:11:10 UTC 2009
ubuntu@ubuntu:~$ sudo hwclock --show
Mi 29 Jul 2009 16:11:23 UTC -0.116412 Sekunden
ubuntu@ubuntu:~$ sudo fsck.ext4 /dev/sda1
e2fsck 1.41.3 (12-Oct-2008)
/dev/sda1: sauber, 202210/655360 Dateien, 1884270/2621440 Blöcke
ubuntu@ubuntu:~$ date
Mi 29. Jul 14:12:11 UTC 2009
ubuntu@ubuntu:~$ sudo hwclock --show
Mi 29 Jul 2009 16:12:23 UTC -0.191012 Sekunden

"init=/bin/bash" - Shell:
# date
Wed Jul 29 18:22:45 CEST 2009
# hwclock --show
Wed Jul 29 16:23:26 2009 -0.469027 seconds
# grep UTC /etc/default/rcS
UTC=no

Unfortunately I couldn't try it after fsck ran because it only gives me 5 seconds to read its output and then reboots immediately.
Instead I tried running fsck from the "init=/bin/bash" shell - it also checked the drive, but it didn't give me the error "Superblock last write time is in the future" but just "/dev/sda1 contains file system with errors, check forced".
If I run fsck again without rebooing the filesystem's "clean", but after a reboot it "contains file system with errors" again.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 405828] Re: fsck always fails (superblock last write time in future) on ext4

On Wed, 2009-07-29 at 14:52 +0000, Alexander Hartl wrote:

> "init=/bin/bash" - Shell:
> # date
> Wed Jul 29 18:22:45 CEST 2009
>
Sorry, could you run this one as:

  TZ=UTC date

Thanks

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Alexander Hartl (alx321) wrote :

Sorry that I couldn't respond earlier. I had some trouble with my instalation: As I recognized that /dev/sda1 was displayed as ext3 in mount I thought maybe an update-initramfs will help, but afterwards grub couldn't start this kernel at all. Thus I reinstalled it using aptitude (it was updated to a slightly newer version). As it didn't help I restored the boot directory which made grub not start anymore as well. So I downloaded a ubuntu jaunty cd to be able to read and write ext4. Using this cd I did an fsck.ext4 on the partition but it just told me that it restored the journal. I then found out that I had to update to grub2 - after I had done this everything worked again - the bug suddenly didn't occur anymore.

I tried to reproduce it to be able to develop a fix by setting the date to a point in the future, booting and setting it back, but against my expectations fsck was not run on startup. So I ran it manually. It gave me "restoring journal" and found some other things that it fixed, no error concerning the superblock time BUT I then rebooted and suddenly the bug occured again on every bootup.

mount now gives me the right filesystem of /dev/sda1.

TZ=UTC date
gives me the same as
hwclock --show

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Ok, if this should happen again please do file a new bug.

Changed in util-linux (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.