Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm persistently getting the "Superblock last mount time is in the future" error when booting CentOS 6. I've seen other questions which ask how to resolve this error, but I know exactly why it's occurring: our development/testing VMs regularly have their date set to times far from the present, and have all of their filesystems remounted.

What I want to know is: how do I disable all consistency checking for superblock mount time in centOS?

I've tried tune2fs -i 0 <device> and setting buggy_init_scripts=1 in /etc/e2fsck.conf and neither has worked; the problem persists.

share|improve this question
Why not just fixing your date/time? – Khaled Apr 12 '12 at 13:49
Because it changes all the time as a necessary part of our development and testing process. Same with the filesystem remounting. Some of the time changes affect the VMs' hardware clocks, some don't, but either way it is a regular event that is critical to our ability to test concurrency issues with our product. – Zac B Apr 12 '12 at 13:59
What are you doing that would require you to change the system-wide time? – Andrew M. Apr 12 '12 at 16:55
A lot of our site's code hits different parts/partitions of the database depending on the date. Our codebase is big, old, and ugly. The methods of acquiring the date are so varied (PHP date, fetch from a date that gets written to log files (don't ask me why), or just exec(date)) and so numerous that doing it right would take a lot of time. It's just easier to muck with the system date, especially since they're easily-rebuilt, low-value testing VMs. – Zac B Apr 17 '12 at 16:06
up vote 4 down vote accepted

buggy_init_scripts=1 only works if the time difference is smaller than 1 hour.

Try that int /etc/e2fsck.conf:


# 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 should remove the message, and correct the datas.

share|improve this answer
Perfect, thanks! – Zac B Apr 17 '12 at 16:02

It is better that you fix the vm datetime. It is quite a complicated issue actually if by vm you mean vmware.

if it is some other vm system, i think the issue would be similar.

turning off consistency check etc. is not advisable because they are there for a reason. a system with time being inconsistent will affect integrity in many other ways.

share|improve this answer
I know it's not advisable, but they're test environments, and if one of their filesystems actually does get borked, I can rebuild the whole environment in like 5 seconds. I'd never put something like this in production, but for testing I was hoping for a hack. – Zac B Apr 17 '12 at 16:04

Build the hwclock time set into your kickstart/build process.

share|improve this answer
If I could, I would. But the developers need to set the machines' dates to weird values multiple times, after kicking the systems. And it's not feasible to have a build's cleanup set the date back to a sane value because, no joke, we have a significant number of build failures that page fault the systems. – Zac B Sep 20 '12 at 20:56

Your Answer


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.