Hibernate – How to Resume Ubuntu 18.04 After Hibernate


I followed this answer two days ago to activate hibernation on my fresh install of ubuntu 18.04 and it worked.

I then managed to break the filesystem so completely that a clean reinstall seemed like the easiest way. So I reinstalled ubuntu (using the "other" option in the installer) with a /tmp, swap, /boot and / partition. Exactly as I did last time. I then followed that answer again to set up hibernate.

Hibernating works – but resuming does not:
When I perform a systemctl hibernate, my laptop screen instantly turns black and only the led on the power button indicates any difference to a complete shutdown – that's good. However, the laptop does not respond to any interaction like keyboard inputs or short presses on the power button. The only option is to press the power button for 15 seconds to cause a forced shutdown, followed by a normal press to start it again.

Here is some information about my system:

generic@motorbrot-linux:~$ cat /sys/power/state
freeze mem disk
generic@motorbrot-linux:~$ grep swap /etc/fstab
# swap was on /dev/nvme0n1p7 during installation
UUID=93232136-5a6d-4ffc-b40d-809ccead48df none            swap    sw              0       0
generic@motorbrot-linux:~$ cat /etc/default/grub 
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=93232136-5a6d-4ffc-b40d-809ccead48df"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)

# Uncomment to disable graphical terminal (grub-pc only)

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

# Uncomment to disable generation of recovery mode menu entries

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

One thing I noticed is that update-initramfs and update-grub displayed its output twice. Following this answer got rid of that, but I'm puzzled why I have two linux image still:

generic@motorbrot-linux:~$ sudo update-grub
[sudo] password for generic: 
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.3.0-42-generic
Found initrd image: /boot/initrd.img-5.3.0-42-generic
Found linux image: /boot/vmlinuz-5.3.0-28-generic
Found Windows Boot Manager on /dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for EFI firmware configuration

I'm looking for guidance on how to make my laptop resume after I sent it into hibernation. In case that is relevant, I have a dual boot system with ubuntu 18.04 and windows 10.

Device             Start        End    Sectors   Size Type
/dev/nvme0n1p1      2048    1085439    1083392   529M Windows recovery environme
/dev/nvme0n1p2   1085440    1288191     202752    99M EFI System
/dev/nvme0n1p3   1288192    1320959      32768    16M Microsoft reserved
/dev/nvme0n1p4   1320960  614399999  613079040 292.3G Microsoft basic data
/dev/nvme0n1p5 614400000  614985727     585728   286M Linux filesystem
/dev/nvme0n1p6 614985728  628658175   13672448   6.5G Linux filesystem
/dev/nvme0n1p7 628658176  667719679   39061504  18.6G Linux swap
/dev/nvme0n1p8 667719680 1953523711 1285804032 613.1G Linux filesystem

I just tried systemctl suspend and the same thing happens there: Screen instantly goes black, and the only way to get it back on is to force shutdown by pressing the power button for about 20 seconds. Sometimes instead of a black screen after suspending, I get a frozen black screen with a cursor on it that won't move. This Answer suggesting that the nouveau driver is at fault did not help.

Pinging the "hibernated" system gets no reaction whereas pinging the fully-booted system does get replies.

Presssing the brightness keys on the black screen causes no reaction.

Here is an excerpt from my /var/log/syslog starting from "sleep requested" and ending at a point where I am reasonably certain that it is part of the booting up that followed, not the "hibernating" itself.

I have tried all three options reboot, platform and shutdown and they all freeze my screen.

I'm currently no longer experiencing this exact problem. For anybody with a thinkpad, perhaps ThinkWiki is helpful

Best Answer

xenoid kindly pointed out a generally helpful article on the ubuntu wiki.

Dead, blank, or black screen on resume In some cases, a machine can hibernate just fine, and resume without issue, with the exception of waking up to a blacked-out screen. In other words, the computer is running just fine, but the display appears dead.

They recommend adding nomodeset to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.
Because I like verbose boot, I did not specify quiet splash as they did in their example, and because I followed this guide I already had GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=<my uuid>". So in the end my line looks like this:

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset resume=UUID=93232136-5a6d-4ffc-b40d-809ccead48df"

After changing that, you need to run

sudo update-grub2

(which happens to do the exact thing as sudo update-grub). And then


Now systemctl hibernate should work.

This question asks the same thing you are wondering right now:

  1. What exactly am I doing? Why does it help?
  2. Can I do something to avoid doing these steps?

The answer suggests to "install suitable video drivers". That may well indicate why I had to add nomodeset this time, but not last time I tried to set up hibernate - my audio driver is also broken, so that could be related (though I don't know why this happened).
It turns out this solution broke my audio card detection and my brightness controls. See here for more info. As of July 2020 it seems like a kernel update or something has fixed this issue for me though.

systemctl suspend does now "work" as well... but for some reason the screen stays on. It's mostly black, but you can tell because there's a white underscore at the top left corner.

Related Question