5

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

I have googled but found nothing guiding for me.

Improve this question
3
  • 1
    Is the system time currently correct? Could just be a nearly-dead CMOS battery.
    – Tim Post
    Oct 6, 2009 at 5:29
  • I'm sure it's not.
    – Shawn Xie
    Oct 6, 2009 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, 2009 at 11:27

5 Answers 5

Reset to default
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.

Improve this answer
3
  • I'm sure it's not a problem of hardware clock. I had checked it.
    – Shawn Xie
    Oct 6, 2009 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, 2009 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, 2017 at 23:28
2

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

Improve this answer
3
  • I don't dare to fsck. But I hate have to fsck everytime when booting.
    – Shawn Xie
    Oct 6, 2009 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, 2009 at 11:57
  • If it's something like the root partition you can make it read-only to run fsck (mount -o remount,ro /) and after fsck reboot
    – rakslice
    Aug 26, 2020 at 23:12
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.

Improve this answer
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.

Improve this answer
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?

Improve this answer
1
  • It likely occurred because you had booted into another OS which set the hardware clock to non-UTC.
    – hackerb9
    May 29, 2021 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .