S3 Suspend works on stock Fedora 37 but not Qubes 4.1 or 4.2 (fc37)

Could it be this?

I’m trying to use S3, not S0ix / modern sleep. I wasn’t able to follow all the technical implications of the issue. How could I test whetherr this issue is relevant?

The BIOS option is set to Linux S3 Sleep.

qvm-shutdown --all before attempting suspend made no difference.
Have searched the forums and mailing lists and tried all the suggestions.

Does anyone know why 4.2 is so different to a stock FC37 that it would affect suspend? Anything I can check?

Diff the qubes kernel against vanilla fedora?

Interestingly, following the kernel power management debugging guide linked from here:


a) Test modes of hibernation

To find out why hibernation fails on your system, you can use a special testing
facility available if the kernel is compiled with CONFIG_PM_DEBUG set. Then,
there is the file /sys/power/pm_test that can be used to make the hibernation
core run in a test mode. There are 5 test modes available:


  • test the freezing of processes


  • test the freezing of processes and suspending of devices


  • test the freezing of processes, suspending of devices and platform
    global control methods(*)


  • test the freezing of processes, suspending of devices, platform
    global control methods(*) and the disabling of nonboot CPUs


  • test the freezing of processes, suspending of devices, platform global
    control methods(*), the disabling of nonboot CPUs and suspending of
    platform/system devices

This resulted in successful test suspend / resume for echoing each of freezer devices platform processors and core .

1 Like

Next steps seem to be booting into runlevel 1 and suspending from there, if it works, then perform a binary search to see which of the loaded kernel modules could be causing an issue.

Not sure I follow…diff the whole kernel source?

Suspend 2 RAM from runlevel 1 fails in the same way as when Qubes fully loaded

1 Like

Only as a last resort. In patches, there’s more often than not developer comments

// leaving this here because enabling this flag causes a kernel panic
program HelloWorld;

    WriteLn('Hello World');

which might “jump out” at you regarding power management.

Solution: Install Kernel 6.0.7 in Dom0 (works in both 4.1 and 4.2)

dom0$ qubes-dom0-update kernel-6.0.7 (in 4.2 /fc 37)

(note that qubes kernel-latest is newer and doesn’t work, so something in newer kernels breaks suspend)

For Qubes 4.1 (fc32)

The package exists

but won’t install when I run

sudo qubes-dom-update --releasever=4.1 --enablerepo=qubes-dom0-currrent-testing kernel-latest-6.0.7

“unable to find a match”

I pulled it manually, moved to dom0 and ran dnf install

Props to @cayce for suggesting the right answer

1 Like

Thanks ! I’m not (yet) an advanced user…

So on 4.1 + Fedora 37, got the error “unable to find a match: kernel-6.0.1” as you describe it.

I pulled it manually, moved to dom0 and ran dnf install

@BenT Can you just explain how to pull it manually ? And then install it via dnf install ? I uploaded it (thank to you post) but wasn’t able to move the .rpm file to Dom0 from an internet connected AppVM. I’m fearing doing wrong things there…

One way to move files between Qubes (from a shell in dom0) is:

… and if you want the file to stay in dom0, you should be able pipe it to a file there:

qvm-run --pass-io sourceVM 'cat file' > filename_in_dom0


Great. That works now. I can suspend and resume the session. Thanks also to @ChrisA for helping in pulling the package back to Dom0.

I now need to fix a new issue as I cannot enter the session password in ScreenSaver when resuming. Will do some search on the forum.


Does your sys-firewall come back after suspend?
Mine doesn’t:

In fact I can’t open the session after resuming. This is the problem I tried to explain : keyboard isn’t recognized (or partially recognized…). So I cannot tell you if sys-firewall come back when resuming…

I’m sure I can obtain logs somewhere (if someone explain me how) so I can share that with the community.

Absence of logs :speak_no_evil: :hear_no_evil: :see_no_evil: impedes troubleshooting effectively. :disappointed:

Have either of you tried to build your sys-* qubes with both fedora-based & debian-based templates and/or minimal templates?

Just a shot in the dark but, could it be possible the issue lies with one of the very many unneeded packages installed within the default, “full” templates?

@cayce is right again
debian-11-minimal (disposable) sys-firewall does not exhibit the freezing issue

time to start building sys-* with minimal templates

Actually, how about building the whole system on clones of minimal templates with only desired packages…

1 Like

Like this?

1 Like

Hi there !

This is now working perfectly fine. I think a recent update allow to fix the last problem I had when resuming. I noticed that the screen saver box changed slightly.

So Dell XPS 13 + Kernel 6.0.7 is a good solution for Qubes-OS 4.1 !

@Sven : should I update the HCL entry with that information ?


Your posted HCL report currently doesn’t have any remarks and says R4.1 works: yes.

This thread is linked from it. I recommend you add whatever remarks you’d like to make to this thread.