Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#16838 - [e2fsprogs] 1.41.9 filesystem check regression

Attached to Project: Arch Linux
Opened by aniruddha (aniruddha) - Sunday, 25 October 2009, 12:28 GMT
Last edited by Dan Griffiths (Ghost1227) - Monday, 01 March 2010, 19:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Ronald van Haren (pressh)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


With e2fsprogs 1.41.8 when a filesystem contained errors, it was auomatically checked. The message was:

/dev/sda2 contains a filesystem with errors, check forced

With e2fsprogs 1.41.9 the boot process is halted with the message "filesystem check failed' and requires you to login to do a manual fsck.

Additional info:
* package version(s) e2fsprogs 1.41.9
* config and/or log files etc.

Steps to reproduce:

This task depends upon

Closed by  Dan Griffiths (Ghost1227)
Monday, 01 March 2010, 19:41 GMT
Reason for closing:  Fixed
Comment by Łukasz Fibinger (lucke) - Sunday, 25 October 2009, 14:20 GMT
To clarify: even though rc.sysinit should take care of it, "superblock mounted in the future" errors still pop up after unclean reboot when HARDWARE_CLOCK is set to localtime in >GMT timezones. It just corrected that and continued booting in e2fsprogs 1.41.8, in 1.41.9 the "perform manual check, /sbin/sulogin -p" stuff gets triggered. Ted Ts'o changed the behaviour of buggy_init_script due to . Arch actually boots without interruption with 1.41.9 and buggy_init_scripts in /etc/e2fsck.conf.
Comment by aniruddha (aniruddha) - Monday, 26 October 2009, 08:11 GMT
I closed the wrong bug
Comment by Aaron Griffin (phrakture) - Wednesday, 28 October 2009, 21:04 GMT
So.. what's the fix here?
Comment by Łukasz Fibinger (lucke) - Thursday, 29 October 2009, 05:50 GMT
I don't know. This thing baffles me; I'm flustruck, maybe I'll manage to figure it out when I'm a-okay.
Comment by aniruddha (aniruddha) - Thursday, 29 October 2009, 08:14 GMT
Remove the patch causing problems and report it to upstream?
Comment by Dale Blount (dale) - Tuesday, 10 November 2009, 00:47 GMT
I can reproduce the superblock in the future bug as well. This thing is bothering me so bad now, I may just have to try to figure out why it's breaking. It appears that the superblock is stored as localtime at some point and GMT at others which freaks out fsck on boot. Aaron, this doesn't happen to you being in GMT+ as well? Maybe we need to set localtime before fsck runs?

Comment by Daniele C. (legolas558) - Tuesday, 10 November 2009, 01:01 GMT
seems like no more happening with 2.6.32(-rc6)
Comment by c b (cb474) - Tuesday, 10 November 2009, 02:49 GMT
I was also having the problem of being force to do manual file system checks with the "superblock last mount time was in the future" error. (I actually get this error surprisingly frequently. The last update of the tzdata package set my clock ahead eight hours for some reason. Just resetting my clock by a couple minutes triggered the problem once.)

Downgrading from e2fsprogs 1.41.9-1 to 1.41.8-2 also solved the problem for me.
Comment by Daniele C. (legolas558) - Saturday, 28 November 2009, 15:14 GMT
I am using a 2.6.32 vanilla kernel and the problem is gone, I guess that next kernel will fix this issue.

Please somebody confirm
Comment by Łukasz Fibinger (lucke) - Saturday, 28 November 2009, 17:06 GMT
Seems to be okay in .32 indeed.
Comment by Aaron Griffin (phrakture) - Tuesday, 01 December 2009, 21:47 GMT
Dale, can you confirm this fixed? If so, we can close it
Comment by Dale Blount (dale) - Wednesday, 02 December 2009, 13:02 GMT
I'll check tonight as I only noticed it on my box at home.
Comment by Dale Blount (dale) - Thursday, 03 December 2009, 01:05 GMT
Is there a kernel26 package for 2.6.32 somewhere I can try out? I don't see one in testing.

We can also set
buggy_init_scripts = 1

in e2fsck.conf

Google search for buggy_init_scripts - it seems Arch isn't the only distro with this issue (although some handle it better by only printing a warning about superblock time instead of forcing fsck).
Comment by Dale Blount (dale) - Saturday, 05 December 2009, 14:57 GMT
OK, I tried 2.6.32 and it failed in the same way. Then I started to add some debug into rc.sysinit.
After a few tries I realized my problem was that I had HARDWARECLOCK="local" in rc.conf and there is no case for this. After setting this to "localtime" like it should be, the problem went away for me.

It appears I'm not the only one with this issue: Maybe we should add an or into the localtime elif?
Comment by Daniele C. (legolas558) - Saturday, 05 December 2009, 16:21 GMT
It's not a matter of HARDWARECLOCK, I have always add "localtime" and I had the problem prior to some unknown change which I think is in kernel 2.6.32
Comment by Dale Blount (dale) - Wednesday, 23 December 2009, 19:40 GMT
Daniele, what side of GMT are you on? What is your TIMEZONE set to in rc.conf?
Comment by Daniele C. (legolas558) - Wednesday, 23 December 2009, 21:07 GMT
@dale: I live in Italy, my TIMEZONE in rc.conf is "Europe/Rome"

This is other interesting information:
$ hwclock --utc
Wed Dec 23 23:06:14 2009 -0.031202 seconds
$ date --utc
Wed Dec 23 21:06:50 UTC 2009
$ date
Wed Dec 23 22:07:05 CET 2009

The local date is correct, while I am not sure about the hardware clock...does these information seem consistent to you?
Comment by Dale Blount (dale) - Wednesday, 23 December 2009, 21:12 GMT
Yes, that data looks about the same as mine.

One thing though, hwclock --utc will report the wrong time if your hardware clock is actually stored in localtime which you said it is.
Comment by Daniele C. (legolas558) - Thursday, 24 December 2009, 16:21 GMT
yes my BIOS clock runs in local time, I have just checked it
Comment by Tomas Mudrunka (harvie) - Friday, 25 December 2009, 00:53 GMT
legolas558: yea. you are probably "localizing" or "UTCing" time twice.

Fri Dec 25 01:49:14 2009 -0.566887 seconds
hwclock --utc
Fri Dec 25 02:49:18 2009 -0.868947 seconds
Fri Dec 25 01:44:11 CET 2009
date --utc
Fri Dec 25 00:44:13 UTC 2009

0 ;) harvie@harvie-ntb ~ $ cat /etc/rc.conf | grep ^HARDWARECLOCK

as you can see hwclock == date. which means that local time is stored in CMOS.
but i am not sure why hwclock-utc != date-utc...
Comment by Daniele C. (legolas558) - Friday, 25 December 2009, 09:47 GMT
@harvie: nope, CMOS is local time and my HARDWARECLOCK is set to localtime, there's nothing wrong in my configuration. Hardware clock is different from local time (in UTC) because they're synchronized when shutting down.

I have a pretty standard configuration
Comment by Ionut Biru (wonder) - Friday, 08 January 2010, 20:27 GMT
maybe we can add a e2fsck.conf like in the forum?
i tested myself and seems that is working. note that those values are for ext3/ext4.
Comment by Tomas Mudrunka (harvie) - Friday, 08 January 2010, 22:02 GMT
wonder: i think we should fix the problem rather than trying to make some band-aid solution, hide problems or supress error warnings. last write time in future can be on filesystem for some another reason and then it will be left unfixed with this configuration. :-(

i think that problem is in handling return code of fsck and maybe also in adjusting time.
Comment by Dominik Schips (Dominik) - Saturday, 16 January 2010, 18:31 GMT
Same problem here with a fresh ftp installation. hwclock is set to localhost and in rc.conf it is configured as localhost.
If I change the hwclock (BIOS setting) to 1 hour ahead I can boot my arch linux correct.

I did a fsck.ext4 -f -v several times with the USB install image and a GRML live CD. Yet it didn't fix the problem for me to get the system boot with the hwclock on correct localtime. I am in germany so my localtime is UTC+1 at the moment.
Comment by Tomas Mudrunka (harvie) - Saturday, 16 January 2010, 20:06 GMT
i am slightly east in Czech Republic (also UTC+1)... so i think problem is obviously only with UTC+ times. but anyway there are two bugs:

1.) time is set incorrectly so there are block written in future (which can be repaired without reboot)
2.) there are incorrect handling of fsck return value which prevents arch from repairing fs without reboot. (you have to study meanings of particular return values + sometimes fsck needs to be runed few times to fully correct the fs)
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 28 February 2010, 23:58 GMT
  • Field changed: Status (Assigned → Waiting on Response)
status with latest e2fsprogs?
Comment by Daniele C. (legolas558) - Monday, 01 March 2010, 00:02 GMT
i think this has been fixed in kernel, it can be closed for me since I have no more experienced it