F38: suspend

My intel-based F38 desktop does not have “suspend” available anymore for a few weeks.
It’s not available in the GNOME shutdown menu and on the shell:

~ systemctl suspend
Call to Suspend failed: Sleep verb "suspend" not supporteded

I don’t see that on another intel-based laptop or my AMD-based thinkpad.

I see that with the 6.2 kernels from the default repos and also with 6.3 kernels from koji.

Could need some help on this, thanks.

Please provide more information. I suggest to boot your machine once, do nothing but logging in and then trying to suspend (which means, provoking the error). Then, shutdown and boot again: then, get the logs from the then-last boot with sudo journalctl --boot=-1 and let the supporters here know the output (e.g., sudo journalctl --boot=-1 > logfile.log.

At the best, you provide here the link to the file. If you have to paste it for some reason, please use the brackets (which means, mark all log text and then click the </> button).

Please do not use the 6.3 kernels in conjunction with any XFS file systems (in case you have some). It could cause trouble (an XFS issue is the reason why 6.3.3 is still not pushed to stable).

Will try to do that later this afternoon. Thanks so far.
And btw: no XFS used here, btrfs all over the place :wink:

here that logfile: the oops!Nextcloud
Used kernel 6.2 from fedora repos.

A lot processes/services log on your system. Can you add the very system time (second) when you have tried the suspend? To know at what time to start searching. Working through this whole log file would take some time.

Additionally, do you remember which was the last kernel where the suspending worked? However, I would not exclude at this time that it is a GNOME-related issue (beyond your elaboration of GNOME, there are some GNOME errors logged). Unfortunately, I am not used to GNOME.

What is the contents of /sys/power/state? Not all systems support all sleep states in all configurations (for example: secure boot will disable a few).

You can read up a bit more about supported sleep states here: System Sleep States — The Linux Kernel documentation

Currently away from that system, will provide a fresh log and details as soon as I am back. Thanks.

DId that again and added lines “suspend test starts” and “suspend test stops” before/after “systemctl suspend”. Not much too see, I am afraid … at least for me.

# cat /sys/power/state 
freeze mem disk

Suspending worked fine on this system for a long time, until maybe 1-2 months ago. It was NOT related to the F38 upgrade.

EDIT: link to new logfile: the oops!Nextcloud

Please do not manipulate logs but provide additional/related information here. However, if I understand it right, you tried systemctl suspend somewhen between 14:02:16 and 14:02:25 - please confirm.

I thus assume the entries you added were …
Mai 30 14:02:16 ivy unknown[7338]: suspend test starts and
Mai 30 14:02:25 ivy unknown[7691]: suspend test stops

If so, what was contained at these two lines before you changed them?

If you added the two lines completely yourself, where did the initial parts of the two entries come from? By initial parts I mean unknown[7338]: and unknown[7691]:?


Concerning your /sys/power/state , you might check if disk is supported (which means in the easiest way: test without! So remove the disk from the file and then try again).

→ I also have only freeze mem (not sure if Fedora today adds disk automatically if it could verify that your system supports it, or if you maybe activated it accidentally manually at some point, which means it could be the origin of the problem).

Beyond the documentation provided by @supakeen , systemd-sleep.conf could be helpful.

You might check ls -l /etc/systemd/sleep.conf to see if your sleep.conf has been changed roughly at the time when the problem has started to occur (and check its contents; feel free to share if you want).

ad logs: I didn’t manipulate. The 2 “unknown” lines came from me issuing:

systemd-cat echo "suspend test starts"
systemctl suspend
systemd-cat echo "suspend test stops"

Nothing was removed or so …

Ah, ok, that explains the process IDs. Got it now.

Sorry, a bit busy.
Just another small feedback: /etc/systemd/sleep.conf is basically empty, everything commented out, only “[Sleep]” header active.