How to resume Ubuntu 18.04 after hibernate?

Question

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_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# FOR HIBERNATION 
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 ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

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

# 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'
#GRUB_GFXMODE=640x480

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

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# 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
done

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

"only the led on the power button indicates any difference to a complete shutdown - that's good". No, that's not. When hibernated a system is completely powered off, it's only the disk configuration that makes a difference between shut down and hibernation. If you see a heartbeat on the LEDs, you are likely in sleep mode. If you get a black screen on wakeup it possibly because your system omits to light up the display, I had that occur to me occasionally on a previous machine and the cure was just to use the screen brightness control keys (that were functional...) to restore the brightness. — xenoid, Mar 19 '20 at 12:36
Hmm, okay then that is not good. However, pressing the screen brightness controls (they work right now) on the black screen does not do anything @xenoid. — lucidbrot, Mar 19 '20 at 12:39
Put your system on a network and try to ping it from another machine, so you can tell if it's running or not despite the black screen. If running, could be worth setting up an SSH connection to it to investigate further. Also what do you get in the logs (append to question)? — xenoid, Mar 19 '20 at 12:58
/var/log/syslog should tell you what happened on sleep/shutdown — xenoid, Mar 19 '20 at 13:25
In the last two minutes (I ran hibernate again approx then), /var/log/syslog got 2k new lines. I have no real idea what to look for. Attaching all 2000 lines seems like a bit much though. At 14:27 there's a message that system.journal corrupted or uncleanly shut down which is reasonable when I force shutdown it — lucidbrot, Mar 19 '20 at 13:37
@xenoid I added a pastebin link with logs to my question. (Also, the broken "hibernated" system does not respond to pings) — lucidbrot, Mar 19 '20 at 13:48
What makes it reboot at 14:39:46? Is that you or did the system reboot on its own? In any case it looks like hibernation didn't complete... — xenoid, Mar 19 '20 at 14:35
After issueing systemctl hibernate, the keyboard lights turn off, the screen turns black, the power button led stays on. The only interaction with the laptop that actually causes something to happen is when I long-press the power button to shut it down forcefully and then press it again to start the device. That is why it started again - I wanted to get the logs — lucidbrot, Mar 19 '20 at 14:41
At lest once give it some time to hibernate, like 15mn. There are some scripts that run on such occasions that have fairly long timeouts. Also, seen this? — xenoid, Mar 19 '20 at 16:41
@xenoid thank you for the link! it hibernated fully within 10 seconds! The open window from the terminal is now open again after booting. nomodeset fixed it! If only I understood why I didn't need that on the first install... — lucidbrot, Mar 19 '20 at 18:14
Please @xenoid feel welcome to post the nomodeset paragraph as an answer. Ideally with an explanation what it does and why I might not have needed that on my previous install, but I will accept your answer also without that — lucidbrot, Mar 19 '20 at 18:20
I didn't give the answer, at best I just nudged you to it. You are perfectly entitled to answer yourself and to accept the answer in a couple of days (I may even upvote it). You are in a better position to explain what was the problem anyway... — xenoid, Mar 19 '20 at 18:31
@xenoid I have a guess for the reason why nomodeset helps, but it could also not be true. I have answered nonetheless. Thank you very much for your time and guidance! — lucidbrot, Mar 19 '20 at 18:46
Looks fine. One last question, now that it works, what does the Power button LED indicates when you hibernate? Completely off? dimmed? "Breathing"? — xenoid, Mar 19 '20 at 20:07
@xenoid it blinks twice short, once long, three times short and then it remains off like everything else (apart from the "I'm charging!-led" — lucidbrot, Mar 19 '20 at 21:07

lucidbrot · Accepted Answer · 2020-07-20T14:02:42.857

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

reboot

Now systemctl hibernate should work.

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

What exactly am I doing? Why does it help?

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.

@xenoid You might be interested to hear that nomodeset caused sound and brightness problems for me. Long explanation here. I haven't yet tested how hibernation is currently behaving. — lucidbrot, Jun 07 '20 at 11:36

score 0 · Answer 2 · answered Mar 19 '20 at 12:33

0

You Probably allocated a very small SWAP partition during the re-installation.
Thus,on trying to hibernate, the data to be saved is way greater than the swap space available.
Hence, the hibernation process gets halted.

answered Mar 19 '20 at 12:33

ByronTaaka

171
6

I have an 18.6G swap partition as reported by fdisk -l and only 16GB actual ram. I'm quite certain that I had the swap partition just so sized on the last install where hibernate and suspend worked – lucidbrot Mar 19 '20 at 12:36
@lucidbrot Using gparted, Right-Click the Swap Partition (which is "/dev/nvme0n1p7" in Your Case.), Then Turn it on by clicking Swapon After that, You Can Try Hibernating. – ByronTaaka Mar 19 '20 at 14:29
Thank you, but it is already on. I only have the option to Swapoff – lucidbrot Mar 19 '20 at 14:33

How to resume Ubuntu 18.04 after hibernate?

2 Answers2

Linked