3

Yesterday, I encountered a confused problem. During booting, the system complained that the superblock last mount time is in the future and ask me to fsck. I have used Debian Squeeze for months and encountered the problem the first time. I wonder if it's a problem about UTC.

I have googled but found nothing guiding for me.

  • Is the system time currently correct? Could just be a nearly-dead CMOS battery. – Tim Post Oct 6 '09 at 5:29
  • I'm sure it's not. – Shawn Xie Oct 6 '09 at 11:24
  • I had checked the BIOS time, which is same as OS. I have fsck for several times, but just one time fsck prompted to ask to input yes/no to fix a fault. – Shawn Xie Oct 6 '09 at 11:27
5

This can (and usually does) happen when the hardware clock dies, or else when the hardware clock was accidentally set in the far future sometime in the past (and has since been brought back into line). The former is far, far more common than the latter.

Make sure the machine's system and hardware clocks are both accurate now (run hwclock), then take the machine down in a maintenance, turn it off, pull it's power (physically disconnect it from the mains), wait a couple of minutes, then start it up again. Jump into the BIOS and check the time there. If it's still correct, then it's most likely to be a mis-set hardware clock and it probably won't happen again. If it's now wrong (probably set to Jan 1, 1988 or some other "round" time), the CMOS battery has died and you should replace it before setting the time correctly via the BIOS and booting the machine again. Keeping spare BIOS batteries around (our DC toolboxes each have a box of them) is always a good idea.

  • I'm sure it's not a problem of hardware clock. I had checked it. – Shawn Xie Oct 6 '09 at 11:23
  • I have read some docs about the timezone setting in Linux and Windows(my computer is multi-OS) and now I think it's caused by the different UTC setting between Linux and Windows. – Shawn Xie Oct 14 '09 at 9:54
  • Yes to the above: in a multi-OS set up I fixed this by booting Windows (which was still working) and setting the Windows OS to UTC, adjusting time manually to local time. – Tfb9 Jun 4 '17 at 23:28
2

On my Linux Mint Debian Edition (LMDE), Using Cook Schelling's answer above I edited /etc/default/rcS as administrator and changed the "FSCKFIX=no" to "FSCKFIX=yes"

When I rebooted, the problem was fixed.

Now, if I change the clock in BIOS setup, the system will automatically fix any "Superblock last mount time is in the future"-type problems.

2

It is quite simple issue. And simple is it's resolution.

  • Change date to new one.

    $ date -s "2 OCT 2016 18:00:00"

  • Run fsck check without auto mode and enter 'y' for correcting issues. In this case that will remove lock.

    $ fsck

  • Ctrl+D will restart your server. This should make your server startup properly.

  • For later check from where your system time is getting sync from and check UTC settings etc.

All the best guys.

1

...and if the clocks are correctly set, just run fsck. Don't be afraid. It's a testing distro - maybe they messed something up. ;)

  • I don't dare to fsck. But I hate have to fsck everytime when booting. – Shawn Xie Oct 6 '09 at 11:21
  • It should run just once and that's it. If it re-occurs, it's more likely a BIOS battery outage. – PEra Oct 6 '09 at 11:57
0

I have found the resolution. I edited /etc/default/rcS: changed the line

UTC=no

to

UTC=yes

Then reboot and found it's OK.

I remember UTC's default setting is "yes" and I had changed it to "no". It seems to be my mistake. However, why it had worked correctly for a long time until quite recently?

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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