Score:1

Ubuntu fails to wake after suspend-then-hibernate

cn flag

There is a problem I haven't been able to solve yet, and doesn't seem to be much discussed.

I recently enabled hibernation on a swap partition on Ubuntu 22.04 by adding resume=UUID=UUID_OF_MY_SWAP_PARTITION in the line GRUB_CMDLINE_LINUX_DEFAULT of my /etc/default/grub file and RESUME=UUID=UUID_OF_MY_SWAP_PARTITION in the file /etc/intramfs-tools/conf.d/resume. This enabled hibernation successfully, and I see the menu entries and can hibernate whenever.

I have no problem hibernating then waking, and suspending then waking. Everything works very well.

I also disabled Hybrid Sleep in a file in /etc/systemd/sleep.conf.d/ and set the delay for suspend-then-hibernate to 60 min ; here's the content of this file

[Sleep]
AllowHybridSleep=no
HibernateDelaySec=60min

The behavior I want is lid close or sleep key or inactivity to do a classic suspend, and any of these classic suspends, whether plugged in or not, to hibernate after 60 minutes. Without changing the behavior of any command, this is indeed what it does. Waking when it is in suspend mode does work, and hibernation successfully happens after 60 minutes of being suspended. However, when hibernated this way and only when hibernation came from a suspended state, I can not boot again : turning the computer on goes to the grub screen as it should (dual boot), and choosing Ubuntu doesn't boot completely : I instead get a message on a command-line-like black screen.

I tried performing the bug again to copy the error message, but today it doesn't write anything! Just a black screen! Also in the next few days, it booted until login screen, where it dispalys the time before asking for session password, but it was stuck on the time without accepting input. I don't know what caused this change of behaviour. Users on forums have had this kind of problem with suspend (not suspend-then-hibernate), with this message :

Bluetooth hci0: Timeout waiting for suspend events
Bluetooth hci0: Suspend timeout bit: 6
Bluetooth hci0: Suspend notifier action (3) failed: -110

My error message is very similar. It is also three lines, and the first line is definitely the same. The two next lines I'm not sure, even less of the numbers written, but they did look similar. I checked again in the logs but couldn't find it.

And then the computer doesn't accept any input and won't boot ; I must turn off with the power button (or REISUB) and turn it on again - which kind of defeats the purpose of hibernating...

I tried to look into the logs but I'm not sure which log to check, and didn't find anything that really seemed relevant. But I'm not very good at this, so if one of you wants me to look up something specific, I certainly can!

For information, I am on a DELL Precision 7520 laptop, with a fresh Ubuntu 22.04 install on an SSD I added myself, dual-booting with Windows 11 installed later on. Both these partitions, two data partitions and my swap partition are on the SSD. There is also an HDD that is used for data storage only.

I'm sure it's easy to fix, but I have absolutely no clue as to what to do.

Thank you very much for your help, and I will provide any further information you want.


EDIT :

Using kernel boot option mem_sleep_default=s2idle, as suggested in the comments, didn't have any effect unfortunately.

While I can't really make sense of the log files, there seemed to be a bunch of nvidia messages. I remembered on the same computer, but long ago like ubuntu 16.04 or 18.04, I had wake problems (not after hibernation, just regular sleep) and eventually switching to server nvidia drivers did the job. In this case, I tried many available nvidia drivers, whether server or not, in Software & Updates, but to no avail.
I initially wanted to do this in order to save energy. Since I have a SSD, waking from disk is quite fast, so I settled on disabling RAM sleep altogether and going for hibernate all the time.
I first tried to have a .conf file in /etc/systemd/logind.conf.d/ say that every power action is hibernate :

[Login]
HandlePowerKey=poweroff
HandleSuspendKey=hibernate
HandleHibernateKey=hibernate
HandleLidSwitch=hibernate
HandleLidSwitchExternalPower=hibernate

but strangely it didn't suffice (lid switch did hibernate, but not suspend key). Changing a conf file in /etc/systemd/sleep.conf.d/ to have SuspendMode and SuspendState the same as Hibernate didn't work either. I had to create a link

sudo ln -s /usr/lib/systemd/system/systemd-hibernate.service /etc/systemd/system/systemd-suspend.service

and now it works, I don't have "classic" suspend anymore, it just hibernates all the time.

It's okay for me this way! Maybe this can help someone, though the root problem is still not solved.

Thanks for your help :)

nobody avatar
gh flag
Please can you try kernel boot option `mem_sleep_default= s2idle` instead? Found https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html here
damb11 avatar
cn flag
Thanks for your input! s2idle instead of deep does not change the problem. I haven't fixed my problem, but settled on another solution instead (see edit) :)
Score:1
sd flag

I'm seeing this late, but I'll post anyway on the off chance it helps in this case or helps others.

I had the same problem with suspend working, hibernate working, but suspend-then-hibernate failing. I'm running 22.04 on Dell XPS 9310.

I wound up using an alternative to suspend-then-hibernate called suspend-sedation. It's a script that can be run as part of a systemd service. Like suspend-then-hibernate, it will wake up a laptop out of suspend mode after a set number of seconds--defined by the ALARM_SEC variable in the script below--and go into hibernation. In my case, that variable is set to 21600 seconds, which is six hours.

At first, I had failures with it, too, but because it's a script I was able to experiment with it. I suspected that it was causing my laptop to jump into hibernation before it had fully awakened from suspend, so I inserted an three-second delay upon coming out of suspend. That did the trick. I also adjusted it so that it wouldn't go into hibernation if the laptop was plugged in. Here's the script, see the pages in the "Documentation" section for more:

# save as: /etc/systemd/system/suspend-sedation.service
# reload service files to include this service: sudo systemctl daemon-reload
# start the service: sudo systemctl start suspend-sedation.service
# check its status: sudo systemctl status suspend-sedation.service
# enable to run at startup: sudo systemctl enable suspend-sedation.service

[Unit]
Description=Suspend Sedation
Documentation=https://bbs.archlinux.org/viewtopic.php?pid=1420279
Documentation=https://bbs.archlinux.org/viewtopic.php?pid=1574125
Documentation=https://wiki.archlinux.org/index.php/Power_management
Documentation=http://forums.debian.net/viewtopic.php?f=5&t=129088
Documentation=https://wiki.debian.org/SystemdSuspendSedation
Conflicts=hibernate.target hybrid-sleep.target
Before=sleep.target
StopWhenUnneeded=true

[Service]
Type=oneshot
RemainAfterExit=yes
Environment="ALARM_SEC=21600"
ExecStart=/usr/sbin/rtcwake --seconds $ALARM_SEC --auto --mode no
ExecStop=/usr/bin/bash -c '\
sleep 3; \
ALARM=$(cat /sys/class/rtc/rtc0/wakealarm); \
NOW=$(date +%s); \
BATRY=$(echo /sys/class/power_supply/BAT*); \
BAT_STATUS=$(tail "$BATRY/status"); \
if [[ -z "$ALARM" ]] || [[ "$NOW" -ge "$ALARM" ]]; then \
  if [[ "$BAT_STATUS" = "Charging" ]] || [[ "$BAT_STATUS" = "Full" ]]; then \
    echo "suspend-sedation: Woke up, no alarm set, but plugged in. Suspending..."; \
    systemctl suspend; \
  else \
    echo "suspend-sedation: Woke up, no alarm set, and unplugged. Hibernating..."; \
    systemctl hibernate; \
  fi \
else \
  echo "suspend-sedation: Woke up before alarm - normal wakeup."; \
  /usr/sbin/rtcwake --auto --mode disable; \
fi \
'

[Install]
WantedBy=sleep.target

Oh, I had the same Bluetooth issue as you, too. The second answer in this post solved it for me.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.