You are not logged in.

#1 2022-06-18 20:38:01

Registered: 2022-06-18
Posts: 2

[SOLVED] Swap encryption: resume from hibernation skipped passphrase

Hi all,

i followed instructions per the wiki pages … encryption and … encryption to set up swap encryption using sd-encrypt. I use a swap partition to hibernate (and resume). After some headache, i got that to work consistently.
However, i noticed that whenever i accidentally type in the wrong passphrase when unlocking the swap partition in initramfs during boot, hibernation will silently be skipped and the system will boot normally, essentially discarding the swap partition data and everything saved there when hibernating.

Is that by design? I understand that sd-encrypt cannot unlock the swap partition and just assumes it cannot resume, but i would expect to be prompted for that passphrase again, maybe with an option to skip resume from hibernation. I am also confused since i am prompted again when unlocking other partitions after initramfs.
Since i was not successful in finding that problem on the internet, i wonder what i might have done (or understood) wrong.

My current crypttab.initramfs:

swap         UUID=0d74a479-a97d-48d0-92fb-ff9bbec13ede        none    swap,cipher=aes-cbc-essiv:sha256,size=256,offset=64,noearly

Relevant lines from mkinitcpio.conf:

HOOKS=(systemd autodetect keyboard sd-vconsole modconf block sd-encrypt lvm2 filesystems fsck)

btw, the binary /usr/lib/systemd/systemd-makefs being needed in initramfs is not documented in the wiki, i think it would be useful to add this. Before i added it, i got error messages regarding that binary missing.

Best regards

Last edited by vogeljo (2022-06-18 23:37:22)


#2 2022-06-18 21:02:47

Registered: 2013-11-15
Posts: 1,136

Re: [SOLVED] Swap encryption: resume from hibernation skipped passphrase

You're trying to mix things up... the Wiki link you posted has the crypttab example specifically under the section "Without suspend to disk support"

Now you're trying to use it with resume, and that is problematic.

At minimum you'll have to get rid of the swap option in crypttab:

man crypttab,

           The encrypted block device will be used as a swap device, and will
           be formatted accordingly after setting up the encrypted block
           device, with mkswap(8). This option implies plain.

           WARNING: Using the swap option will destroy the contents of the
           named partition during every boot, so make sure the underlying
           block device is specified correctly.

But you don't want to destroy the existing swap partition, you want to keep it, to resume from it... so it's not doing what you want. You can get rid of the swap option, mkswap the resulting /dev/mapper/swap device yourself, and then start using it after another reboot.

Then you are using this with offset so this is a "hidden" encrypted swap, so the issue is convincing systemd this is essential mandatory and can't be skipped... not sure how to do that, you can try your luck with the tries=x, verify options

The suggestion of the wiki seems to be more along the lines of, use a regular LUKS header, and rd.luks= ... parameters

Even then, the constellation of encrypted swap, but unencrypted / root might still allow systemd to skip past it. In a fully encrypted setup its not possible to continue simply because root it's encrypted and not there.

-- If the crypttab is no longer supposed to run the mkswap for you, most likely you'll also not need the makefs utility.

I'm not sure what the optimal solution is for systemd, I don't use systemd in initcpio myself, and I also don't use hibernate/resume. So you'll have to do some experimentation on your end

So maybe the 'verify' option will help you verify the password (by forcing you to enter it twice) but if you make the same typo twice in a row, you're back to your problem that it will just be skipped over.

PS: of course, I'm stupid, in cryptsetup plain mode without LUKS there is no such thing as password retry or verification, it will open the device with any passphrase and the encrypt result will be different. So what you are asking for is specifically a LUKS feature but you're not using LUKS (if you are using LUKS, get rid of cipher size offset options, too)

So what happens is that systemd (from its point of view) did not skip it... it opened "successfully", mkswap successfully, there was no hibernation image (with wrong password the encrypt result was different already), so at this point it does what it does after a regular shutdown.

Last edited by frostschutz (2022-06-18 21:25:03)


#3 2022-06-18 21:59:15

Registered: 2022-06-18
Posts: 2

Re: [SOLVED] Swap encryption: resume from hibernation skipped passphrase

I was able to fix my issue, thank you so much!

Indeed, i mistakenly used the swap option which had those side effects you described. Had i only looked at that crypttab manual once...
For anyone having similar issues, i resolved mine by re-running luksFormat and then adjusting the UUID and removing all options in crypttab.initramfs.

swap         UUID=<new UUID>        none

Also you are right, makefs is not needed anymore.
I went on a wild escapade before because i accidentally placed lvm2 before sd-encrypt in HOOKS, which led me to experiment with these options like offset and noearly (which is not even an option).
Another great example of Arch Wiki being an excellent source for people who can actually read :-)


#4 2022-06-18 22:51:55

Forum Moderator
Registered: 2012-01-15
Posts: 3,962

Re: [SOLVED] Swap encryption: resume from hibernation skipped passphrase

Please remember to mark your thread [SOLVED] (edit the title of your first post).

How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.


Board footer

Powered by FluxBB