Hi. On Thu, Jul 15, 2021 at 11:30:10AM -0400, Stefan Monnier wrote: > Greg Wooledge [2021-07-15 07:00:40] wrote: > > On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote: > >> "nofail" is really needed for removable devices, because whoever > >> designed systemd made an "interesting" decision to halt the boot process > >> (i.e. host is inaccessible by network, console access only) even if a > >> single filesystem mentioned in fstab fails to mount. > > This was the traditional behavior before systemd, so one can't really > > fault systemd for continuing the practice. > > That's not my recollection. AFAIK before systemd, you'd just get an > error message and the boot would just (try to) continue.
My words exactly. > I don't think systemd's decision is bad. You have a remote server. You modify fstab on that server. You reboot a server after that, and maybe a lot of time had passed since fstab modification. Now you have a system that's inaccessible via SSH/VNC/whatever network protocol you're using for remote access. Good luck unbricking this system, especially if it does require a road trip. Or paying for renting KVM. Or soldering UART, because manufacturer haven't exposed it to the end user. I cannot call that an improvement, because I do remember how it used to work in Debian before systemd. To systemd's defence - RedHat version of sysvinit did exactly the same in this regard. Could be worse, I guess. One can render modern AIX unbootable by simply adding inaccessible NFS mount to /etc/filesystems (they call /etc/fstab this way). At least systemd is "smart" enough to avoid such pitfall. > But I think it's implementation is not good enough: it should offer > some kind of simple "continue y/n?" prompt. > [ "Simple" for the user: the implementation might be not so simple. ] That'd change nothing important, really. You'd have to be at the console to answer such question, you cannot just boot somehow and fix things after via SSH. > To be honest, I've added the `nofail` pretty much everywhere and hence > haven't faced this problem recently, so for all I know, the > implementation has already been improved. Nope, it did not. I've faced similar problem just two days ago. >From the upstream POV the current behaviour is correct, so there's nothing to improve. Reco
