Created attachment 160890 [details] error message STEPS TO REPRODUCE There are no steps to reproduce at will, but here's what I did 1. Nothing, just wait for the screen to lock 2. shake the mouse to unlock the screen OBSERVED RESULT I got this black screen with this error message: (oh come on, no copy-pasting images?? FFS, ok, see attachment) The error message said: "Switch to a virtual terminal (e.g. Ctrl+Alt+F1)..." so I tried that but it would do nothing. So I had to reboot and lose all my unsaved work. After I rebooted, the desktop was black, so I had to kill and restart plasmashell ("killall plasmashell" followed by "kstart5 plasmashell". There's a separate bug report about that, been happening for years, I thought it had been fixed already but apparentlty not). So now I thought I'd try Ctrl+Alt+F1 and found out that never brings up the virtual console. It just freezes the current screen and renders it unresponsive (so useful!!), and Ctrl+Alt+F2 restores it. So it occurred to me to try Ctrl+Alt+F3 and that does work. Unfortunately I hadn't thought about that when I needed it. EXPECTED RESULT First, the screen locker should never crash or become unable to unlock to begin with. If the screen locker is not 100% rock-solid, unbreakable, crash-proof, then just toss it, and when I try to lock the screen just say "Sorry, we don't lock the screen anymore because we haven't figured out a way to do it in a safe manner". Second, Ctrl+Alt+F1 should open a virtual console. That's a pretty universal convention. I could understand if there were different conventions and you had something more interesting and useful to assign to Ctrl+Alt+F1, but freezing the screen and making the mouse cursor disappear doesn't seem to be that. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.1.38-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-1065G7 CPU @ 1.30GHz Memory: 7.3 GiB of RAM Graphics Processor: Mesa Intel® Iris® Plus Graphics Manufacturer: LENOVO Product Name: 81WE System Version: IdeaPad 3 15IIL05
Before this happened, did you happen to install software updates without rebooting before locking the screen? If you run `coredumpctl --reverse` do you seen any crashes from something like "kscreenlocker_greet" at or near the top?
> Before this happened, did you happen to install software updates without rebooting before locking the screen? Hmm, I'm not entirely sure. I had installed some updates a few days ago, and I think I restarted right after that, but I'm not 100% sure. > If you run `coredumpctl --reverse` do you seen any crashes from something like "kscreenlocker_greet" at or near the top? I have these: Thu 2023-08-10 16:58:22 CEST 180503 1000 1001 SIGABRT present /usr/bin/kcminit Thu 2023-08-10 16:58:06 CEST 180469 1000 1001 SIGABRT present /usr/bin/kcminit (and then ancient stuff) but these timestamps come _after_ I took the picture of the error, so they probably happened when I rebooted afterwards. Regarding the Ctrl+Alt+F1 thing which actually concerns me more (I'm pretty sure the screenlocker thing is a duplicate of some known bug), right now I tried again, and instead of just freezing the screen, it does show a black screen with a blinking cursor, but nothing else (not a login prompt) (and as usual, Ctrl+Alt+F3, 4, etc, do work)
Which VT is going to allow input is unfortunately dependent on your distro, so anything we can say in this message is just a guess. On Fedora I get the same thing, and Ctrl+Alt+F3 is the one that works. Before we go any further, let's agree to avoid discussing two bugs in one bug report. Would you like to use this bug report to track the fact that the screen locker broke in the first place, or the incorrect message?
> Would you like to use this bug report to track the fact that the screen locker broke in the first place, or the incorrect message? Actually I'd suggest to use it to track the fact that Ctrl+Alt+F1 seems to do nothing except render the system useless until you hit ctrl+alt+F2 to get it back. Unless that belongs outside of KDE, in which case I'd suggest using this bug for the improvable error message. The fact that the screen locker is broken in the first place, I assume it's tracked somewhere else (given that the error message even exists) (and hopefully the particular condition that makes it break that I've stumbled upon is not a new unknown one).
Looks like there was a prior attempt to fix this that didn't end up being merged: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/86 The submitter abandoned the work and deleted their account. :/ Someone else could try again, using that as a base.
I just ran into the same issue. Using Ctrl-Alt-F3 worked for me.
So my thinking is what if it prompts the user to hit Ctrl+Alt+Shift+Esc, and then tells the user to log in with a session that ships with KDE that is just "KDE Session Unlock", and the session could call something like this script: SDDM supports logind v257's SecureAttentionKey with GDM and LightDM with waiting patches Maybe even the user logging into KDE could run that script if it detects a simultaneous session, but this might make it hard for users that want simultaneous sessions, and don't have KDE starting with systemd --user #! /bin/bash UserSessions=($(loginctl show-user $LOGNAME --property=Sessions --value)) SeatSessions=($(loginctl show-seat $XDG_SEAT --value --property=Sessions)) UnlockSessions=() for UserSession in "${UserSessions[@]}" do for SeatSession in "${SeatSessions[@]}" do if [[ $UserSession == $SeatSession ]] then UnlockSessions+=($SeatSession) break fi done done #loginctl unlock can take multiple sessions loginctl unlock ${UnlockSessions[@]}" #Determining which session is actually KDE, vs say a Weston session will be the hardest bit loginctl activate ...
(In reply to bluescreenavenger from comment #7) Ah! I mean to post this in https://bugs.kde.org/show_bug.cgi?id=466178 ! I am sorry