2

After building a minimal Raspbian installation with raspbian-ua-netinst, making an image off of it and flashing it on another SD card a few days later I get an Superblock last mount time is in the future fsck error for the root partition, which then throws me into a management shell.

The idea was to build a minimal image and base all of my subsequent installs on it, which will clearly be impossible if this something like this happens.

I found a few possible solutions to this, like disabling fsck, or making it assume a broken hardware clock. What I'm interested in is how does the official Raspbian avoid this kind of situation.

4
  • if this Pi is connected to the network then you can just use ntp to keep the clock up to date.
    – rob
    Jan 26, 2015 at 14:56
  • 1
    The problem is that it can't reach the network because it can't mount its filesystem. If it could, I wouldn't even have noticed the problem in the first place.
    – Dumitru
    Jan 26, 2015 at 14:58
  • 1
    The fix of first setting the system clock to the superblock last mount time plus a small amount seems reasonable when there is no battery backed clock. Given this was discussed a few years back I'd think it likely the patches have propagated and are what is in use - do you see something about fixrtc or similar in raspbian boot config? Jan 26, 2015 at 16:33
  • Did you make any changes to /etc/default/rcS my last line is #FSCKFIX=no on netinstall so it defaults to no (or is it yes), whereas in Raspbian (I use both) it is 'FSCKFIX=yes'
    – geoffmcc
    Jan 26, 2015 at 22:50

2 Answers 2

2

I had this error temporarily (after fixing SD card in a host PC). Fixed it by writing correct time into /etc/fake-hwclock.data.

It may work for you purpose to fix-up this file to some date beyond when the image was created, so the superblock timestamp is never seen to be in the future.

1

I've found that if I dd a typical RPi image to the SD card and then go straight to the RPi, I typically don't see this issue. But, if I decide to mount the card and manipulate it before moving it to the RPi, this happens every time.

After a bunch of investigation, I found that the problem is that when you mount your SD card on your Linux computer, the system helpfully writes the date on which the card was last mounted to the card itself. (I don't know why it's a good idea to write to a card when the only action being performed is mounting.) And when you actually write to the card, it updates the last written date on the card as well.

So, when you insert the card into the RPi (which has no RTC) to startup, the boot process helpfully compares the date on the card to the RPi clock, which is stuck at its default (I forget what it is, but it's several years back). I have no idea why this date mismatch is catastrophic, but it is, so the boot halts.

Now, if you have a keyboard and display on your RPi, you'll see the helpful suggestion to run fsck (which I assume works if you do it on the RPi itself, although I haven't tried it, and running it on the legitimate-dated Linux machine definitely does not help). But, if you are running your RPi headless, and maybe you've just reflashed the card or updated it in a way that's more convenient than ssh, you may just find that the board doesn't boot for an invisible reason.

Fortunately, there is a way to override the decision to make the date mismatch important enough to halt the boot. Add the following file to your system (apologies that I don't know the originator of this to credit them), and things will boot fine, no matter the date:

/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
}

My primary use case is headless, so it wouldn't bother me if this became standard issue for all RPi images.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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