Lubuntu 18.04 (lxde) here, upon AMD Epyc 7282. Kernel 4.15. The system is stable and works flawlessly, but id does refuse to suspend.

If I try to suspend it, the screen blanks, but the system does not power off.

At this point, if I hit a key or move the mouse, nothing happens. If I hit the power button, the system "wakes up", presenting the login screen, and then all the applications as I left them.

Hibernation is absent alltogether.

Note that Epyc Rome is not affected by the notorious RDRAND bug which affects Ryzen 3000 and causes problems with suspend to ram.

EDIT: I used the system for days with high load, and can confirm rock stability, but if I leave it blanking the monitor, there is no way to wake it up.. One has to connect via ssh and reset the system.

EDIT(II): Example output for journalctl -u systemd-suspend.service:

gen 25 04:33:52 epyc systemd[1]: Starting Suspend...
gen 25 04:33:52 epyc systemd-sleep[1743]: Suspending system...
gen 25 04:34:36 epyc systemd-sleep[1743]: System resumed.
gen 25 04:34:36 epyc systemd-sleep[1743]: /dev/sda:
gen 25 04:34:36 epyc systemd-sleep[1743]:  setting Advanced Power Management level to 0xfe (254)
gen 25 04:34:36 epyc systemd-sleep[1743]:  APM_level        = 254

EDIT (III): I actually managed to hibernate the system using uswsusp, by specifying explicitly the resume device, that is, the swap partition:

sudo s2disk -r /dev/sda1

In such condition the system does shut down visualizing SNAPSHOTTING THE SYSTEM...

If I power on, the system does boot saying RESUMING FROM HIBERNATION... but then, it just displays the desktop, with no trace of any application left open. I will investigate the logs and report back.

  • 2
    If you suspend via command systemctl suspend does it suspend correctly?
    – guiverc
    Jan 25 '20 at 22:57
  • No, it does not. Actually I am interested mainly in this way of suspending it, since I will use the system primarily by ssh. Thanks.
    – MadHatter
    Jan 27 '20 at 19:20
  • For hibernating the system you would need a swap partition as far as I know. I once tried it with just creating a swap file but that seemed a little buggy to me. What does gsettings get org.gnome.desktop.screensaver ubuntu-lock-on-suspend tell you?
    – starkus
    Feb 1 '20 at 9:32
  • 1
    Does masking suspend and hibernation with sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target give you any errors? And does unmasking it with sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target give you some hints to solve your issues?
    – starkus
    Feb 1 '20 at 9:37
  • look through the log file /var/log/syslog. Or journalctl --since 9:00 --until "1 minute ago" --since time system went to sleep --until time system woke up or tried to anyway.
    – da_kingpin
    Feb 2 '20 at 17:54

Some ACPI BIOS have been know to be buggy in linux and this may not work with all systems. I do believe hibernation is disabled by default with ubuntu flavors. Check and make sure the file /etc/default/grub contains the resume parameter in the line GRUB_CMDLINE_LINUX_DEFAULT= near the beginning of the file. To quickly check, from a terminal type:

head -n 15 /etc/default/grub

The line should read something like this example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=26623446-028a-415d-e685-8adc53740282"

If your resume value instead contains resume=/dev/sda1, I would suggest changing that to a UUID number. The device identifier "/dev/sda1" is not always persistent and could possibly change when a new drive is introduced to the system. The UUID will remain unique. To find the UUID# of your swap partition:

lsblk -o +uuid | grep -i swap

As a good habit, make a backup copy of the original file before changing.

sudo cp /etc/default/grub /etc/default/~grub.bak.`date '+%Y-%m-%d'`

If you have made any changes to the /etc/default/grub file, you will need to update the grub configuration:

sudo update-initramfs -u

Read the output and confirm that initramfs resume hook is pointing to the correct partition. Then

sudo update-grub

Then try to hibernate system:

sudo systemctl hibernate

If system immediately resumes then login and read dmesg to see any recent [PM] errors and look over the logs again to find what may be the issue.

  • That's an interesting answer, although I won't be able to check it before the bounty expires. I'll try and reissue the bounty tomorrow.
    – MadHatter
    Feb 6 '20 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.