Bug 86062 - x-systemd.device-timeout=0s causes halts boot in endless wait due to 's' suffix
Summary: x-systemd.device-timeout=0s causes halts boot in endless wait due to 's' suffix
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-09 15:00 UTC by Jerome
Modified: 2018-06-11 15:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.