Hi Steve, with your additional information about the faulty fstab entry, I had another look. a/ I first tried with a non-existing device. I also made sure the concurrently running fsck takes longer then 90s.
The result is: https://people.debian.org/~biebl/bug931267/boot-missing-device.mp4 systemd will indeed start the emergency shell after 90s, although the fsckd process is still ongoing and clobbers the output of the login prompt. Once the fsck is done, simply hitting enter one can log in without problems. b/ Next I tried with a faulty mount point where the device exists but the mount options are non-sense, so will trigger a mount failure. The emergency shell is immediately started while fsck is still ongoing. See https://people.debian.org/~biebl/bug931267/boot-failing-mount.mp4 I guess this is basically what happened in your case. The login prompt was again still usable. Given this, I'm inclined to downgrade the severity. I'm not entirely sure how to fix this though. Should systemd delay the start of the sulogin prompt until all fsck processes have finished? You can't interact with the system for a potentially very long time (the same way basically as is the case now). The only thing you'd gain is that the login prompt in such a case doesn't look clobbered. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
