FS#17438 - [initscripts] causes fsck: Superblock last write time is in the future.
Attached to Project:
Arch Linux
Opened by Tomas Mudrunka (harvie) - Tuesday, 08 December 2009, 12:32 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 16:37 GMT
Opened by Tomas Mudrunka (harvie) - Tuesday, 08 December 2009, 12:32 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 16:37 GMT
|
Details
Description: Almost every restart i get this annoying
message. I suppose it´s related to switching UTC and local
time during the init, or something similar. and it forces me
to do fsck -a /dev/root_device manually. For example this
happend even when computer was turned off for about 12 hours
(so fs errors are probably not caused before reboot, but i
get those errors even when i reboot computer without
delay):
EXT3-fs: write access will be enabled during recovery. usb 2-2: configuration #1 chosen from 1 choice kjournald starting. Commit interval 5 seconds EXT3-fs: sda2: orphan cleanup on readonly fs EXT3-fs: sda2: 9 orphan inodes deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with writeback data mode. kinit: Mounted root (ext3 filesystem) readonly. INIT: version 2.86 booting > Arch Linux > http://www.archlinux.org > Copyright 2002-2007 Judd Vinet > Copyright 2007-2009 Aaron Griffin > Distributed under the GNU General Public License (GPL) ------------------------------ :: Starting UDev Daemon [DONE] :: Triggering UDev uevents [DONE] :: Loading Modules [DONE] :: Loading standard ACPI modules [DONE] :: Waiting for UDev uevents to be processed [DONE] > UDev uevent processing time: 53ms :: Bringing up loopback interface [DONE] :: Mounting Root Read-only [DONE] :: Checking Filesystems [BUSY] /dev/sda2: Superblock last write time (Tue Dec 8 13:36:39 2009, now = Tue Dec 8 12:36:52 2009) is in the future. <-- THiS iS THe PRoBLeM [FAIL] ***************** FILESYSTEM CHECK FAILED **************** * * * Please repair manually and reboot. Note that the root * * file system is currently mounted read-only. To remount * * it read-write type: mount -n -o remount,rw / * * When you exit the maintenance shell the system will * * reboot automatically. * * * ************************************************************ Give root password for maintenance (or type Control-D to continue): [root@(none) ~]# fsck -a /dev/sda2 fsck z util-linux-ng 2.16 /dev/sda2 obsahuje systém souborů s chybami, kontrola vynucena. (<-- errors => check forced) /dev/sda2: 564860/3571712 souborů (5,2 % nesouvislých), 12816672/14281785 bloků Additional info: * package version(s) sysvinit 2.86-5 e2fsprogs 1.41.9-1 * config and/or log files etc. /etc/rc.conf: ... LOCALE="cs_CZ.utf8" HARDWARECLOCK="localtime" USEDIRECTISA="no" TIMEZONE="Europe/Prague" KEYMAP="cz" CONSOLEFONT="ter-v14n" CONSOLEMAP= USECOLOR="yes" ... DAEMONS=(syslog-ng nscd hal fam gdm @laptop-init @gpm !network @alsa @crond @acpid @networkmanager @miredo @openntpd @autofs @privoxy @tor @netfs @sshd @lighttpd @ntpd @cups @cpufreq) Steps to reproduce: |
This task depends upon
Closed by Tom Gundersen (tomegun)
Sunday, 27 March 2011, 16:37 GMT
Reason for closing: Works for me
Additional comments about closing: Requested closed by the reporter. Please reopen if someone fits the criteria in my last comment.
Sunday, 27 March 2011, 16:37 GMT
Reason for closing: Works for me
Additional comments about closing: Requested closed by the reporter. Please reopen if someone fits the criteria in my last comment.
0 ;) harvie@harvie-ntb ~ $ pacman -Qs initscripts
local/initscripts 2009.08-1 (base)
System initialization/bootup scripts
Please try removing them both and see if your problem disappears.
Do you have some other OS in a dualboot?
After you reboot your system - is the time correct in BIOS?
LANG=c cat /etc/rc.d/ntpd
cat: /etc/rc.d/ntpd: No such file or directory
I can see this message after every improper shutdown (it wants me to fsck disks). What if this happens on a remote server? :X
problem is in the "/etc/rc.sysinit" which IMHO does not handle fsck return value properly. i have checked "man fsck" and i think the problem is there.
i have arch on "remote server" and it stucks all the time when i need to kill it and it needs to be rebooted until it start working again.
the problem is in the
"Please repair manually and reboot... Give root password for maintenance (or type Control-D to continue)"
message it should timeout after while if no password is given. when i pres ^G, system just reboots and fix filesystems automagically. but IMHO it can be fixed automagicaly without need for reboot. why on the first reboot it waits for root password and on the second reboot it just repair system without any questions?
The exit code returned by fsck is the sum of the following conditions:
0 - No errors
1 - File system errors corrected
2 - System should be rebooted
4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error
32 - Fsck canceled by user request
128 - Shared library error
The exit code returned when multiple file systems are checked is the bit-wise OR of the exit codes for each file system that is checked.
if [ ${fsckret} -gt 1 -a ${fsckret} -ne 32 ]; then
echo
echo "***************** FILESYSTEM CHECK FAILED ****************"
echo "* *"
echo "* Please repair manually and reboot. Note that the root *"
echo "* file system is currently mounted read-only. To remount *"
echo "* it read-write type: mount -n -o remount,rw / *"
echo "* When you exit the maintenance shell the system will *"
echo "* reboot automatically. *"
echo "* *"
echo "************************************************************"
echo
/sbin/sulogin -p
fsck_reboot
fi
the ${fsckret} -gt 1 conditional is imho absolutely wrong. the return value of fsck is sum so it should be handled in bit different manner (and according to meanings of each number). maybe the problem is also with multiple filesystems, when fsck repairs one filesystem and the other after reboot because it's launched with different arguments.
There are two real problems here:
1) The underlying cause of the problem needs to be found - I have never been able to reproduce the problem, so I cannot do this.
2) It is entirely stupid to make "File system write time in the future" a critical error and this needs to be changed upstream. I have no idea what the reasoning behind this is.
As a workaround, set your hardware clock to UTC, then everything will work as expected. It actually makes no sense to me why anyone would not do this.
It's set like this now, but a workaround is not a fix. Also the issue doesn't seem to effect people west of GMT.
ArchLinux thinks that filesystem have to be rapaired manualy, but when i reboot it, it repairs itself during next boot automatically or without reboot i can manualy launch command "fsck -a /dev/sd??" which fix it also. That means it can be fixed without user intervention even when arch offers us root shell instead of fixing it so arch DEFINETELY NEEDS BETTER HANDLING OF FSCK RETURN CODE. BTW for some strange reasons fsck sometimes needs to be launched several times which arch also does not try.
IMHO first step is to run fsck two times and save only the fsckret from second run...
However, please add "echo fsck return value: ${fsckret}" and tell me the value that is returned.
[options]
buggy_init_scripts = true
This will still cause an fs check, but not abort the boot process. The underlying cause of the problem is still unknown, as none of the affected users seem to be able to properly investigate why their time is not set correctly during fsck on boot.
1.) we don't want to disable fsck on unclean system halt
2.) this is only problem of UI (can't we just re-run fsck and continue booting instead of waiting for root password) - maybe we can check how other distros are handling this...
So, I see two people on this bug report that have this problem. By any chance, are you using a custom kernel? If so, this might be related to
FS#18078.1.) problem of UI, which prevents arch from booting even when filesystem can be repaired automaticaly, this can happen for some another reason even when time is set correctly (!crucial on remote servers!)
2.) problem of setting time, which causes fsck to fail
at line 56: echo $RTC_MAJOR
at line 66 (ie. before /sbin/hwclock): echo "clock is setup with $HWCLOCK_PARAMS"
report the results
While I still like to find and fix the time setup bug, the e2fsck.conf option I mentioned above is a valid workaround - it causes e2fsck to make a full file system check instead of bailing out entirely.
In addition to what Roman asked before, the output of "ls -l /dev/rtc*" once the system has booted might be helpful.
EDIT: And if you are using the Arch kernel, add "lsmod | grep rtc" to the list of things to post.
253
clock is setup with --hctosys --utc
$ dmesg |grep rtc
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
$ lsmod |grep rtc
rtc_cmos 8904 0
rtc_core 14631 1 rtc_cmos
rtc_lib 1810 1 rtc_core
$ ls -l /dev/rtc*
lrwxrwxrwx 1 root 4 2010-02-23 10:03 /dev/rtc -> rtc0
crw-rw-r-- 1 root 253, 0 2010-02-23 10:03 /dev/rtc0
see, there should not be --utc
this means that you don't have HARDWARECLOCK set up properly in rc.conf
it must be HARDWARECLOCK="localtime"
(I assume your hardware clock is actually using localtime, because users with UTC have zero problems)
If you have --utc, then you shouldn't have any problems at all.
Do you guys have Windows in dual-boot maybe?
or is something else messing with UTC/localtime etc between boots?
- You use UTC. Unless something messes with your hardware clock during system downtime, the Linux system time should always be correct.
- Your rtc device is created as expected (contrary to the case of
FS#18078, which I thought might be related, but it seems it isn't).Can we get the output of "date" at the beginning of initscripts (at some point before hwclock) and directly before the (failed) file system check? We need to verify that the date is actually set incorrectly on boot (which really shouldn't happen for UTC).
I hope the other two reporters can also provide the information needed - I suspect the problem reported by you (unhammer) might only be loosely related to theirs.
rtc_cmos 7504 0
rtc_core 12011 1 rtc_cmos
rtc_lib 1450 1 rtc_core
2.) i found interresting informations on this issue: http://lists.openwall.net/linux-ext4/2009/10/12/12
3.) btw rc.sysvinit is using deprecated fsck -a instead of reccomended fsck -p
2) Oh my ... can you confirm that your "now" time is always the correct time when the error occurs? In this case, looking at initscripts won't actually be very helpful, as WE are doing everything right, but e2fsck isn't. I'll look into this.
3) Oh yes, we should change that.
Add new e2fsck.conf configuration option, default/broken_system_clock
to support systems with broken CMOS hardware clocks. Also, since too
many distributions seem to have broken virtualization scripts now,
e2fsck will by default accept dates which are off by up to 24 hours by
default. (Addresses Debian Bugs: #559776, #557636)
Do we want to find the root of the problem or do we ignore it in case the new version solves the issue for those of you who still experience it?
but if it fixes the problem, then it doesn't really tell what caused it (or at least I don't see it),
so it must be downgraded after that to track the problem.
1.) filesystem is really OK and it does not need to be repaired after kernel crash (and i was just misleaded by fsck running almost every boot few months earlier)
2.) fsck is ignoring such problems because of some workaround...
did you observed similar behaviour?
Otherwise, there is something wrong with your clock...
See also this https://bugzilla.redhat.com/show_bug.cgi?id=522969 and links therein...
1) is using UTC
2) is not using dualboot
3) is running up-to-date standard Arch kernel and other packages