Hide Forgot
Trivial errors like a missing / failed disk drive or even an incorrect file system type in /etc/fstab wioll cause hard boot failures. Version-Release number of selected component (if applicable): systemd-37-3.fc16 How reproducible: 100% Steps to Reproduce: 1. Use a working system, then change in /etc/fstab the file system type for any unessential (i. e. not really needed for a successful boot) file system. 2. For example, change the /etc/fstab entry for /boot from ext4 into ext3 3. Reboot. (4. Boot from DVD in recovery mode. This will not work either.) Actual results: The system fails to boot. systemd complains about missing dependencies. Expected results: The system should just boot. The inconsistent file system should just be omitted from being mounted, but such a trivial issue should _never_ block the whole system from booting. Additonal notes: Similar problem also prevent recovery of the system when booting in recovery mode from DVD, see bug # 771635.
(In reply to comment #0) > The system fails to boot. systemd complains about missing > dependencies. To be precise... Do you get dropped into "emergency mode" then? > The system should just boot. The inconsistent file system should just > be omitted from being mounted, but such a trivial issue should > _never_ block the whole system from booting. This seems to be a common complaint. The old rc.sysinit did not require all mounts from fstab to succeed. So I'm inclined to change the fstab entries to be WantedBy=local-fs.target by default (instead of the current RequiredBy). The 'nofail' option would still disable the ordering dependency with respect to the target.
(In reply to comment #1) > > > The system fails to boot. systemd complains about missing > > dependencies. > > To be precise... Do you get dropped into "emergency mode" then? No. The system comes to a halt without any way to input any commands or do anything else but to reset the system. > > The system should just boot. The inconsistent file system should just > > be omitted from being mounted, but such a trivial issue should > > _never_ block the whole system from booting. > > This seems to be a common complaint. The old rc.sysinit did not require all > mounts from fstab to succeed. Right, and this makes perfect sense. It is _much_ easier to recover a partitally running system than a dead one. > So I'm inclined to change the fstab entries to be WantedBy=local-fs.target by > default (instead of the current RequiredBy). > The 'nofail' option would still disable the ordering dependency with respect to > the target. It would be nice if above mentioned "emergency mode" would be used in case of problems. Thanks.
(In reply to comment #2) > No. The system comes to a halt without any way to input any commands > or do anything else but to reset the system. I can't reproduce this. I get the emergency shell. Could you take a picture of the errors you get?
(In reply to comment #3) > (In reply to comment #2) > > No. The system comes to a halt without any way to input any commands > > or do anything else but to reset the system. > > I can't reproduce this. I get the emergency shell. > Could you take a picture of the errors you get? Hm... On the systems I can play around with now it works, too (i. e. I get the "Welcome to emergency mode" message and can enter a shell. The servers where this happened are back in operation again, so I cannot re-test this soon (I was happy to haven them for a full day during xmas break). I will re-test this as soon as we have to reboot any of the servers. Sorry.
(In reply to comment #1) > So I'm inclined to change the fstab entries to be WantedBy=local-fs.target by > default (instead of the current RequiredBy). Lennart convinced me that papering over failing mounts by default would not be safe. systemd cannot know if the mount that failed is trivial or essential for the integrity of the system. By default it has to err on the safe side. Non-essential mounts should be marked with the 'nofail' option. Let's keep this BZ open for the issue with the missing emergency shell.
We need someone who can reproduce the problem of the missing emergency shell to tell us the error messages, or we'll close this due to INSUFFICIENT_DATA.
(In reply to comment #6) > We need someone who can reproduce the problem of the missing emergency shell to > tell us the error messages, or we'll close this due to INSUFFICIENT_DATA. I'm not sure what you mean by "error messages". When this happens, the box is more or less dead. There are no error messages, it's just hanging, with no other way to recover than to reset it.
I was referring to "systemd complains about missing dependencies.". I thought it also applied to this failure mode. If there are no error messages, we need to make it more verbose. One option is to boot with "systemd.log_level=debug systemd.log_target=console". Ideally with a serial console connected ("console=ttyS0" or similar) to capture the logs.
I believe the missing emergency shell got fixed in systemd-37-20.fc16. It was caused by bug 798328.