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?
Interestingly, following the kernel power management debugging guide linked from here:
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
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:freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform
global control methods(*)processors
- test the freezing of processes, suspending of devices, platform
global control methods(*) and the disabling of nonboot CPUscore
- 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;
{$APPTYPE CONSOLE}
begin
WriteLn('Hello World');
end.
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
https://ftp.qubes-os.org/repo/yum/r4.1/current-testing/dom0/fc32/rpm/kernel-latest-6.0.7-1.fc32.qubes.x86_64.rpm
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.
2 Likes
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 
impedes troubleshooting effectively. 
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
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 ?
2 Likes
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.