Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm working with a system where we want to allow users to play around with the date and time if they want, and where reboots may happen arbitrarily. This is fine, except for one thing: if there's a large time jump backwards, the following error appears on reboot:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

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

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

…and then the boot hangs waiting for user console input, and even once console access is gained, requires a root password to continue.

This is decidedly less than ideal. Is there any way to either skip the check or force the check to happen automatically on reboot?

Google has only provided help that requires running fsck manually if/when this is hit, which is not what I'm after. Running fsck manually after setting the time doesn't work as the filesystem is still mounted at that point, and just disabling fsck entirely is less than ideal.

I'm using RedHat 6.

Update: The solution I'm currently going with is to hack fstab to disable fsck checking on reboot. I'd tried editing the last mount time on the disks using debugfs, which works fine for ext3 drives, but appears to fail inconsistently on ext4.

share|improve this question

4 Answers 4

up vote 10 down vote accepted

I was going to suggest hacking e2fsck to disable the specific checks for a last mount time or last write times in the future. These are defined in problem.c / problem.h, and used in super.c. But in looking, I discovered that E2fsprogs 1.41.10 adds a new option to /etc/e2fsck.conf called broken_system_clock. This seems to be exactly what you need, and since you're using Red Hat Enterprise Linux 6, you should have 1.41.12, which includes this option. From the man page:

   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.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Yes, the man page can't spell "heuristics". Oops. But presumably the code works anyway. :)

share|improve this answer
    
That looks fantastic, save that the man page implies it only affects ext2 and ext3, and I'm using a combination of ext3 and ext4. Still, I'll go try it now, as if it works, it's exactly what I'm looking for. –  me_and Mar 17 '11 at 10:35
    
It works! Including on ext4. Thank you! –  me_and Mar 17 '11 at 14:01

I doubt there's a way to remove this check specifically, short of modifying the source code. Ignoring all errors from fsck sounds dangerous, what if there was some other problem?

Therefore I'll suggest the following workaround: change the boot scripts to set the system date to some time in the future (say 2038-01-18 on a 32-bit machine) just before running fsck, and read it back from the hardware clock afterwards (hwclock --hctosys, with more options as needed depending on your hardware and use of GMT in the hardware clock.)

share|improve this answer
    
Would this not mean the next time around that there'd be a window in which we could hit the same bug again? i.e. the last mount time is 2038-01-18, so if the current time is set to that too, there's a race condition in which we're (as far as the system's concerned) trying to mount before the last mount again. –  me_and Mar 2 '11 at 14:02
    
@me_and: Yes, I'm afraid my kludge won't help against malicious users. If that's what you're up against, patching fsck looks to be the best option. –  Gilles Mar 2 '11 at 19:53

This sounds like it should be run in a virtual machine, where you can have more control (or just revert to a snapshot).

share|improve this answer
    
Running in a VM is really not an option for us, and in any case just reverting to a snapshot means we remove all the other state the user may have set up. –  me_and Mar 2 '11 at 13:10

Here is a solution that worked great for me:

Create /etc/e2fsck.conf:

[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
}

More on this fix here:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.