Bug 86062

Summary:	x-systemd.device-timeout=0s causes halts boot in endless wait due to 's' suffix
Product:	systemd	Reporter:	Jerome <ce0c5679c447a438>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Jerome 2014-11-09 15:00:46 UTC

The short: an fstab entry specifing "0s", note the 's' suffix makes the systemd startup wait indefinitely, and I was unable to get to rescue/maintenane mode without booting through a USB stick and manually mounting/editing fstab.

systemd: 217 (systemctl -version)
kernel: 3.17.2-300.fc21.x86_64

fstab entry:
/dev/fedora/storage1 /mnt/storage  ext4  defaults,x-systemd.device-timeout=0s 1 2

What's wrong with that?
- systemd.mount(5) suggests '0s' is acceptable. 
- it's also unclear if 0 means unbounded delay or no delay allowed.
- it bricks the system, rescue prompt is unreachable, requires boot from usb stick to fix.

extra info:
The startup sequence spits out a spurious "You're in maintenance mode..." dracut prompt I couldn't interact with, but the systemd process continues for a few steps until it hangs shortly after with:
"A start job is running for dev-mapper-storage1... (time / ETA)"

Comment 1 Jerome 2014-11-09 15:03:55 UTC

I'm guessing the problem had to do with the parsing of the option, but I'll add that this was an ext4 fs on an lv sitting on top of luks on a seperate HD added after install. I setup /etc/crypttab accordingly and fiddling aside, the final differene between boot and hang was that 's' in the fastb mount options.

Comment 2 Zbigniew Jedrzejewski-Szmek 2018-06-11 15:06:54 UTC

https://github.com/systemd/systemd/commit/0004f698df

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.