Comment 10 for bug 1644975

If the swapfile is available as the initrd is handing over to the real system, then it should work (in Bionic and fixed versions back probably beyond Xenial).

What would happen is something like this:

- Grub[2] is loaded from yr /boot, an unencrypted partition or perhaps a USB stick

- Grub loads the initial ram disk (named initrd* but an initramfs in recent Linuxes) image which is responsible for loading the actual system

- the initrd discovers your physical, logical and encrypted disk devices and will attempt to chain to the "actual" boot device as specified in /boot/grub/grub.cfg ("the system disk")

- in this process you have to supply your passphrase or keyfile or token to allow the encrypted system disk to be mounted

- finally the initrd morphs into the system on the system disk.

When resuming from hybrid-sleep (s2both) or hibernation, it is the initrd script /scripts/local-premount/resume, copied to the initrd from /usr/share/initramfs-tools by update-initramfs, that parses the resume and resume_offset kernel parameters from the grub.cfg linux command line. Those parameters may have been entered by hand or by an add-on script in /etc/default/grub (in which case update-grub would be needed to add the parameters).

The initrd resume script, which runs in a environment where all the kernel command-line parameters are available as shell variables, has to translate the resume parameters into a major:minor[:offset] format that is understood by the kernel when written to /sys/power/resume.

If the resume parameters are set, the resume script will have to mount the system disk to verify whether there is a resumable image, and that should trigger the password prompt/use of keyfile or token. You can debug the resume script using the break=premount kernel command-line setting, which leaves you in a limited Busybox shell just before the script would run (Ctrl+D to continue booting).

If the initrd kernel succeeds in loading the resumable image, it will be directly overlaid by the image and you will get a running system as it was when hibernated/hybrid-slept. If not, it will become a newly started system from the root of the encrypted system disk.

When initiating hibernate or hybrid-sleep, the kernel knows about your swapfile and will use it automatically (if it's big enough and there is enough free memory to prepare the image) through the sys/power interface. If your swapfile is on the encrypted system disk (or another encrypted disk), it will automatically be protected.

In systemd versions, a small binary (why?) invokes the necessary commands (printf "suspend|platform|shutdown"> /sys/power/disk; printf "disk"> /sys/power/state) driven by sleep.conf(5); before that the pm-utils kernel method attempted to do the same. It might seem logical to stash the resume info at this point, but that's not what happens: would you want a failed hibernation to destroy your grub.cfg?

This series of processes doesn't seem to be clearly laid out anywhere but I thought it worth recording in case anyone wanted to implement swapfile hibernation on pre-Bionic versions.