swapDevices.*.encrypted doesn't work

[Qubasa]

Describe the bug
The swapDevices.*.encrypted does not work. It tries to swapon the partition containing the luks container instead of the luks container itself.

To Reproduce
$ fdisk -l

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048   2099199   2097152     1G EFI System
/dev/nvme0n1p2   2099200 913858559 911759360 434.8G Linux filesystem
/dev/nvme0n1p3 913858560 976773119  62914560    30G Linux filesystem

$ lsblk -o name,uuid

NAME              UUID
nvme0n1           
├─nvme0n1p1       83CD-FFE4
├─nvme0n1p2       9460e8e9-89bc-4355-9337-f42642d56169
│ └─nixos-decrypt ca22f388-6161-480f-b1cb-7b6359a75c38
└─nvme0n1p3       0cbf5dfd-b148-4e4c-ae75-981a4d62e11e
  └─decryptedSwap 7406719e-134a-4705-9c70-c04abd63f832

  swapDevices = [
    {
      device = "/dev/disk/by-uuid/0cbf5dfd-b148-4e4c-ae75-981a4d62e11e"; ## uuid of partition containing the luks container
      encrypted = {
        blkDev = "/dev/disk/by-uuid/7406719e-134a-4705-9c70-c04abd63f832"; ## UUID of luks container 
        enable = true;
        label = "decryptedSwap";
        keyFile = "${config.secrets}/swap/swap.key";
      };
    }
  ];

$ nixos-rebuild switch

building the system configuration...
activating the configuration...
setting up /etc...
reloading user units for lhebendanz...
setting up tmpfiles
A dependency job for swap.target failed. See 'journalctl -xe' for details.
warning: the following units failed: dev-disk-by\x2duuid-0cbf5dfd\x2db148\x2d4e4c\x2dae75\x2d981a4d62e11e.swap

● dev-disk-by\x2duuid-0cbf5dfd\x2db148\x2d4e4c\x2dae75\x2d981a4d62e11e.swap - /dev/disk/by-uuid/0cbf5dfd-b148-4e4c-ae75-981a4d62e11e
   Loaded: loaded (/etc/fstab; generated)
   Active: failed (Result: exit-code) since Sat 2019-08-10 01:07:25 CEST; 44ms ago
     What: /dev/disk/by-uuid/0cbf5dfd-b148-4e4c-ae75-981a4d62e11e
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)

Aug 10 01:07:25 bln04nb0405 systemd[1]: Activating swap /dev/disk/by-uuid/0cbf5dfd-b148-4e4c-ae75-981a4d62e11e...
Aug 10 01:07:25 bln04nb0405 swapon[12806]: swapon: /dev/nvme0n1p3: read swap header failed
Aug 10 01:07:25 bln04nb0405 systemd[1]: dev-disk-by\x2duuid-0cbf5dfd\x2db148\x2d4e4c\x2dae75\x2d981a4d62e11e.swap: Swap process exited, code=exited status=255
Aug 10 01:07:25 bln04nb0405 systemd[1]: dev-disk-by\x2duuid-0cbf5dfd\x2db148\x2d4e4c\x2dae75\x2d981a4d62e11e.swap: Failed with result 'exit-code'.
Aug 10 01:07:25 bln04nb0405 systemd[1]: Failed to activate swap /dev/disk/by-uuid/0cbf5dfd-b148-4e4c-ae75-981a4d62e11e.
warning: error(s) occurred while switching to the new configuration

I tried switching the uuids around or having the same uuids in blkDev as in device but with no success.

Metadata

- system: `"x86_64-linux"`
 - host os: `Linux 4.19.64, NixOS, 19.03.173251.56d94c8c69f (Koi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.2`
 - channels(root): `"nixos-19.03.173251.56d94c8c69f, nixos-unstable-19.09pre186820.bf39fc17d46"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[JohnAZoidberg]

Hmm, I'm not sure it's possible that way.
Do you need to be able to suspend-to-disk?
Otherwise you can use swapDevices.*.randomEncryption.enable = true

If you do, you cannot use randomEncryption. See the ArchWiki
Two of the three approaches they suggest unlock the rootfs and swap using the same key (they are part of the same LUKS volume). But you want to have them separate and even have the key for the swap on the rootfs - I think that'd prevent you from suspending-to-disk, too.
But even if it didn't want to read it from there, we'd have to make sure to get order right and unlock the swap first.

Summary:
What do you want?
Is our swapDevices.*.encrypted useful/working as it is?

[JohnAZoidberg]

Our script that swapons the device doesn't seem to care about .encrypted.
That's why you see the behavior you're seeing: https://github.com/NixOS/nixpkgs-channels/blob/nixos-19.03/nixos/modules/config/swap.nix#L190

[Qubasa]

Yes, suspend to disk was what I was aiming for! There was a stackexchange answer which said it could/ should be done with a separate partition and I think this was also the idea behind the options given by swapDevices.*.encrypted because you can define a keyfile and a blkDevice so it makes sence to be able to have them separate. I do think suspend to disk will work this way.

To tell the truth I find the current swapDevices.*.encrypted not very useful / quite misleading with its options. It would be great if the script for swapon could be altered to be able to do that.

[gcoakes]

@luis-hebendanz, I'm fairly certain you have blkDevice and device reversed. If I'm understanding the documentation correctly (and that's how I have mine setup), then device is supposed to be the unencrypted block device (e.g. /dev/mapper/cryptswap) and the blkDevice is supposed to be the luks encrypted device. I'm having some issues with swapDevices.*.encrypted myself but my system is at least properly swapping on the proper device.

[Qubasa]

@gcoakes
does suspend to disk work on your machine with an encrypted swap device and decrypting it on boot?
Because if so then I will close this issue :)

[gcoakes]

@luis-hebendanz, not with swapDevices.*.encrypted. Using the settings I described above, my system properly used it as an ecrypted swap device, but it seems to try to decrypt it too late in the boot process to be used for the resume device. Instead I ended up using this workaround. I suspect there is a bug in swapDevices.*.encrypted.

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[tyrion]

Why is this closed? Has anyone confirmed that swapDevices.*.encrypted works as expected? Maybe I did something wrong but I am not able to make it work with a keyFile.

{
  swapDevices = [ {
        device = "/dev/disk/by-uuid/...ad"; # unlocked device
        encrypted = {
          enable = true;
          blkDev = "/dev/disk/by-uuid/...a2"; # encrypted partition
          keyFile = "/keyfile-swap.bin";
          label = "swap";
        };
  } ];
}

[Waelwindows]

Why is this closed? Has anyone confirmed that swapDevices.*.encrypted works as expected? Maybe I did something wrong but I am not able to make it work with a keyFile.

Can confirm it still doesn't work. My setup's essentially the same.

{
  swapDevices = lib.mkForce [
    {
      device = "/dev/disk/by-uuid/31183799-..."; # my decrypted partition in /dev/mapper
      encrypted = {
        enable = true;
        keyFile = "/mnt-root/persist/swap.key";
        label = "swap";
        blkDev = "/dev/disk/by-uuid/b63bf5df-..."; # my encrypted LUKS partition
      };
    }
  ];
}

However, mine fails for another reason. It doesn't even seem to mount and open up the encrypted partition. Instead it waits for the blkDev to "come online" in Nix stage 1, and then fails. Then, it goes to Nix stage 2 where systemd waits for the device to come online and waits for a minute and a half.

[wucke13]

For me, unlocking the swap device works (supposedly even in stage 1, at least no error is reported), and it also ends up activated, but resume does not work. I have the following config:

{
  swapDevices = [{
    device = "/dev/mapper/cryptswap";
    encrypted = {
      enable = true;
      keyFile = "/mnt-root/root/swap.key"; #Yes, /mnt-root is correct.
      label = "cryptswap";
      blkDev = "/dev/disk/by-uuid/...";
    };
  }];
}

Maybe there is a logical error in the lines following https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L465 ?

Edit: Indeed cryptswap's ID_FS_TYPE is reported as swap, not swsuspend as expected in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L466 . Probably therefore the swap partition is not even considered for resume by the stage 1 script.

[AkechiShiro]

@wucke13 what would be a way to fix it ? PR and fixing https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L465 ? Could you open a PR for this issue ? Or should I give a try at fixing it ? Just changing ID_FS_TYPE from swsuspend to swap or adding an or clause ?

[Nick1296]

I have the same problem as the original issue. (using nixos-unstable) it seems that the luks device is not getting unlocked automatically at boot. So in stage 2 nixos is waiting for the swap device to get online and it will eventually boot without the swap partition.

[brianfabre]

I have the same problem as the original issue. (using nixos-unstable) it seems that the luks device is not getting unlocked automatically at boot. So in stage 2 nixos is waiting for the swap device to get online and it will eventually boot without the swap partition.

I'm having the same issue as well. I just disabled my swap until I figure out how to fix it.

[JosephLucas]

FYI I found one hibernation/resume success on encrypted swap partition in 2022

https://discourse.nixos.org/t/unable-hibernate-with-encrypted-swap/23418/4

Otherwise there seems to be another way through a swap file, on a partition system encrypted with LUKS. And another success here too.