I’ve been playing around with NixOS and LUKS for the first time in my life during the past one and a half week with pretty good and enjoyable results.
I have set up my system based on mostly the following guide:
I.e. used a EFI partition on a GPT disk as boot and encrypted another partition on the same disk with LUKS, created pv, vg and lv for swap and root on top of it rebuilded nixos the standard way.
I have used systemd and useXkdConfig = true option in the console, not sure about earlySetup though and believed that during stage one the passphrase I am entering is being encoded according to my colemak keyboard layout which I have used during setup to enter and confirm the passphrase.
I’ve done many configuration changes and created 35 generations of nixos which all worked pretty well and at any reboot I was always capable to decrypt the disk with the same passphrase entered.
Then I’ve moved to the unstable channel and believe still was capable to successfully reboot and decrypt, but when trying out configuring with flakes and not absolutely sure to have goten it right a few generations reverted to the stable nixos channel. I’ve did some adjustments on XkbConfig (was using Wayland), tried to make ctrl+alt+del kill which did not work, and remapped caps lock to backspace. Then my computer froze up and I believe that some gnome apps even before that displayed garbled text on choice buttons in dialogs or elsewhere and after a reboot, no matter what I’ve tried I was not capable to get my passphrase accepted. After weeks of usage without any issues suddenly I’ve became unsure about whether it has one trailing character at its end more or less, but otherwise I am absolutely sure that I got it right.
But nevertheless I get “no key available with this passphrase” whether I boot through EFI/systemd on my disk or installation usb.
sudo cryptsetup luksDump /dev/sdb4
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: d97bc8fa-7dbe-4825-8f79-6d2abf8ad979
Label: crypted
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 14
Memory: 1048576
Threads: 4
Salt: d8 81 fe 0d 4e 83 0a b1 71 2b 4f 7e 80 e0 d2 7e
ba 48 34 2a 41 f4 bf 17 b1 af f8 7b 18 93 ec 91
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 428339
Salt: 47 8a 4e 36 7c ce 5d d2 8a d0 ce 7b df 25 af a2
e7 9c de e9 6f 48 4c d5 17 d1 bf a7 7a 89 e1 b5
Digest: 04 e9 29 ae b4 11 07 b4 55 30 41 5b 51 12 ea 11
89 83 57 33 9e 37 9b e8 e0 3b 48 78 38 e0 09 8e
As far as I can tell all seems to be fine. I have a Samsung SDD which Samsung Magician is not capable to analyse for errors more thoroughly, but at least SMART doesnt show anything out of order. I had no issues with it on Windows 11 Pro 64-bit which is installed on its other half.
It does not seem very likely to me that I would have suffered corruption exactly in the LUKS header in such a way that it would not be perceivable.
I thought I had the header and keys backed up on another unencrypted filesystem, but no matter how hard I’ve tried I could not find it anywhere.
Right now I am left with whatever is available in the EFI boot:
/mnt/boot/EFI/Boot
/mnt/boot/EFI/Boot/bootx64.efi
/mnt/boot/EFI/Boot/fbx64.efi
/mnt/boot/EFI/Boot/mmx64.efi
/mnt/boot/EFI/ubuntu
/mnt/boot/EFI/ubuntu/grubx64.efi
/mnt/boot/EFI/ubuntu/shimx64.efi
/mnt/boot/EFI/ubuntu/mmx64.efi
/mnt/boot/EFI/ubuntu/BOOTX64.CSV
/mnt/boot/EFI/ubuntu/grub.cfg
/mnt/boot/EFI/systemd
/mnt/boot/EFI/systemd/systemd-bootx64.efi
/mnt/boot/EFI/Linux
/mnt/boot/EFI/nixos
/mnt/boot/EFI/nixos/02s7x0gv18z968bzjz7nk38a2lgc20l0-linux-6.6.63-bzImage.efi
/mnt/boot/EFI/nixos/h74kbq0zmzhcfy0qv13d89nszayb94z2-initrd-linux-6.6.63-initrd.efi
/mnt/boot/EFI/nixos/.extra-files
/mnt/boot/EFI/nixos/yhdx84xjcswsf7d2ckm251b3v9hizlw9-initrd-linux-6.6.63-initrd.efi
/mnt/boot/EFI/nixos/dspqjs81r9m74805l5fzmp4b9hdib0yd-initrd-linux-6.6.63-initrd.efi
/mnt/boot/EFI/nixos/3dbihkrqfdqsxa5s9pmqxx8slx2rx61x-initrd-linux-6.6.63-initrd.efi
/mnt/boot/EFI/nixos/5zm7p5kyqvzn4ib6px23wl8n73g8v8yg-linux-6.6.64-bzImage.efi
/mnt/boot/EFI/nixos/k5jxd6s7cg3da7kb8aik44cjlbbz37xf-initrd-linux-6.6.64-initrd.efi
/mnt/boot/EFI/nixos/jzl52vx9j42jgn92nynihpniamzwd31p-linux-6.6.64-bzImage.efi
/mnt/boot/EFI/nixos/nxnw0xfh6600yl7vnx6n143j4ny71c4k-initrd-linux-6.6.64-initrd.efi
/mnt/boot/EFI/nixos/977517whn6knicf17cznvrbh57a55iyx-linux-6.6.66-bzImage.efi
/mnt/boot/EFI/nixos/8kkww0a0n8hkzbd6amnrh8y2r272v6bh-initrd-linux-6.6.66-initrd.efi
/mnt/boot/EFI/nixos/rhp6qdkyvqrmpcbmdrbnqqbx6dqaj97v-initrd-linux-6.6.66-initrd.efi
/mnt/boot/System Volume Information
/mnt/boot/loader
/mnt/boot/loader/entries
/mnt/boot/loader/entries/nixos-generation-1.conf
/mnt/boot/loader/entries/nixos-generation-2.conf
/mnt/boot/loader/entries/nixos-generation-3.conf
/mnt/boot/loader/entries/nixos-generation-4.conf
/mnt/boot/loader/entries/nixos-generation-5.conf
/mnt/boot/loader/entries/nixos-generation-6.conf
/mnt/boot/loader/entries/nixos-generation-7.conf
/mnt/boot/loader/entries/nixos-generation-8.conf
/mnt/boot/loader/entries/nixos-generation-9.conf
/mnt/boot/loader/entries/nixos-generation-10.conf
/mnt/boot/loader/entries/nixos-generation-11.conf
/mnt/boot/loader/entries/nixos-generation-12.conf
/mnt/boot/loader/entries/nixos-generation-13.conf
/mnt/boot/loader/entries/nixos-generation-14.conf
/mnt/boot/loader/entries/nixos-generation-15.conf
/mnt/boot/loader/entries/nixos-generation-16.conf
/mnt/boot/loader/entries/nixos-generation-17.conf
/mnt/boot/loader/entries/nixos-generation-18.conf
/mnt/boot/loader/entries/nixos-generation-19.conf
/mnt/boot/loader/entries/nixos-generation-20.conf
/mnt/boot/loader/entries/nixos-generation-21.conf
/mnt/boot/loader/entries/nixos-generation-22.conf
/mnt/boot/loader/entries/nixos-generation-23.conf
/mnt/boot/loader/entries/nixos-generation-24.conf
/mnt/boot/loader/entries/nixos-generation-25.conf
/mnt/boot/loader/entries/nixos-generation-26.conf
/mnt/boot/loader/entries/nixos-generation-27.conf
/mnt/boot/loader/entries/nixos-generation-28.conf
/mnt/boot/loader/entries/nixos-generation-29.conf
/mnt/boot/loader/entries/nixos-generation-30.conf
/mnt/boot/loader/entries/nixos-generation-31.conf
/mnt/boot/loader/entries/nixos-generation-32.conf
/mnt/boot/loader/entries/nixos-generation-33.conf
/mnt/boot/loader/entries/nixos-generation-34.conf
/mnt/boot/loader/entries/nixos-generation-35.conf
/mnt/boot/loader/loader.conf
/mnt/boot/loader/random-seed
/mnt/boot/loader/entries.srel
but otherwise no access to my encrypted root.
I am completely unsure, whether systemd during the first stage is capable to switch the keymap to colemak layout based on the wayland xkbconfig setup. I’ve read complaints that it does not, but if it did not like I believed it would, then I cant explain how it would have been possible for me to decrypt/boot the system so many times by entering the passphrase. But if it does, I am unable to comprehend what could have happened on the flake system rebuilds that could have broken the keyboard mapping on all my generations or luks header corruption or change. SDD corruption does not seem very likely also. I’ve run 5 complete iterations of memtest even with most aggresive memory BIOS settings and no issues were detected. I did not change the LUKS key, digest, algorithms, passphrase, did not touch anything in the header. If there was some corruption then I assume that the header backup somewhere on the same device would got out of sync and LUKS would automatically complain about it but it did not.
I’ve experimented with several hypotheses what could have been wrong and wrote my own and tried out other peoples software to auto transform the passphrase into characters that would be output by a standard US mapping and then tried to enter them with colemak and even tried piping “echo -n passphrase” directly into “cryptsetup open /dev/sdb4 crypted --type luks2” but without any success.
No matter what hypotheses I try to come up with what could have happened they are not consistent with all the conflicting informations about the issue I have.
Any idea what I could do on my side to somehow be able to fix the issue and not loose almost 2 weeks of tuning which I unfortunately was not, due to silly overconfidence in the availability of 100% working bootable previous generations of NixOs and not enough time have not been able to back up yet.
I have even experimented with the Nix system and tried out running garbage collection on it a few hours before the issue appeared. Unsure whether it might have affected anything related.
The system is awesome so far, but unfortunately not as conveniently fool and bullet proof as one might hope it to be.