7

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.

Zac B
  • 841
  • 1
  • 15
  • 27
  • 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

3 Answers3

4

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

Try that int /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
}

This should remove the message, and correct the datas.

Gregory MOUSSAT
  • 1,737
  • 2
  • 25
  • 48
3

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

http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

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.

johnshen64
  • 5,747
  • 23
  • 17
  • 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
2

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

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 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