<stikonas[m]>As far as I know double password prompt in guix cannot be removed <stikonas[m]>Guix requires world read permissions for everything in /gnu/store <stikonas[m]>So it's impossible to setup autounlock in initramfs without letting world to obtain luks passphrase <oriansj>Gooberpatrol66: you'll see it in the procedure about 5 minutes after I figure it out <oriansj>and Hagfish today I verified your enhancement on a fresh install of arch (it worked great <Hagfish>oriansj: thanks :) i'm glad that little segment of code meets the high standard that i've seen elsewhere in these repos <Hagfish>stikonas[m]: that's an interesting design detail, thank you <Hagfish>i'm wondering whether it would be a valid feature request to keep the password in memory for a few seconds, but i don't even know which component(s) would have to be changed to support that <stikonas[m]>Well, it's possible but much more work than putting it in initrsmfs <oriansj>well one has to put it in the initramfs and then add a hook to have the kernel read it <oriansj>or perhaps more precisely have the init spawned by the kernel use it to mount it <oriansj>well I have a solid idea of how to do it; now just need to figure out the details that go with it. <oriansj>as it appears to be just a simple shell-out for the init using a file in the initramfs <oriansj>after that we just need to do the creation outside of the guix-daemon so it doesn't show up in the store. <oriansj>and ironically I figured out a method to eliminate the need for the luks.key to even be in the initramfs. Essentially the password is used to generate a 4KB file at runtime and inserted into the initramfs that is then passed to the kernel. That 4KB file is generated also during the install time and cryptsetup luksAddKey is used to add it to luks. <Hagfish>so it's sort of automatic? i don't fully understand, but is this the solution that the original designers intended? it sounds kinda neat <oriansj>kaem as init, it runs cryptsetup then execs into /sbin/init <Hagfish>i wouldn't call that stupid... maybe "creative" or "bold"... :D <oriansj>it can't possibliy that straight forward to setup a luks volume right? <Hagfish>i wouldn't know, but kaem as init seems like people would have to trust quite an unusual piece of software to do quite an important job, which it wasn't really designed for <Hagfish>still, i guess it can't be any worse than systemd ;) <oriansj>that would be much less complex than updating a cpio archive <Hagfish>yeah, that sounds like a very natural interface design <oriansj>just need to patch grub and the various inits to support it as any unknown kernel argument is passed to the init <oriansj>so why if it isn't very complex and solves a very real problem, has it not been explored prior? <Hagfish>yeah, i don't know what the competing approach(es) is, or how people might avoid having this use case <oriansj>well if one has a keyfile in the initramfs and a hook to their init to use it, they wouldn't be prompted to type in their password twice <oriansj>it also wouldn't work if boot and / had different passwords <Hagfish>i have found someone else who had the same symptom on a manjaro install: <Hagfish>"After checking the keyslots for the swap partition only 1 is used (root partition uses 2 slots). So I added my cryptfile to the swap partition" <Hagfish>i don't understand the technology enough yet to debug something like that <oriansj>Hagfish: that is just doing cryptsetup open /$partition $name --key-file luks.key and then a mount by the init process <oriansj>So just having the $name in fstab for mounting properly and cryptsetup in the initramfs is enough to solve that <oriansj>say something along the lines of: /dev/mapper/sda1_crypt / btrfs defaults 0 0 <oriansj>think of initramfs as a mini-filesystem stored in /boot that is passed to the kernel unencrypted by your bootloader (grub usually) <oriansj>the kernel, kernel firmware and kernel modules I understand. the usr/bin/mount seems essential as does usr/lib/cryptsetup and etc/fstab <oriansj>possibly etc/lvm and etc/mdadm if you used that <Hagfish>hmm, there's more in that initramfs than i was expecting <oriansj>heck one could probably put Ca Plane Pour Moi by Plastic Bertrand in beep format and have it play during boot <Hagfish>heh, you might need to set a cronjob to delay that commit by 100 years or so... ***janneke_ is now known as janneke
<acrow>plasma41: sadly, there does not seem to have been any kotlin progress for quite some time; after a valiant attempt and remarkable success.