Resume from disk (swapfile) fails

[Ryo Onodera]

Well, hibernation with swap file doesn't work while hibernation with swap partition works perfectly fine with the exactly same configuration and hardware.

The reason is that when resuming from swap file, initramfs script can't correctly detect the machine are hibernated from the last shut down.

And I investigated the issue and found this patch solved https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/554009/+attachment/1366060/+files/resume.patch) for the hibernate to work.

And it isn't applied to the package. I'd like to help this is really applied to the official package.

In short, my setup is swapfile inside the system filesystem (LUKS + LVM2 + ext4).

Also, I roughly followed this tutorial to prepare this configurartion that: https://ubuntuforums.org/showthread.php?t=1042946

I've opening this bug because the original bug report is closed and getting no response...

[Ryo Onodera (ryoqun)]

I'm marking this status to confirmed because this is a re-open of https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/554009

[Ryo Onodera (ryoqun)]

Hi! Some time passed...

Will this bug be addressed?

[Wladimir Palant (palant)]

I can confirm that the following statement in https://help.ubuntu.com/community/SwapFaq#Why_do_I_need_swap.3F is wrong:

> The hibernation implementation currently used in Ubuntu, swsusp, needs a swap or suspend partition. It cannot use a swap file on an active file system.

In fact, swsusp supports offsets just fine, and so does initramfs-tools - mostly. The only thing blocking hibernation to a swap file from working is that check in /usr/share/initramfs-tools/scripts/local-premount/resume script. It calls wait-for-root which returns "ext4" because no offset has been passed in. So the script will just assume that no hibernation occurred and continue without resuming. While I opted for simply removing the check, I strongly suspect that Ryo's patch will fix the issue just as well.

[Dirk F (fieldhouse)]

Reviewing the patch from bug 554009, I have the following comments:

- as the patch sets SWAPTYPE, no need to set it in line 24 of the original script immediately before the patch: just run wait-for-root (if that is actually needed);

- the test for $resume_offset would be safer if it looked for a number, eg:
[ "${resume_offset}" -ge 0] 2>/dev/null

- lines 63-67 of the original script can be replaced by line 64 only: no need for a separate resume_offset case.

I confirm that the patch enables hibernation and hybrid-sleep to a /swapfile using uswsusp with LXLE 16.04 identifying as "4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:58:51 UTC 2017 i686 i686 i686 GNU/Linux", and also with the above changes.

Why is no-one picking this up? Still 3.5 years of support for Ubuntu 16.04 LTS.

[Dirk F (fieldhouse)]

Bug 983805 also applies to the /usr/share/initramfs-tools/scripts/local-premount/resume script.

[Dirk F (fieldhouse)]

In the latest upstream version 0.130 <https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/tree/scripts/local-premount/resume>, the faulty script has been rewritten, with supporting sourced scripts.

Perhaps a better solution would be for Ubuntu to pull in this version, and repackage it for Aardvark and LTS releases.

[Mario Limonciello (superm1)]

Thanks for those of you who added the various patches for this. I've updated them relative to 0.130 and i'm uploading them to bionic.

I've also submitted a bug to Debian with the patch for this (but I haven't gotten the BTS email yet).

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.130ubuntu3

---------------
initramfs-tools (0.130ubuntu3) bionic; urgency=medium

  * Fix resuming a hibernate session from a swapfile (LP: #1644975)

 -- Mario Limonciello <email address hidden> Tue, 20 Feb 2018 15:34:46 -0600

[Steve (stevebot)]

Does this mean that hibernation + swapfile + LUKS encryption will work on bionic?

[Dirk F (fieldhouse)]

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.

[Andrej Shadura (andrew.sh)]

@superm1, your fix makes the boot process very slow on one of the machines, it takes a minute or more for it to time out waiting for the resume device.

People also complain here: https://askubuntu.com/questions/1013830/slow-boot-long-kernel-load-time-due-to-wrong-resume-device

[Dirk F (fieldhouse)]

In the related bug #1763611, it is concluded that the Ubiquity installer incorrectly set up /etc/initramfs-tools/conf.d/resume to reference a non-existent disk UUID, causing a 30-40s delay in startup.

Surely that file is obsolete (because it doesn't help resume from swapfile, eg) and should be removed from the installation?