3 ms·

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? My (least) favorite SystemD

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that. However, when you try to boot after a disk has been removed from the system, it won't. Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed. The default setup on a lot of Linux distros won't boot if you remove a non-system disk. I like SystemD more than the old init system(s), but there are some really, really dumb decisions that have been made along the way.

jasonjayr 5y ago
Yep. Hit that one too. Learned the hard way the need for the 'nofail' flag in 'fs_mntops' field, which was undocumented in the man page in the early versions ...
gigatexal 5y ago
Ok that’s a bit much. Why is SystemD encroaching on the fstab??
- jcelerier 5y ago
  Because systemd services can depend on mount points or cause mountpoints to come up dynamically, in a way that pure fstab does not support, e.g. for containers. So (as far as I understand) fstab is now simply an input to the actual mount system.
- Denvercoder9 5y ago
  It's not encroaching on fstab, it's using it as input during boot, because mounting is intimately coupled with service ordering. Think about services that reside on a network filesystem: the network has to be up to mount the filesystem, but the network in turn can require arbitrary services to run, which can require other local filesystems to be mounted. You can't get configurations like these to work without coupling mounting and service ordering. It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.
Denvercoder9 5y ago
> Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed. That's indeed an unfortunate situation. systemd allows you to set the SYSTEMD_SULOGIN_FORCE environment variable for the rescue.service to override this behaviour and always give you a rootshell. It's an open bug for the Debian installer to set that variable by default if installing without a root password (#952450).
yrro 5y ago
If you want your system to boot if a filesystem can't be mounted, use the longstanding nofail option on the noint point.

jasonjayr 5y ago

Yep. Hit that one too. Learned the hard way the need for the 'nofail' flag in 'fs_mntops' field, which was undocumented in the man page in the early versions ...

gigatexal 5y ago

Ok that’s a bit much. Why is SystemD encroaching on the fstab??

jcelerier 5y ago
Because systemd services can depend on mount points or cause mountpoints to come up dynamically, in a way that pure fstab does not support, e.g. for containers. So (as far as I understand) fstab is now simply an input to the actual mount system.
Denvercoder9 5y ago
It's not encroaching on fstab, it's using it as input during boot, because mounting is intimately coupled with service ordering. Think about services that reside on a network filesystem: the network has to be up to mount the filesystem, but the network in turn can require arbitrary services to run, which can require other local filesystems to be mounted. You can't get configurations like these to work without coupling mounting and service ordering. It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.

Denvercoder9 5y ago

> Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed. That's indeed an unfortunate situation. systemd allows you to set the SYSTEMD_SULOGIN_FORCE environment variable for the rescue.service to override this behaviour and always give you a rootshell. It's an open bug for the Debian installer to set that variable by default if installing without a root password (#952450).

yrro 5y ago

If you want your system to boot if a filesystem can't be mounted, use the longstanding nofail option on the noint point.