Bug 82733 - Duplicate target entry in /etc/fstab renders system unbootable
Summary: Duplicate target entry in /etc/fstab renders system unbootable
Status: RESOLVED WONTFIX
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium critical
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-17 15:17 UTC by Ian Greenhoe
Modified: 2014-08-21 12:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Ian Greenhoe 2014-08-17 15:17:29 UTC
After updating my Debian system to systemd, I discovered that it was unable to boot (going into emergency mode instead) due to two entries in my fstab being directed to mount at the same location.

This is deliberate. This is intended. The two lines in my fstab are for two separate 3 TB USB3.0 drives which I use for backing up the system. One of those drives lives in my house, and the other lives in my safety deposit box, and they get swapped monthly. The two drives will never be connected to my system at the same time.

Prior to this, automount would complain about not being able to find one or the other. This is expected.

This is severely broken behavior.
Comment 1 Lennart Poettering 2014-08-18 17:36:24 UTC
We don't support multiple entries for the same mount point in /etc/fstab. This used to somewhat work on classic "mount -a", but it actually is not only incompatible with systemd, but with many other software that parses /etc/fstab, too.

Moreover, the scheme you describe cannot really work either, since on modern hw there's usually no time known at which devices have to have shown up. Especially on USB devices can take any time they like to initialize (this fact is used on android for example, which only show up on USB after the user got asked interactively on the device for confirmation). Now if you list both devices in your fstab, then the this tells the system to wait for the devices to show up, which means you#d have to plug in both, and otherwise would have to endure a lengthy timeout. Or you turn off the timeout by adding "nofail" to he options, but in that case it might happen that neither shows up and is mounted at boot.

My suggestion to do this properly is by only having one line for the device in /etc/fstab, and reference the devices by a single /dev/disk/by-label/ link or suchlike, and use the same label on both devices. That way it doesnt matter which one is plugged in, the one that's plugged in will be waited for and be mounted.

Sorry, if this change tripped you up, but the old scheme really only worked out of luck, and is not supported this way in systemd. Sorry.
Comment 2 Ian Greenhoe 2014-08-21 03:35:56 UTC
If you disagree with this scheme, that's OK.

HOWEVER... detecting something like this should in NO WAY force the system into single user emergency boot mode. That should be reserved for things like not being able to find the root partition.

So this is still a bug.
Comment 3 Zbigniew Jedrzejewski-Szmek 2014-08-21 12:20:45 UTC
The system has no way of knowing which mounts are "important". If it is listed in /etc/fstab, it is assumed to be required for a fully functional system.

If you still disagree, please take it up on the ML or elsewhere.


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.