Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

> 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