2

I have the very familiar problem eth0: kevent 2 may have been dropped when torrenting to a usb hard drive and already increased the memory and disabled the turbo mode, however occasionaly my Pi still 'drops' it and needs to be rebooted. The problem is that once I reboot I get the following: 

[...] Checking file systems...fsck from util-linux 2.20.1
fsck.ext4: Unable to resolve `UUID=[insert UUID here]`
fsck died with exit status 8
failed (code 8).
[FAIL] File system check failed. A log is being saved in /var/log/fsck/checkfs if that location is writable. Please repair file system manually. ... failed!
[warn] A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. ... (warning).
Press enter for maintenance(or type Control-D to continue):

And now it waits for keyboard input, which is annoying because it runs headless and no keyboard is attached (and ssh isn't started yet). How can I get the Pi to continue booting (without interaction)?

Setting the fsck option in /etc/fstab to zero obviously works, but I'd rather have it sent me an email and continue booting (I already have exim set up).

Improve this question

1 Answer 1

Reset to default
3

You can set the fsck and mount up at some point in the boot process yourself to get around this. The simple version would be if there's nothing else in the boot process which requires the drive, in which case you can add to /etc/rc.local (I'm presuming debian, btw; arch using systemd will be somewhat different).

fsck -n UUID=...
if [[ $? != 0 ]]; then
    logger -p user.warning "/etc/rc.local: fsck fail $?"
else mount ....
fi

I think you will need the '-n' since fsck will probably consider itself to be running non-interactively here (you could also try '-y'). This means it won't repair anything, it will just fail if something's wrong. Redirecting the output to a log would also be useful.

Note that this means you have to put a 0 in fstab for fsck and the noauto option so that it is not yet mounted when this runs (which rc.local runs after everything else).

If there's something in the boot process that does require it, you'll have to add your own service at an appropriate point (on debian see /etc/init.d/README).

You can also use udev rules for this, btw.

Improve this answer
2
  • Thanks for your suggestion, in this way it is also possible to do something with the exit status, nice!
    – Gerhard Burger
    Mar 18, 2013 at 8:10
  • 1
    @GerhardBurger : Yeah -- and actually fsck may fail there if it sees itself as being run non-interactively. I'll edit some stuff in to flesh those possibilities out.
    – goldilocks ♦
    Mar 18, 2013 at 17:08

Your Answer

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

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