[Solved] Issues when suspending the OS

Hi All,

TL; DR:
My system specs can be found here: https://0x0.st/HX9y.txt

As soon as I put my laptop in suspend mode, the login screen comes back up. I do see it go into the suspend mode and it does turn off the monitor for a second or two but it then wakes up again and shows the login screen. I am not sure whether there is a setting that I have to change to make it work or something else. The suspend feature did work in my previous [Solus] Linux installation.

I do have a SWAP partition of 13GB (I know that swap is mainly used while hibernating the system but I just wanted to point that out).

Please let me know if you need any more info to pinpoint the issue.

Background:
I am Priten and I installed EndeavourOS Budgie today. I was a long time Solus user (most than four years) and had to switch as no new release has been made since mid-2021. Additionally, Solus infrastructure has not been operational for over four months, resulting in numerous packages remaining out-of-date with security vulnerabilities going unpatched.

My move to EndeavourOS has been fairly exciting. Most of my apps started working again without any additional configuration once I reinstalled them. I have also heard so much about the EndeavourOS community and was going through the community guidelines and a few posts to see whether someone had similar issues. I found this thread but I am not sure whether it applies to my issue.

Any and all help is appreciated. :slight_smile:

Hello,
how are you entering suspend? By point-and-click, energy management or through terminal?

What is your DE?

Thank you for your response.

I am using Budgie DE. Trying to suspend/hibernate the system using the user applet from the bottom panel (point and click)

Could you try if it works when you trigger suspend from the terminal with

sudo systemctl suspend

?

I tried that right now but it did not work. With Terminal, the time between the command being executed and the login screen reappearance is around 10 seconds but the laptop does come out of suspend mode on its own

Run

journalctl --since "10 min ago" --grep=suspend

after a failed suspension and see if it reveals something meaningful. Change the number of the minutes to something you find relevant.

60 mins ago:

Apr 09 07:14:23 Steelix dbus-daemon[509]: [system] Activating via systemd: service name='or>
Apr 09 07:14:29 Steelix sudo[2500]:   priten : TTY=pts/0 ; PWD=/home/priten ; USER=root ; C>
Apr 09 07:14:29 Steelix systemd-logind[512]: The system will suspend now!
Apr 09 07:14:32 Steelix systemd[1]: Starting System Suspend...
Apr 09 07:14:32 Steelix systemd-sleep[2551]: Entering sleep state 'suspend'...
Apr 09 07:14:53 Steelix systemd[1]: systemd-suspend.service: Deactivated successfully.
Apr 09 07:14:53 Steelix systemd[1]: Finished System Suspend.
Apr 09 07:14:53 Steelix systemd[1]: Reached target Suspend.
Apr 09 07:14:53 Steelix systemd[1]: Stopped target Suspend.
Apr 09 07:15:58 Steelix systemd-logind[512]: The system will suspend now!
Apr 09 07:16:04 Steelix systemd[1]: Starting System Suspend...
Apr 09 07:16:04 Steelix systemd-sleep[3231]: Entering sleep state 'suspend'...
Apr 09 07:16:17 Steelix systemd[1]: systemd-suspend.service: Deactivated successfully.
Apr 09 07:16:17 Steelix systemd[1]: Finished System Suspend.
Apr 09 07:16:17 Steelix systemd[1]: Reached target Suspend.
Apr 09 07:16:17 Steelix systemd[1]: Stopped target Suspend.
Apr 09 07:21:39 Steelix dbus-daemon[509]: [system] Activating via systemd: service name='or>
Apr 09 07:21:47 Steelix sudo[5324]:   priten : TTY=pts/0 ; PWD=/home/priten ; USER=root ; C>
Apr 09 07:21:47 Steelix systemd-logind[512]: The system will suspend now!
Apr 09 07:21:49 Steelix systemd[1]: Starting System Suspend...
Apr 09 07:21:49 Steelix systemd-sleep[5358]: Entering sleep state 'suspend'...
Apr 09 07:22:17 Steelix systemd[1]: systemd-suspend.service: Deactivated successfully.
Apr 09 07:22:17 Steelix systemd[1]: Finished System Suspend.
Apr 09 07:22:17 Steelix systemd[1]: Reached target Suspend.
Apr 09 07:22:17 Steelix systemd[1]: Stopped target Suspend.

Also, my journal folder size has grown to almost 4GB. Is it normal?
image

Have a look here:

https://wiki.archlinux.org/title/Journalctl#Journal_size_limit

Also check this out:

https://wiki.archlinux.org/title/Wakeup_triggers#Instantaneous_wakeups_from_suspend

(This was written under the assumption that OP wanted suspend-to-disk not suspend-to-RAM. Hopefully it can still be useful for someone out there who are having issues with waking up from hibernating.)

Hey OP, I’ve used Solus OS as well and I think I know what you’re talking about. I don’t use a laptop but I think this situation is similar, my Arch system wouldn’t wake up after it put itself to sleep/hibernate, the screen stayed black and my login window never showed up. (On Solus I believe the installation automatically gives you a 4GB swap partition. On Arch I had a similar partition scheme but I think I used 16GB.)
My issue was this. Solus automates this but you need to set it up on Arch yourself. I can’t lie- since I switched to Arch months ago, I’ve lived without this feature and just keep my PC running because I couldn’t figure out how to set it up at the time. I admit I didn’t try very hard though because I like to just keep things at their defaults and live with it. But, I think it would simply involve adding a kernel parameter:
resume=UUID=insertUUIDofdrivetobehibernatedhere

(sorry if you don’t use grub but the kernel parem is the important part) To add kernel parameters I simply edit grub and add that ^ line to sudo nano /etc/default/grub under the GRUB_CMDLINE_LINUX_DEFAULT= section.
To apply this change, you’ll need to reconfigure grub, which for my specific system I:

sudo grub-install --target=x86_64-efi --efi-directory=/boot
sudo grub-mkconfig -o /boot/grub/grub.cfg

Hope this was it, good luck friend. While I’m here I’ll go ahead and teach you how to boot “silently” like on Solus. That was a big plus for me with Solus, the clean looking and instant boot. It’s the same process as above but include these parameters:

loglevel=0 console=tty2 udev.log_level=0 vt.global_cursor_default=0

(0 is probably overkill but hasn’t caused me issues, if you want more verbosity in your journal you could use 1-3)

PS: Archwiki’s usefulness goes beyond the meme, it really is the most handy thing ever. This situation is an example- googling this question you’d get an assortment of irrelevant results and will find yourself nowhere. Archwiki has the answer right there in bold fully troubleshooted. I always check there first and 90% of the time find my solution.

This would be the right course of action for putting the system into hibernation, that would be suspend-to-disk (systemctl hibernate). For this it is necessary to have a swap device.

I am under the impression that OP wants to suspend the system (or put it into sleep in other words), that is suspend-to-RAM (systemctl suspend). For this no swap device is needed.

:eye: https://wiki.archlinux.org/title/Suspend

Yeah I just noticed OP uses a laptop, my instructions were geared more toward how I set my desktop PC up. I can see how such a thing is essential for a laptop. I think it should be around the same alley though, kernel parems. Solus gives you a 4gb swap partition by default during installation. I’ll edit my comment so it is more clear that I’m not using a laptop

1 Like

Thank you all for your contributions. I am currently trying to suspend my laptop for faster response.

Thank you for sharing your experience and it is nice to meet a former Solus user. I have not tried this yet as I want to primarily make suspend [in memory] work for me. I will definitely, give it a shot once I am done with that though.


I tried a few things but nothing has worked for me so far.

Option 1:

I created a tmp system file to block USB wakeup before the boot and sustain the same after a restart but that did not work. I created the following file, restarted the system, and attempted to suspend the machine.

/etc/tmpfiles.d/disable-usb-wake.conf:

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   EHC1
w    /proc/acpi/wakeup     -    -    -    -   EHC2
w    /proc/acpi/wakeup     -    -    -    -   XHC
w    /proc/acpi/wakeup     -    -    -    -   USBE

Option 2:
Created a service to disable USB wakeup as described here.

/etc/systemd/system/disable-USB-wakeup.service:

[Unit]
Description=Disable USB wakeup triggers in /proc/acpi/wakeup

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo EHC1 > /proc/acpi/wakeup; echo EHC2 > /proc/acpi/wakeup; echo XHC > /proc/acpi/wakeup"
ExecStop=/bin/sh -c "echo EHC1 > /proc/acpi/wakeup; echo EHC2 > /proc/acpi/wakeup; echo XHC > /proc/acpi/wakeup"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

I restarted by system after this and see that the service is working fine. However, the issue still persists.

priten@Steelix ~ $ sudo systemctl status disable-USB-wakeup.service
[sudo] password for priten: 
● disable-USB-wakeup.service - Disable USB wakeup triggers in /proc/acpi/wakeup
     Loaded: loaded (/etc/systemd/system/disable-USB-wakeup.service; enabled; p>
     Active: active (exited) since Sun 2023-04-09 09:08:15 EDT; 2min 22s ago
    Process: 493 ExecStart=/bin/sh -c echo EHC1 > /proc/acpi/wakeup; echo EHC2 >
   Main PID: 493 (code=exited, status=0/SUCCESS)
        CPU: 9ms

Apr 09 09:08:15 Steelix systemd[1]: Starting Disable USB wakeup triggers in /pr>
Apr 09 09:08:15 Steelix systemd[1]: Finished Disable USB wakeup triggers in /pr>


Although I do not see the USB entries in /proc/acpi/wakeup, the suspend feature is still not working and I see the same experience as before.

priten@Steelix ~ $ cat /proc/acpi/wakeup | grep enabled
PS2K	  S3	*enabled   pnp:00:04
RP06	  S5	*enabled   pci:0000:00:1c.5
RP12	  S4	*enabled   pci:0000:00:1d.0

Similar logs in journal as before:

priten@Steelix ~ $ journalctl --since "60 min ago" --grep=suspend
Apr 09 08:48:08 Steelix systemd-logind[516]: The system will suspend now!
Apr 09 08:48:12 Steelix systemd[1]: Starting System Suspend...
Apr 09 08:48:12 Steelix systemd-sleep[3332]: Entering sleep state 'suspend'...
Apr 09 08:48:45 Steelix systemd[1]: systemd-suspend.service: Deactivated success>
Apr 09 08:48:45 Steelix systemd[1]: Finished System Suspend.
Apr 09 08:48:45 Steelix systemd[1]: Reached target Suspend.
Apr 09 08:48:45 Steelix systemd[1]: Stopped target Suspend.
Apr 09 08:56:13 Steelix systemd-logind[516]: The system will suspend now!
Apr 09 08:56:14 Steelix systemd-sleep[4570]: Entering sleep state 'suspend'...
Apr 09 09:06:59 Steelix systemd-logind[516]: The system will suspend now!
Apr 09 09:07:00 Steelix systemd[1]: Starting System Suspend...
Apr 09 09:07:00 Steelix systemd-sleep[5180]: Entering sleep state 'suspend'...
Apr 09 09:07:09 Steelix systemd[1]: systemd-suspend.service: Deactivated success>
Apr 09 09:07:09 Steelix systemd[1]: Finished System Suspend.
Apr 09 09:07:09 Steelix systemd[1]: Reached target Suspend.
Apr 09 09:07:09 Steelix systemd[1]: Stopped target Suspend.
-- Boot ffcff3079e4647839779a08ced4c0463 --
Apr 09 09:09:45 Steelix systemd-logind[496]: The system will suspend now!
Apr 09 09:09:46 Steelix systemd[1]: Starting System Suspend...
Apr 09 09:09:46 Steelix systemd-sleep[2200]: Entering sleep state 'suspend'...
Apr 09 09:10:08 Steelix systemd[1]: systemd-suspend.service: Deactivated success>
Apr 09 09:10:08 Steelix systemd[1]: Finished System Suspend.
Apr 09 09:10:08 Steelix systemd[1]: Reached target Suspend.

Is there anything else I can try?

1 Like

Weirdly, fixing this pcie error has fixed this issue for me. Now I am able to suspend the system without any issue.

Thank you, @PigOfDestiny, @pebcak, and @anon36778426 for your valuable time.

@anon36778426, I while adding the param to suppress the pcie errors, I also added quiet splash to it and now I get the same boot experience as Solus. Thank you!

4 Likes

That’s great! Congrats!
:champagne:

1 Like

Just out of curiosity: was it pci=nomsi or pci=noaer that fixed the issue?

pci=noaer

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.