Description of problem: The Plymouth LUKS password prompt will wait FOREVER for me to type in a password without powering down the monitor or blanking the screen. This leaves me vulnerable to screen burn-in if 1) there was an unexpected reboot like a crash, or 2) another OS (which shall remain nameless) rebooted after update, but the dual-boot started in Linux instead of the other OS. How reproducible: 100% Steps to Reproduce: 1. Wait at LUKS prompt until you need to throw away your monitor. Actual results: A bill for an expensive new monitor. Expected results: The monitor goes into powersaver mode after a reasonable time, like 20 minutes, or at least blanks.
Thank you for the bug report. To be honest my first reaction when I saw this was to close it with "WONTFIX" as resolution... But you convinced me that some sort of blanking would be good to have with: "screen burn-in if 1) there was an unexpected reboot like a crash, or 2) another OS (which shall remain nameless) rebooted after update, but the dual-boot started in Linux instead of the other OS." So I've added this to my list of plymouth issues to look at when I have time to work on plymouth issues, it is at the bottom of that list though, so I do not expect to get around to this soon if ever.
@Hans: As someone interested in this - well, personally I'd rather have the system shutdown than just blank the display and stay on - could you perhaps give me some pointers on where to look inside Plymouth?
Just for a bit of history, once upon a time, Plymouth would wait for a few minutes and then, without user entry, would drop to the emergency shell. We asked for the timeout to be removed, because it left users who happened to walk away during the reboot faced with a very scary sight when they came back. (For example, reboot to apply RPM updates offline, go stretch your legs, then come back and it looks like your system has become unbootable.) So, having the system remain at the LUKS prompt definitely makes sense from that perspective. (And it would be highly undesirable if it shut the system down as well). Having it blank the screen to avoid potential burn-in situations makes sense, but I think anything more aggressive would be unnecessary and unwelcome.
I agree with Stephen and the plan (when I get around to it) is to add some simple screen blanking and restore the screen on a key-press.
I definitely think by default it should shutdown after some time period if the wait is during startup (before the boot is successful test checkpoint). If plymouth can opt into some kind of systemd timeout that falls back to poweroff, that would be great. Then users can just customize that timeout value, including e.g. 0 for indefinite. I mentioned it on systemd list and it resulted in this response from Lennart. https://lists.freedesktop.org/archives/systemd-devel/2019-August/043282.html It's a valid point about fsck too. What if the fsck fails? Just sit there and let the laptop battery run out? There are a number of things that could inhibit startup where it'd be better to just poweroff if the user doesn't intervene; but then after a critical point you no longer want that policy in place.
If we're going to be changing defaults here, it should definitely be on mobile systems only. Additionally, screen burn-in is only an issue with CRT displays. If fsck fails, the best option is to continue to show the exact error for as long as possible, so that it can be addressed, as any other major boot-time issue.