.. title: Hibernation in Ubuntu 18.04 LTS
.. slug: hibernation-in-ubuntu-1804-lts
.. date: 2019-02-12 18:47:36 UTC+01:00
.. tags: 
.. category: 
.. link: 
.. description: 
.. type: text

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.

.. image:: /images/suspend_tux.png
   :width: 250
   :align: center
   :alt: Hibernating Linux

.. TEASER_END

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
<https://ubuntuforums.org/showthread.php?t=2391841>`_, 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:

.. code-block:: console

  [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 <http://man7.org/linux/man-pages/man8/blkid.8.html>`_
quickly shows me what to change:

.. code-block:: console

  [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:

.. code-block:: console

  [dzu@harry ~]$ grep CMDLINE_LINUX= /etc/default/grub
  GRUB_CMDLINE_LINUX="resume=UUID=fb9cddc3-c496-4922-92b6-558168c47a65 loop.max_part=63"
  [dzu@harry ~]$
  
Running ``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:

.. code-block:: console

  [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:

.. code-block:: console

  [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:

.. code-block:: console

  [dzu@harry ~]$ cd /etc/initramfs-tools/conf.d/
  [dzu@harry conf.d]$ sudo echo test > bar
  -bash: bar: Permission denied
  [dzu@harry conf.d]$