Bugzilla – Bug 1169811
opensuse tumbleweed starts in emergency mode because of a yast entry in /etc/fstab
Last modified: 2020-05-11 16:19:45 UTC
if I format an usb harddisk or stick via yast partition tool yast makes automatically a new entry in /etc/fstab with this usb device. If I then remove the usb device and make a reboot of my system the boot-process hangs in emergency-mode, because the system can not find the removed usb-device.
I think this "feature" is a horrible bug. I think a "green" user has no chance to repair his system and gets much frustration of opensuse.
Created attachment 836262 [details]
Screenshot: Add Partition
"Add Partition" dialog.
Notice the "mount device" radio button which is off by default,
thus the "mount point" field is disabled.
All I changed in that dialog is the filesystem type which I set to "FAT"; the rest are the default values from entering the dialog.
By default it does NOT create an /etc/fstab entry.
It doesn't even try to mount that device.
The normal procedure is to just create a partition (using this dialog) and apply the changes.
When you close the parititioner, on most desktops the newly formatted USB stick will automatically be picked up by UDEV rules, and it will be mounted at
with the new filesystem's UUID (or the label if you created one).
However, if you explicitly request it to be mounted by checking the "mount device" radio button in that "add partition" dialog and then enter a mount point, it will mount it there immediately and also create an entry in /etc/fstab with those parameters.
I guess that is what you did, right?
To make this more transparent, we might choose to explicitly add a checkbox
[x] Add to /etc/fstab
in this dialog, so its right column looks about like this:
( ) Mount device
[x] Add to /etc/fstab
(x) Do not mount device
The default for this would be on (checked), of course.
While this would mean zero behaviour difference to what it does now, it would make users more aware of that /etc/fstab entry.
Another annoying (but out of scope for the YaST team) problem is systemd completely halting the boot process when such a filesystem of minor importance cannot be mounted.
For the average user, this is a catastrophic failure; most users cannot cope with that emergency shell. This is most unfortunate.
(In reply to Stefan Hundhammer from comment #4)
> For the average user, this is a catastrophic failure; most users cannot cope
> with that emergency shell. This is most unfortunate.
To clarify: I consider it most unfortunate that systemd behaves like that, not that users cannot deal with that emergency shell (usability of that emergency shell is a whole different topic).
Still waiting for a reply...
Did I guess the scenario correctly? See comment #2 here.
Yes, I think I made this entry unintended.