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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1644975
Title:
Resume from disk (swapfile) fails
Status in initramfs-tools package in Ubuntu:
Fix Released
Status in initramfs-tools package in Debian:
Incomplete
Bug description:
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...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1644975/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
