1

If the raspberry pi doesn't shut down cleanly, it forces a fsck at boot. My filesystem is on a 64GB micro SD card and it takes quite a while to fsck. But before that can finish a couple of services timeout, so it ends up in emergency mode. This even though the filesystem is really fine.

This is a problem for me because I want this raspberry pi to run unattended and headless. If it goes into emergency mode after a power outage it'll just disappear from the network and I won't be able to do anything about it until I can physically access it again. Raspbian shouldn't require that much care and attention.

I can reproduce the problem by forcing it to check the filesystem with "sudo tune2fs -c 10 -C 15 /dev/mmcblk0p2". (If you do this, note that this causes it to always go to emergency mode. So make sure you can log in to the console to switch it back again with "sudo tune2fs -c -1".)

Googling the problem, it seems that some other people have run into this:

https://www.reddit.com/r/raspberry_pi/comments/3zop09/rpi_boots_into_emergency_mode_how_do_i_remove_it/

It's also been suggested that the fsck is unnecessary:

https://bbs.archlinux.org/viewtopic.php?id=213548

But since this is my root filesystem I can't remove it from fstab. I tried adding "noauto,x-systemd.automount" to the options in fstab, but it didn't change anything.

Does anyone have a recipe for any of these?

  • lengthening the timeout
  • preventing an fsck on startup
  • preventing the filesystem being marked as dirty on unexpected power loss
3

If you do not want to take the risk of corrupting your SD Card by disabling fsck on startup you can use your first suggestion: "lengthening the timeout" on starting services. With systemd you can easily change DefaultTimeoutStartSec in

/etc/systemd/system.conf

In man systemd.service you will find:

TimeoutStartSec= Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "infinity" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5)).

  • I'm glad you weighed in on this one. I learn more about systemd each time I read one of your answers :) +! – Seamus Sep 1 '18 at 22:12
  • Yep, that's exactly what I wanted. I extended the timeout to "5min" and it boots cleanly now. Thanks! – Matthew Exon Sep 3 '18 at 11:23
2

Like many other activities, booting is now controlled by systemd processes. I suspect that there is a way to give fsck additional time to complete, but I don't know enough about that to advise. However, systemd still depends on /etc/fstab for its instructions. And so, without rendering any opinion on the wisdom of this (see note), following is a "recipe for [...] preventing an fsck on startup":

Edit /etc/fstab as follows:

FROM:

PARTUUID=whatever  /               ext4    defaults,noatime  0       1

TO:

PARTUUID=whatever  /               ext4    defaults,noatime  0       0  

Note:
@Ingo makes a valid point in his comment below this answer. I can't comment on the negative opinions wrt systemd rendered by others in the thread you referenced, nor should I speculate on the "cost" of a failure of your root filesystem that could have been avoided by running fsck. I feel these are matters of circumstance and opinion, and since this is your data, only your opinion is valid.

If data loss matters to you, you should put a backup system in place. And if you inhibit fsck on boot as shown here, you should also take your RPi offline periodically to run fsck on the SD card. If, on the other hand, booting quickly is a priority, and your usage is such that the data and files on your system are easily replaced, perhaps it's not worth the bother. Again, these are choices only you are qualified to make.

  • Huh.. you should really spend a few words about this setting. I could make the SD Card complete unreadable after a time without fixing file system errors. Anyway +1 – Ingo Sep 1 '18 at 21:26
  • @Ingo: You're right - I should have; my disclaimer is rather gutless :) – Seamus Sep 1 '18 at 21:44
  • 1
    Upvote to this one because it is also a solution in my case, where data loss is fine but failing to boot up properly is a pain. I tested it and it works. In the usual case there's nothing wrong with the filesystem anyway. Even if there is corruption there's at least a good chance it'll boot up until I can reach the thing for maintenance. The other solution is cleaner, but disabling the fsck entirely could be useful for some people e.g. if reducing outage length is important. – Matthew Exon Sep 3 '18 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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