[solved] Encrypted swap file in a non-root partition for hibernation

archdub · 2025-08-08 08:19:41

My laptop has the boot loader and unencrypted kernels in the EFI partition, and two partitions with LUKS2, the first mounted as / (root), and the second as /pool1. I have /pool1/home mounted as /home.

I am doing experiments with swap files. In experiment A I had /swapfile, and in experiment B I had instead /pool1/swapfile, that is, the swap file in respectively the first or the second partitions (not both simultaneously). Swap worked fine in both experiments A and B, that is the laptop boots, the systemd hook in mkinitcpio does its magic, and at the end of boot swap is on and all is good.

My next test was with hibernation. In this case, systemd magic worked in experiment A as it correctly resumed from hibernation, but failed in experiment B. In experiment B, what I see on the screen is that after entering the LUKS2 passphrase, systemd says it is waiting up to 2 minutes for a device whose UUID is that of the file system in /pool1. After the two minutes pass, systemd gives up on resuming from hibernation and boots as if it had not hibernated, discarding the hibernate data in the swap file and clearing the EFI variable that says where to find the swap file.

I could not find anything in the wiki about this use case, nor by googling. I guess that if a solution exists it will involve either a kernel parameter or a systemd unit or both.

Any ideas?

Last edited by archdub (2025-08-12 21:31:47)

sipak · 2025-08-09 03:45:59

Just to be sure, you do not have the swapfiles encrypted, but the partitions that host it, right?

When you boot, / is read first, and the kernel can then use its swap to resume. When you use it in a separate partition using systemd, the init has already started when you try to resume it. There probably is a way to force systemd to read it earlier tho...
Try to add a keyfile to the /pool1 luks, then add an entry to /etc/crypttab. This way the system will trigger its mount early on boot. It also saves you from entering the luks password again. Note: You can also place the keyfile on a usb key so the system requires the usb to be plugged in to boot (extra security).

seth · 2025-08-10 07:58:41

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Post the exact details of the setup (kernel commandline and lsblk -f) and in doubt also link a photo of the output of the failing resume.

https://wiki.archlinux.org/title/Dm-cry … _swap_file - make sure to see the blue note.

archdub · 2025-08-11 19:14:30

Sorry for the late answer, I was busy with a few things.

sipak wrote:

Just to be sure, you do not have the swapfiles encrypted, but the partitions that host it, right?

Exactly.

sipak wrote:

Try to add a keyfile to the /pool1 luks, then add an entry to /etc/crypttab.

I did what you suggested with a difference: I used a file with the password instead of a key file. It did not work.

That said, I found the answer I was looking for, more on that in a following post.

archdub · 2025-08-11 19:20:24

I found the answer I was looking for. To recap, my question was this: how to configure an encrypted swap file in a non-root partition to be used not only for swapping but also for hibernation? Since I had mentioned that I was using the systemd hook in mkinitcpio, I only looked for an answer in that scope.

This is what I have in /etc/mkinitcpio.conf:

HOOKS=(base systemd keyboard autodetect microcode modconf kms sd-vconsole block sd-encrypt filesystems fsck)

I created a file /etc/crypttab.initramfs [1] with these contents:

arch-root  UUID=ac473471-7559-4b13-8865-ddb4f6573b90 none luks,timeout=180
arch-pool1 UUID=7dfb725b-c558-459c-b37f-8d87c6ce953e none luks,timeout=180

The passphrase for the two partitions is the same. Because systemd caches it, I am asked for it only once. With the above I am telling systemd in early boot, before it decides if it should resume or not, how to access both root and pool1.

I am using systemd-boot. This is the entry:

title   Arch Linux (lts)
linux   /vmlinuz-linux-lts
initrd  /initramfs-linux-lts.img
options root=/dev/mapper/arch-root rw vconsole.keymap=uk fbcon=font:TER16x32 resume=/dev/mapper/arch-pool1 resume_offset=44236800

Two crucial details here. The first one is the absence of “rd.luks.name” which I had in this file before the addition of /etc/crypttab.initramfs [2]. The second is the presence of resume_offset. To calculate it I used an AUR tool [3]. Can I trust this tool? One of the contributors [4] of the github repo from which this tool is downloaded is the author of the relevant kernel documentation on swap suspend [5].

The tool must be run as root. The value returned by it is manually inserted in the resume_offset kernel parameter.

~/ swap-offset /pool1/swapfile
resume offset = 44236800

If the swap file is in the root partition, it is not necessary to have an entry in /etc/fstab, however such an entry is required in the case of a non-root partition.

/pool1/swapfile                         none            swap            defaults        0 0

That is it.

[1] see line #52 in /usr/lib/initcpio/install/sd-encrypt
[2] see warning in red box in https://wiki.archlinux.org/title/Dm-cry … -generator
[3] https://aur.archlinux.org/packages/uswsusp-git
[4] https://github.com/rjwysocki
[5] https://docs.kernel.org/power/swsusp-an … files.html

Edit #1: mentioned /etc/fstab, fixed grammar
Edit #2: fixed introduction
Edit #3: more succint

Last edited by archdub (2025-08-12 21:31:11)

sipak · 2025-08-12 17:06:50

Using password and using keyfile work different and are triggered at different times. That is why I suggested using a keyfile rather than password for pool1.
Can you trust random AUR? No. Yes. Up to you. AUR is user-contributed. They are not audited. Can you get ugly code and even hacked from AUR? Absolutely. It is up to you to analyze every single AUR and determine whether you trust it or not.

Arch Linux

#1 2025-08-08 08:19:41

[solved] Encrypted swap file in a non-root partition for hibernation

#2 2025-08-09 03:45:59

Re: [solved] Encrypted swap file in a non-root partition for hibernation

#3 2025-08-10 07:58:41

Re: [solved] Encrypted swap file in a non-root partition for hibernation

#4 2025-08-11 19:14:30

Re: [solved] Encrypted swap file in a non-root partition for hibernation

#5 2025-08-11 19:20:24

Re: [solved] Encrypted swap file in a non-root partition for hibernation

#6 2025-08-12 17:06:50

Re: [solved] Encrypted swap file in a non-root partition for hibernation

Board footer