Control: severity -1 normal Hey Michael,
Agreed on the downgrade... On Mon, Jul 01, 2019 at 02:14:26PM +0200, Michael Biebl wrote: > >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. Right. Starting things on a busy console like now is confusing for users. I'm not sure there *is* a good answer here, tbh. :-/ Maybe(?) it would be possible to steal a few more characters of each line of the terminal output at boot for a tiny status message? The you could have that show that the boot has hit errors? Similar to the existing LSB-style [ OK ] or [FAILED] messages for each servive, but to show overall system status? My own system looked a lot messier than what you're showing in your simple video, of course - other services starting up around this added a lot of noise. My server runs lots of services. Of course, I didn't get to capture the output directly, just the logs. -- Steve McIntyre, Cambridge, UK. st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross