Bug#756903: systemd: Boot hangs if filesystems unavailable

Cameron Norman camerontnorman at gmail.com
Sun Aug 3 23:08:04 BST 2014


On Sun, 03 Aug 2014 22:08:59 +0200 Michael Biebl <biebl at debian.org> 
wrote:
 > 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.
 >
 >  [snip]
 >
 > > 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.

With mountall/Upstart, there is a nobootwait option supported. I 
believe the behavior is similar to nofail, except that mountall will 
emit the filesystem event before finishing mounting the filesystem as 
well as not GAF about success/failure. Do you know if systemd supports 
this? To implement this in systemd I believe you would make the 
generator for mount units from fstab not add Before=local-fs.target or 
Before=remote-fs.target if the nobootwait option is used. This solves 
the problem that systemd does not know which filesystems are essential 
or not.

Best wishes,
--
Cameron Norman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140803/cabec73f/attachment-0002.html>


More information about the Pkg-systemd-maintainers mailing list