Recently bought a new laptop that comes with an AMD Radeon gpu and installed OpenSuse Tumbleweed on it which I had installed on my previous laptop as well but never had issues with suspending and resuming. However, with the new laptop, I am unable to resume after suspending or closing the lid unless I force it to shut down by holding the power button which is a major inconvenience.

I’m also dual booting alongside Windows and have secure boot enabled and have the Linux and Windows partitions encrypted if that’s what’s causing it which I doubt since this is the same setup I had on my old laptop

Any suggestions or advice would be greatly appreciated.

Edit: I was able to figure out that it does not suspend at all when I close the lid or click the suspend button on Gnome. Only found this out because when going through YaST Services Manager and manually starting systemctl suspend, the laptop suspends just fine and wakes back up. So I’m starting to think it’s more of a systemd issue? Any inputs?

Edit: turns out it was an issue with the official opensuse built kernel not sitting well. Downloaded a community version from the opensuse repository and it works fine. Very odd

  • Skull giver@popplesburger.hilciferous.nl
    5·
    9 months ago

    I doubt it, Gnome just runs the standard dbus suspend call as far as I know (source).

    However, there are different ways to suspend the system (configured by echoing a magic word to a file in /sys) so it’s possible the GUI is somehow misconfiguting the system based on what the OS reports to be the preferred suspend method. From browsing the source code, it seems like Gnome will do a Dbus call which systemd receives, and after receiving that it seems to start the suspend service? It’s a bit hard to follow with all the dbus interaction.

    This seems to be where sleep is actually requested, This is where the requested command is mapped to a specific action that is then started by the systemd manager, which is defined as a string here.

    As far as I can tell, clicking suspend is the same as running systemctl start suspend.target. But maybe there’s more going on, perhaps something else is intercepting the dbus call to suspend, preventing systemd from doing its job?