> Well, I consider the sysvinit behaviour buggy and unfortunately this > lead to broken fstab configurations in the past.
There are 2 changes here: 1- systemd seems to *wait* for the device to be available, whereas the old scripts just failed right away if the device was absent. 2- if the mount fails, this is considered by default as a fatal error. Which of those 2 was "buggy" in sysvinit? The lack of wait or the fact that it moved on upon failure? I like the idea of mounting/fscking partitions without blocking other unrelated boot steps, so I'm OK with adding boot options to help systemd do a better job, but blocking the boot just because some random fstab entry has an error is really obnoxious (it took me a while to fix my machine after installing systemd-sysv because of such an fstab entry referring to a disk that was not connected. Thank god there is "break=mount"!). Here are my suggestions: - In the absence of an explicit request to "bootwait", systemd should not wait for a device to appear, or at least not anywhere near 90s, especially if it is holding back the whole rest of the boot process. - If a mount fails, keep on booting. And then do your best to try and bring this problem to the attention of someone (mentioning the "nofail" option in that same message). Only stop the boot if the partition is explicitly marked as "critical" or "stoponfail". The second part is really important, because in 99.9% of the cases, it's much better to keep on booting, even if the resulting system won't be fully functional: it's likely to be a lot easier to fix the problem with a "half booted" machine than a "not booted" one. E.g. If the /home partition is missing, the machine might be largely unusable, but I should usually still be able to log into it remotely, fix up the partition or fstab entry, and reboot. But with the current "stop on fail" behavior, I don't get such a chance. Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org