Updating one of my laptops from Ubuntu 16.04.5 LTS (Xenial Xerus) to Ubuntu 18.04.1 LTS (Bionic Beaver) was a completely straightforward process. Ubuntu certainly succeeded in creating an end user compatible GNU/Linux distribution.
The only thing that did not work for me immediately was hibernating the machine. This however is an important part of the workflow for this machine. As I carry it around a lot, I certainly don't want to shutdown the system every time I move it. My usual work space containing a terminal with four tabs, GNU/Emacs and Firefox is not very difficult to launch, but it is still a nuisance doing this multiple times a day. Suspending the system to RAM is certainly fast and solves the startup problem nicely, but sometimes (e.g. over the weekend) it happens that the system looses power and potentially some recent work.
Hibernation is the best compromise. It solves the power problem as the system dumps all active memory to swap and shuts down the system completely. On boot the system notices the presence of a hibernation image and re-initializes from it. Although a bit slower than suspend, it is still a lot faster than shutting down the whole system every time.
After the update, the system still went into hibernation fine. I
usually enter hibernation with
systemctl hibernate as GNOME does
not have an easy way to trigger this, but on the next boot it simply
ignored the hibernation image.
Searching the web quickly showed that other people also experience problems on resume in Ubuntu 18.04, so I had a lead on what may go wrong. The most difficult part of the setup is to inform the Linux kernel on the next boot on where to find the hibernation image. For me this was solved by adjusting /etc/default/grub accordingly:
[dzu@harry ~]$ grep CMDLINE_LINUX= /etc/default/grub GRUB_CMDLINE_LINUX="resume=/dev/sda6 loop.max_part=63" [dzu@harry ~]$
Following the lead from the Ubuntu forum, the first thing to try was to change the naming into the UUID scheme. Actually I wanted to do this for some time as it is "The Right Thing", but never bothered. So finally there is a real reason for doing it, Ok. Using blkid quickly shows me what to change:
[dzu@harry ~]$ blkid /dev/sda6 /dev/sda6: UUID="fb9cddc3-c496-4922-92b6-558168c47a65" TYPE="swap" PARTUUID="9bc79944-06" [dzu@harry ~]$
Changing the grub configuration is then easy enough:
[dzu@harry ~]$ grep CMDLINE_LINUX= /etc/default/grub GRUB_CMDLINE_LINUX="resume=UUID=fb9cddc3-c496-4922-92b6-558168c47a65 loop.max_part=63" [dzu@harry ~]$
sudo update-grub commits the changes to the boot partition
and indeed this was enough to make hibernation work again. Hooray!
On subsequent updates it became clear the initramfs tools are not happy about inferring the resume parameter:
[dzu@harry ~]$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.15.0-43-generic cryptsetup: WARNING: failed to detect canonical device of /dev/sda6 I: The initramfs will attempt to resume from /dev/sda6 I: (UUID=fb9cddc3-c496-4922-92b6-558168c47a65) I: Set the RESUME variable to override this. [dzu@harry ~]$
This is easy enough to fix:
[dzu@harry ~]$ cd /etc/initramfs-tools/conf.d/ [dzu@harry conf.d]$ sudo bash -c "echo RESUME=UUID=fb9cddc3-c496-4922-92b6-558168c47a65 > resume" [dzu@harry conf.d]$ ls -l total 4 -rw-r--r-- 1 root root 49 Feb 13 10:49 resume [dzu@harry conf.d]$ cd [dzu@harry ~]$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.15.0-43-generic cryptsetup: WARNING: failed to detect canonical device of /dev/sda6 [dzu@harry ~]$
So this concludes the finishing touches to make the system work again. Note that the complex bash invocation is necessary to make the redirection work with root rights. It is left as an exercise to the reader why this more straightforward construction fails: