💾 Archived View for dctrud.randomroad.net › gemlog › 20191230-guix-luks2.gmi captured on 2020-09-24 at 00:42:41. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

• *TLDR**: Guix can't mount LUKS2 encrypted volumes on boot. If you have existing LUKS2 encrypted volumes then mount them after the system is booted, or convert to LUKS1.

In my last post I mentioned switching to Guix. The first real challenge I hit was on my desktop, where I have an existing SSD and 2xHDD md RAID mirror that are LUKS encrypted. I need to mount these in the Guix system.

Manually assembling the RAID, opening, and mounting the LUKS encrypted filesystems works fine:

# LUKS SSD
cryptsetup luksOpen /dev/sdc1 cryptscratch
mkdir /scratch
mount /dev/mapper/cryptscratch /scratch

# LUKS RAID
guix install mdadm
mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1
cryptsetup luksOpen /dev/md0 cryptdata
mkdir /data
mount /dev/mapper/cryptdata /data 

I next tried to get these setup on boot by adding to `mapped-devices` and `file-systems` in my `/etc/config.scm`

(mapped-devices
...
        (mapped-device
          (source
            (uuid "852f5a67-ece4-44a5-ba1b-caf034786d71"))
          (target "cryptscratch")
          (type luks-device-mapping))
        (mapped-device
          (source (list "/dev/sda1" "/dev/sdb1"))
          (target "/dev/md0")
          (type raid-device-mapping))
        (mapped-device
          (source
            (uuid "d8528380-00a4-4f94-96b3-5bdc83c3699f"))
          (target "cryptdata")
          (type luks-device-mapping))
        ))
(file-systems
... 
         (file-system
           (mount-point "/scratch")
           (device "/dev/mapper/cryptscratch")
           (type "ext4")
           (dependencies mapped-devices))
         (file-system
           (mount-point "/data")
           (device "/dev/mapper/cryptdata")
           (type "ext4")
           (dependencies mapped-devices))
         %base-file-systems))

Doing a `guix system reconfigure /etc/config.scm` raised an error that LUKS devices with the UUID couldn't be found. At this point I changed to `/dev/...` entries, and the system reconfigure did pass. Unfortunately on reboot this leads to being dropped into the early guile shell with:

Locking aborted. The locking path /run/cryptsetup is unusable (not a directory or missing).
Failed to acquire read lock on device /dev/sdc1
Device /dev/sdc1 is not a valid LUKS device

Booting back into the previous generation, I verified that the manual `luksOpen` did still work, with `UUID=...` and `/dev/...` specifications. That lead to grepping the guix source and finding luks-header-uuid pulls the UUID from the device superblock directly. I know enough about LUKS 1 vs 2 from work to understand that the header is quite different for LUKS2, which now explains the guix system reconfigure error when using UUIDs, and the problem on boot.

I could, at this point, choose to keep the devices LUKS2 encrypted, and mount them manually or via script in the booted system. However, I have converted back to LUKS1. This is generally a 2-step process because the default LUKS2 Argon2i PBKDF cannot be used in LUKS1.

1. Convert the key to pbkdf2 which is compatible with LUKS1

<!-- end list -->

cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sdc1

1. Convert the device from LUKS2 to LUKS1

<!-- end list -->

cryptsetup convert /dev/sdc1 --type luks1

Now all my filesystems mount on boot… and perhaps handling LUKS2 mounting on boot is something I could look into a bit in Guix. This would be only for non `/boot` and root drives, as LUKS2 + Argon2i support for the initial GRUB boot stage is still a work in progress according to this savannah bug, so the encrypted boot needs to happen from a LUKS1 device.