Bug#756903: systemd: Boot hangs if filesystems unavailable

[Michael Biebl]

Control: -1 important

Am 03.08.2014 12:21, schrieb Tony Green:
> Since my machine recently updated to using systemd, I have experienced a number
> of occasions when it would just hang at a blank screen when booting.
> 
> After some searching I managed to work out how to get back to having verbose
> output during the boot process, which showed me that the system was refusing to
> initialise because filesystems specified in /etc/fstab were not available
> (either NFS filesystems, when my network was playing up, or a USB external
> drive which had not spun up fast enough).
> 
> It seems that systemd regards ANY missing filesystem as being a fatal error,
> whether or not that filesystem is actually essential to the boot process.
> Although this is certainly valid if vital partitions such as / or /usr can't be
> mounted, it's unhelpful for NFS or external partitions.

That's correct. Systemd waits for 90 seconds for devices listed in
/etc/fstab to show up. Since it doesn't know (unless you tell it) which
devices are essential, it drops you into a rescue shell afterwards to
examine the situation (unfortunately emergency mode currently has some
issues, but we are dealing with that in a separate bug report).

> Given the default result of a blank screen with no information about what's
> gone wrong, this could be very problematic for less experienced or confident
> users if it goes out beyond Debian Testing.

v209 and later will have slightly improved behaviour here.
Even if the default is to boot in quiet mode, systemd will switch into
verbose mode as soon as a unit fails to load or a timeout occurs.

> As a workaround, I have been able to ensure my system boots OK if any of these
> filesystems can't be mounted by adding "noauto" to /etc/fstab and then mounting
> the filesystems via /etc/rc.local instead.

The better alternative in your case (i.e. mount if available but don't
fail otherwise) is to mark the file systems as "nofail". See man fstab.

> I feel that a more robust (and set up by default) fix to this is needed before
> systemd goes mainstream on Debian, as this aspect of systemd is somewhat less
> reliable than on the old init system.
> 
> Please feel free to ask for any more information if it may help fixing this.

Well, I consider the sysvinit behaviour buggy and unfortunately this
lead to broken fstab configurations in the past.
Imho there is no robust and reliable way to determine which file systems
are essential and which are not (but I'm happy to be proven wrong).
E.g. you might have a mysql server storing its databases on a
non-standard location . Failing to mount such a partition could lead to
data loss, etc.

I think it's better to simply fix-up /etc/fstab once and be done with that.

We can try to improve the documentation in that regard (wiki/release
notes/ README.Debian) and maybe add a preinst check which tries to
detect non-existing devices upon installation.
The latter obviously isn't a foolproof method, as in your case you might
actually have your external USB drive attached during installation but
not during reboot.

Comments on how to address this are welcome.

Michael






-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140803/35374187/attachment-0002.sig>