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.

MasterOfTheTiger
  • 103
  • 3
Shawn Xie
  • 163
  • 1
  • 1
  • 6

5 Answers5

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.

womble
  • 95,029
  • 29
  • 173
  • 228
  • I'm sure it's not a problem of hardware clock. I had checked it. – Shawn Xie Oct 06 '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 09: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 04 '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.

user65258
  • 21
  • 1
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. ;)

PEra
  • 2,825
  • 17
  • 14
  • I don't dare to fsck. But I hate have to fsck everytime when booting. – Shawn Xie Oct 06 '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 06 '09 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 '20 at 23:12
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.

Anuj Garg
  • 21
  • 1
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?

Shawn Xie
  • 163
  • 1
  • 1
  • 6