--- Begin Message ---
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
--- End Message ---