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
Opened by aniruddha (aniruddha) - Sunday, 25 October 2009, 12:28 GMT
Last edited by Dan Griffiths (Ghost1227) - Monday, 01 March 2010, 19:41 GMT
|
Details
Description:
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
Downgrading from e2fsprogs 1.41.9-1 to 1.41.8-2 also solved the problem for me.
Please somebody confirm
We can also set
[options]
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).
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: http://bbs.archlinux.org/viewtopic.php?pid=608690#p608690 Maybe we should add an or into the localtime elif?
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?
One thing though, hwclock --utc will report the wrong time if your hardware clock is actually stored in localtime which you said it is.
hwclock
Fri Dec 25 01:49:14 2009 -0.566887 seconds
hwclock --utc
Fri Dec 25 02:49:18 2009 -0.868947 seconds
date
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
HARDWARECLOCK="localtime"
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...
I have a pretty standard configuration
i tested myself and seems that is working. note that those values are for ext3/ext4.
i think that problem is in handling return code of fsck and maybe also in adjusting time.
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.
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)