After the latest Dom0 update (19th may 2025), my system immediately goes to sleep or hibernation instead of simply blanking the screen. Changing screensaver config in Dom0 additionally results in countless errors. Since at least some systems don’t wake up from sleep (mine doesn’t) this problem can make the system unusable, the only thing left to do is switching it off with the power button. Even though I got some errors while doing so, I managed to switch the screen saver off. Hopefully this solves the direct problem, but something is definitely wrong here since the latest Dom0 update.
Edit: The problem seems directly caused by XScreensaver, locking the screen causes the problem. It doesn’t show the password box to unlock the screen anymore, leaving the user locked out
(I have a similar situation with KDE…the monitor sometimes wakes up but shows nothing but a mouse pointer on a black screen. Plugging in a thumbdrive will wake it up the rest of the way, but I also discovered I could type in the password and it would work even while showing a black screen.)
Even with the screensaver and powermanager disabled, the screen turns to black after some time. After having been forced to power the system down (and losing my work) with the power button for three times now, I decided to switch to i3, hopefully the issue is absent there.
Same problem here, XScreensaver in dom0 updated and now the password entry box to unlock the screen after it was locked no longer appears. It’s not a problem with the screen not turning on, my screen doesn’t turn off and when I press a button the mouse cursor appears for around a second.
I can’t fix it (and my suggested workaround was a shot in the dark), but at least now I know not to update dom0. (Even though I’m using KDE I don’t dare.)
Exact same problem here. FWIW I do have a High Resolution (5120x1440) screen.
I’ve turned on “Presentation mode” by clicking on the battery icon in the task bar. So far this seems to successfully prevent screen blanking and thus works around the issue.
Of course the downside is that now I’ll have to shut everything down when leaving for an hour or two.
As a temporary solution to keep your job, you could try Ctrl+Alt+F2 login as user, ps auxwww | fgrep screen, kill xscreensaver --splash and switch back Ctrl+Alt+F1.
P.S. Didn’t notice. This tip is already in the fix above.
If this solves the issue for you and you have a Github account, it would be highly appreciated if you could give it a thumbs-up in [updates-status]. So it would be pushed faster to stable repository for other users.
Yes. That script should be present on dom0’s updatevm (which is sys-firewall by default). Or rather on whichever template it uses (which is default-dvm → fedora-41-xfce by default at this moment). If you do not have it, install it on that template. Or select another template and/or updatvm for dom0. On Fedora templates, the package name is qubes-core-agent-dom0-updates. Otherwise, you may ask about it on Forum (better on a new topic).
thanks for the pointer that was it. I had switched sys-firewall to debian-12-minimal to try and harden it a bit not thinking that this would affect dom0’s update process. Switching back to my original template fixed everything. Thanks!!
You can use a debian-12 minimal based sys-firewall. I’d clone debian-12-minimal, add this script to it (plus the other few items a service qube needs, and those that a service qube client needs since sys-firewall connects to sys-net). And just use that.
yes, after confirming that it was the sys-firewall template the issue, I added the required package in debian-12-minimal and tested it to make sure everything worked
