5

I'm using my raspberry pi as a NAS mostly. If on reboot it does a non-clean fsck the pi dumps to a terminal. I don't have it hooked up to a monitor or keyboard so this is a pain for me to actually access it.

Can I set a setting telling it to never go to a terminal and instead just continue booting so I can ssh in and fix the problem?

5
  • 1
    Sure, don't automount the drive. You can't use it until fsck has run anyway, so put 'noauto' in fstab, boot, ssh in and mount it manually. Then you can watch fsck go if it is required.
    – goldilocks
    Feb 16, 2013 at 20:24
  • Just wondering, does that output also appear in dmesg ? wiki.ubuntu.com/AutoFsck might help in disabling it.
    – Lord Loh.
    Feb 21, 2013 at 6:25
  • This question is a possible duplicate of: raspberrypi.stackexchange.com/questions/7853/…
    – Arne
    Jun 13, 2013 at 7:24
  • Seems this question is older. But the other question has a seemingly good answer.
    – Arne
    Jun 13, 2013 at 7:25
  • I've opened a bug with Raspbian for this issue: bugs.launchpad.net/raspbian/+bug/1212020 Aug 13, 2013 at 23:06

3 Answers 3

3

There's no setting that you can set but you can modify the boot scripts. Rather than allowing it to run fsck with the current options, change the script to execute it like this:

fsck -A -a -y

The first -A indicates check all filesystems. The -a says "Fix it without asking" and the -y similarly will answer "Yes" to any question it wants to ask you.

Of course, exercise extreme caution... While fsck usually works just fine you do run the risk of it making things worse. :)

4
  • There is a setting in /etc/fstab file to avoid auto file system check operation at boot time. 6th field should be 0 (zero) to avoid filesystem check at boot time (wiki.archlinux.org/index.php/Fstab) Aug 13, 2013 at 14:47
  • That's true. However, it's generally better to allow it to run, even in automatic mode, than it is to never allow it to run. Otherwise, correctable issues can add up to serious and non-correctable corruption! Aug 13, 2013 at 18:13
  • 1
    Wow, this should be flagged as a bug in the OS. The RasPi is used so much as a pseudo-embedded controller, and those things must be able to deal with unexpected crashes without human intervention. The OS should provide an easy way to configure it so that no user interaction is required after a crash. Aug 13, 2013 at 22:57
  • No, I disagree. This is expected behavior for any UNIX operating system; if this is occurring it's a clear indication that the system is not being properly shut down. The OS is doing what's expected. Unfortunately, if you're running headless, you can't tell. Aug 14, 2013 at 11:12
0

Set up a serial console? And use that for when it goes wonky?

1
  • I just want it to boot without that drive mounted and then I'll fix it later. Mar 15, 2013 at 6:35
0

I just ran in the same issue with the extra problem that the Raspberry Pi is running with a 3G in a remote location.

My conclusion after examining how this can be avoided, I conclude that the one has to modify the startup scripts by modifying the call to 'sulogin'. When 'fsck' returns with error, 'sulogin' gets called without a time out. So I edited '/etc/init.d/checkfs.sh' and '/etc/init.d/checkroot.sh' so that 'sulogin' also gets a '-t' parameter in all cases (I put 'sulogin -t 60 $CONSOLE' where you read 'sulogin $CONSOLE').

I can't see a clean way to put a parameter in '/etc/default/rcS'. You can set 'FCSKFIX=yes' in there, but that will not avoid 'sulogin'. A hack could be to define CONSOLE like this 'CONSOLE="-t 60 "$CONSOLE"' but that could have unwanted sideeffects as CONSOLE is also used in other locations.

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.