EDIT: Try Ctrl+Alt+Del before hard shutdown if you find yourself in this situation!
I have an ext4 data drive that I mount automatically at boot. If the drive isn’t there the system goes into emergency mode and the only way I can describe it is that it completely locks up the system and forces a hard shutdown.
That is to say, emergency mode says, that I can reboot or boot into default mode (by pressing exit) at the prompt, but then it said can not access console, root account is locked. I could do nothing at all other than press Enter which would just redisplay all that information again. Seeing as I could get nothing worked, I held down the power button.
George N. White III helpfully explained fstab and mount. Sadly, after the hard shutdown my hard drive makes a horrible grinding noise. But I would still like to know if in the future I can prevent this from happening.
I’ve seen this from Microsoft: " Most distributions provide the fstabnofail or nobootwait parameters. These parameters enable a system to boot when the disk fails to mount at startup"
I’ve seen mentions of nobootwait around the internet, however, I don’t see it in the man page and I know sometimes Linux commands have undocumented options (can’t remember which but I know I used some for some program a few months back) but if that is the case, I don’t want to try an undocumented option on something that can literally damage hardware.
I have seen nofail option but the explanation for it does not seem assuring:
nofail: do not report errors for this device if it does not exist.
nobootwait: …applied to non-remote filesystems to explicitly instruct mountall(8) not to hold up the boot for them
Just because an error is not reported, I don’t understand how another part of the boot process can’t lock up the system because a certain drive wasn’t found.
So was wondering if either of these options will work or if I should attempt something else? Thanks for any help anyone can provide.
The command
mount -a [-t type] [-O optlist]
(usually given in a bootscript) causes all filesystems mentioned in fstab (of the proper type
and/or having or not having the proper options) to be mounted as indicated, except for
those whose line contains the noauto keyword.
Yes, just realized it was something to do with that. I’ll try to update the title and post to reflect the issue better.
I’ve read in a few places to use ‘the undocumented’ nobootwait option in fstab but as it isn’t in the man page I’m not sure if I should. I’ve also seen from Microsoft: " Most distributions provide the fstabnofail or nobootwait parameters. These parameters enable a system to boot when the disk fails to mount at startup"
nofail is in man fstab but “do not report errors for this device if it does not exist.” seems different from “nobootwait which can be applied to non-remote filesystems to explicitly instruct mountall(8) not to hold up the boot for them;”
Does the nofail option actually do what Microsoft says?
It sounds like it won’t report a failure, but just because a failure isn’t reported, doesn’t mean a different part of the boot process will go: ‘drive not found? Lock system’. I don’t properly get why it has to lock-up, rather than allow you to try to fix the issue or circumvent the issue if it isn’t a system’s critical drive, but that is not the issue here.
The nofail option seems most commonly used since it allows the system to ignore mounting of a missing drive during boot. The comment quoted makes it human readable but really does not do justice to what actually happens.
Any file system in the /etc/fstab file will be automatically mounted during boot. If it fails to mount the system halts at that point and cannot continue due to the error. In the simplest terms, using the nofail option tells the system to ignore any errors on mounting and to continue booting even if the device cannot be mounted properly.
This is not related to the question so I will not pursue it but in case someone else ends up here.
nofail works great for an unencrypted drive but for an encrypted one (at least on Fedora) it is not that simple. After a few seconds it continues with the boot process even if you have not finished entering the passphrase.
I read that the x-systemd.device-timeout=<number of time units> option in fstab should make it wait however long was desired to enter in the passphrase. Although from reading the manpage I wonder if it should be ``x-systemd.mount-timeout=` instead. Either way, they did not work for me.
I thought I was doing something wrong, then got hopeful when I saw [SOLVED] Is systemd x-systemd.device-timeout broken? making me think it was broken, but that person forgot nofail and I have nofail. I tried 0 and non-zero values for the last field, as it was mentioned in there, but did not help.
I tried 300, 300s, 5min (If I understood the manpage correctly), 12h none of those worked.
Note that I tried all of those for both options to no avail.
Someone mentioned that systemctl daemon-reload was needed for changes to take effect so, off I went trying all that again and still did not work.
If someone sees this maybe they can tell me that I read those options wrong and point out the correct option, if so thank you so much! But just wanted to let someone know what to expect if they try nofail and maybe they can build upon this from what I have.
Continued reading seems to suggest that these options have absolutely nothing to do with the timeout (by my estimations 3 seconds) of when entering in a passphrase, so if anything, maybe someone can skip this, if they get same search results as I did and continue to look for the correct option to change those few seconds into however much time they might need to enter in their passphrase.
That is a good indication of a misconfiguration.
Drives that are encrypted should not contain the nofail option for the exact reason you note.
It would be user error to do that.
The question was about a non-accessible drive (which I interpret as a disconnected drive) and not just about one that fails to mount.
If the disconnected drive is also encrypted then it must indeed be managed differently – i.e. it must be reconnected after the boot has completed or otherwise managed in a way that allows unlocking its content.