Bug#785525: systemd fails to boot if non-essential block device is missing

[Thibaut Varène]

On 17 mai 2015, at 14:59, Thibaut Varène <varenet at debian.org> wrote:

> 
> On 17 mai 2015, at 14:57, Martin Pitt <mpitt at debian.org> wrote:
> 
>> Control: tag -1 wontfix
>> 
>> Hello Thibaut,
>> 
>> Thibaut VARENE [2015-05-17 14:41 +0200]:
>>> Just upgraded my system from wheezy to jessie. Boot stopped after initial reboot, with prompt to enter root password. After looking at the logs, it seems that systemd choked on this line of my fstab:
>>> 
>>> UUID="8633-12F1"	/media/WDX360	vfat	user,auto,utf8=no,iocharset=iso8859-1	0	2
>>> 
>>> That's a line I added for convenience whenever I plug a specific USB
>>> drive to the machine. Granted, it doesn't have the nofail flag
>> 
>> Indeed, that *and* it's marked as "auto".
>> 
>>> and it does have a 2 pass_no (instead of 0), but this never caused
>>> any problem in wheezy, so the new behavior, and the fact that it
>>> entirely halts the boot process (the machine isn't even remotely
>>> accessible) is quite a huge change from previous behavior...
>> 
>> It's a change indeed, but IMHO a correct one. Aside from "auto" and
>> "nofail" there is no other indication whether a file system in fstab
>> should be considered "essential" (in your terms) or not. That's
>> precisely what these flags are for. sysvinit might have not complained
>> about this situation, but that doesn't mean that I'd like to
>> proliferate that bug forever.
>> 
>> Hence I consider this a "wontfix".
> 
> A footnote in the release/upgrade instructions would have been nice. If that machine had been remote without OOB access, I'd have been screwed over, because something that never broke previous upgrades.

"because of"

While I'm there, your argument about what should and shouldn't be considered "essential" seems rather bogus considering all of that is made pretty clear by the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS

This also states that /media is for removable media, so a hard fail on anything below that mount point seems equally wrong.

I'm sure you won't change your mind, but I believe the current behavior of systemd is inappropriate. Then again, I suppose I can always switch back to a saner sysvinit.


> 
> T.