[solved] Superblock last mount time is in the future

[zub]

Hello,

I'm running Debian on an ALIX board (pretty much PC-compatible thing: http://pcengines.ch/alix2d3.htm ). All is working fine, except recently it started happening that after each reboot fsck chokes complaining about superblock mount time:

Code: Select all

Checking root file system...fsck from util-linux-ng 2.16.1
humel-root: Superblock last mount time (Wed Oct  7 18:53:39 2009,
	now = Sat Jan  1 00:00:14 2000) is in the future.

humel-root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

The immediate reason is obvious - the ALIX doesn't keep the time over reboot, so it always starts with Jan 1 2000, 0:00.

When I installed the system, I turned off the interval-between-checks option (tune2fs /dev/sda1 -i 0), as this makes little sense in my case and I was relying solely on max-mount-count checks. All was working fine. But then (after some update I guess) - I started running into the superblock mount time problem.

I didn't find out how can I disable this check. A workaround might be to somewhere early after boot (before fsck) set the date to something like $NOW+few_years value. Is there a better solution? What is the proper way of dealing with this?

Thanks for any tips.

zub

[dbbolton]

I had a similar problem. It kept recurring until I went into my BIOS and changed the time there.

If it keeps happening even after that, your battery could be dead.

[zub]

Maybe I wasn't clear enough: The board is designed not to keep the time. So, there's no battery. It's standard behaviour for the device. And it has behaved always like this.

So, making it remember the time is not much of an option. (There exist HW hacks to add a capacitor/battery, but I don't want to do that.)

What I'm looking for is a way to make fsck not complain about that particular thing. I think this problem must be common to devices with unreliable time, and I think there must be some such devices around. So, how is this thing handled on them?

[dbbolton]

Have you tried the "-e continue" option for tune2fs? What about -T?

[bugsbunny]

http://www.linux-archive.org/debian-use ... clock.html

Well I found a couple of things that are sort of relevant.

1) If you have a file /etc/e2fsck.conf and in there you have an option
buggy_init_scripts = 1 then it will ignore the time check. BUT you have
to persuate initramfs to put this file in the initram or it will not be found
as the disk has not yet been mounted and by default it will not be put there.

2) If you put fastboot as a kernel option in lilo or grub the fsck check is
skipped. This is probaly not a good idea unless you use a journalled
file system as otherwise your system could get corrupt. But it seems
to work with ext3 if I boot the board through to the logon (which will
already have written some log files) and then turn off the power and
reboot. I could not find this documented anywhere, I just found that
there was a test for this in /etc/init.d/checkfs.sh so I do not know how
secure this is for the future.

There are a number of embedded boards like this without a battery
backed clock, so this problem will occur again.

It is not that hard to persuade initramfs to include that file Place a script into /etc/initramfs-tools/hooks/
Make sure it''s executable

Code: Select all

#!/bin/sh
#
# Initramfs-tools hook script
#
# Copyright 2006 Tim Dijstra <tim@famdijkstra.org>
# Released under GPLv2

PREREQ=""

prereqs()
{
	echo "$PREREQ"
}

case $1 in
prereqs)
	prereqs
	exit 0
	;;
esac

. /usr/share/initramfs-tools/hook-functions
[ -f /etc/e2fsck.conf ] && mkdir -p ${DESTDIR}/etc && cp /etc/e2fsck.conf ${DESTDIR}/etc/e2fsck.conf

Now when you (or the system) run update-initramfs it should include that file, if it exists.

The above is untested for this particular situation (by me). I use similar for other things. I suspect you'll need to create that conf file, with the following content:

Code: Select all

[options]
	 buggy_init_scripts = 1

another way off working around the problem is to turn off time based checks:

Code: Select all

tune2fs -i 0 <device>

See http://lwn.net/Articles/264498/ for more.

The best solution, in your case, is probably to disable time based fscks completely. I think the conf file solution only allows the time to offset into the future by 24 hours.

[bugsbunny]

I see that you had the time based fsck disabled. I'd check and make sure it's still disabled. If it is disabled, and still throws this error, you may want to file a bug against e2fsprogs.

[zub]

Thanks for the tips.

The time between checks (tune2fs -i) was still set to 0 (according to dumpe2fs). But AFAIK that is an independent issue. What I'm solving here is not cause by the time from the last check exceeding some value, but the plain and simple thing is e2fsck not liking superblock last mount time > current time. (And the same goes for superblock last write time.)

But the tip about /etc/e2fsck.conf was in the right direction. I don't want buggy_init_scripts = 1 (this options relaxes the superblock last mount/write time check by 24hrs; here I don't want relaxed check, but no check), but digging a bit more I came up with this to be put in /etc/e2fsck.conf:

Code: Select all

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
    preen_ok = true
    preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
    preen_ok = true
    preen_nomessage = true
}

This config then tells e2fsck that the superblock mount and write time issues are ok to be auto-fixed (preen_ok=true) and that I don't want to see e2fsck mentioning it (preen_nomessage=true). More info can be found in e2fsc.conf man page.

The numeric codes (0x000031, 0x000032) are not really in the man page, but you can find them in e2fsck sources (http://e2fsprogs.sourceforge.net/), specifically in e2fsck/super.c (usage) and e2fsck/problem.h (value definition).

So, this solves my problem. One remaining thing is: Why is e2fsck considering this superblock mount/write time such a big issue? If they do, they probably have a reason for it. I.e. will my filesystem just explode?

[ingo]

Well, has it exploded? If not I might try your solution, as I recently installed sidux on my T41 which already had arch on it. Now I get the same problem whenever sidux boots up. I thought openntpd would help set things right, but no joy.

Many thanks in advance on an update

[zub]

A bit late reply... But the update is: So far I'm running ok.

But I'm not rebooting often. I'm using the machine as a router.

[bugsbunny]

note that new versions of e2fsck have some new options. (1.41.10-1, found in testing):
From the changelog:

* Add new e2fsck.conf configuration option:
default/broken_system_clock for system with broken CMOS hardware
clocks. (Closes: #559776)

Quoting from a response in the bug thread:

Your system is broken already because it doesn't have a usable RTC.
Having correct system time is important! Indeed, there are certain
hueristics (such as detecting losted orphaned inodes) that depends on
the system time being correct.

I will add an e2fsck.conf option for systems with busted system
clocks, but it won't be the default.

From the current man page for e2fsck.conf:

broken_system_clock
The e2fsck(8) program has some hueristics that assume that the
system clock is correct. In addition, many system programs
make similar assumptions. For example, the UUID library
depends on time not going backwards in order for it to be able
to make its guarantees about issuing universally unique ID's.
Systems with broken system clocks, are well, broken. However,
broken system clocks, particularly in embedded systems, do
exist. If true, e2fsck will not abort a preen check if it
detects a last mounted or last write time in the superblock in
the future. This setting defaults to false.

It also appears that buggy_init_scripts is no longer an option. It's been replaced, and defaults to on:
From the changelog:

* Change e2fsck to accept superblock times to be fudged by up to 24
hours by default. Most distributions have fixed their init scripts,
but apparently now they have buggy virtualization scripts. I
give up, too many buggy user space set ups out there. (Closes: #557636)

man page:

accept_time_fudge
Unfortunately, due to Windows' unfortunate design decision to
configure the hardware clock to tick localtime, instead of the
more proper and less error-prone UTC time, many users end up in
the situation where the system clock is incorrectly set at the
time when e2fsck is run.

Historically this was usually due to some distributions having
buggy init scripts and/or installers that didn't correctly
detect this case and take appropriate countermeasures. How‐
ever, it's still possible, despite the best efforts of init
script and installer authors to not be able to detect this mis‐
configuration, usually due to a buggy or misconfigured virtual‐
ization manager or the installer not having access to a network
time server during the installation process. So by default, we
allow the superblock times to be fudged by up to 24 hours.
This can be disabled by setting accept_time_fudge to the bool‐
ean value of false. This setting defaults to true.

[dolphans1]

How I solved this issue on Mandriva, because I have a dual-boot system. The issue was my CMOS battery was going bad/dead and I set my time in WindowsXP64 to correct time, however when I booted into Mandriva and I noticed it had a future date of December 19, 2013 in verbose mode and it would hang and fail, and gave me the Superblock last mount time is in the future, which was a future date. Why it set that way is unknown to me.

In Windows I had set the to correct date and time, which at that time was today's date, a date of June 29, 2013, so what I did was I re-booted into WindowsXP64 and changed the date to December 19, 2013 (fake future date) in WindowsXP64, which allowed me to boot into Mandriva, with error message I had been receiving previously denying me the ability to boot into Mandriva and I set the correct date and time for today's date, June 29, 2013 and went back and re-booted into WindowsXP64 bit and synced the correct date and time.

d-1