> On 7/13/20 4:20 PM, Dudemanguy via artix-general wrote:
> Okay, I finally believe I've gotten to the bottom of this. The short answer is that I don't think this is possible with the current way s6 is setup on Artix, but at the very least it's not an issue with the script. During the boot process, the cryptsetup script gets executed, reads the /etc/crypttab with all the right arguments and everything but there's an error message that's sent to shell. Specifically, "Nothing to read on input". The reason I don't believe this can work as-is is because the early getty service that s6-linux-init starts is designed to capture any output from the started services and print them on /dev/console. This will interrupt any wait on input and thus cause the cryptsetup to fail.
> I haven't tested this, but there are theoretically two potential fixes to this. One would be simply to disable printing on /dev/console. I'm not totally sure anything from the cryptsetup would even print on the early getty in the first place but it is a separate bash/shell call and not a complete execline script so it might work. I don't want to do this though because I've found error output on tty1 to be very useful in debugging and I don't think the tradeoff is worth it.
> The other possibility would be to move the early getty to some other tty (say tty2) and print the cryptsetup stuff on a different tty (like tty1). This would be strange though because a user would have to manually switch to the other tty (you would still boot on whatever the early getty is defined as) and also said getty services would have to start before cryptsetup to work. I also don't think this hypothetical is worth it.
> I know you probably already know this (and maybe already do this), but why not just generate a keyfile instead and add it to the luks device? That can be read on boot just fine and as long as it's in a secure location, it's a better solution than a passphrase anyway. If someone has access to your root, you're already compromised after all.
> Sidenote: I did find a slight error when closing devices on s6. They weren't being unmounted, so at least that should be fixed now.
Hi Dudemanguy, thanks a lot for the update.
I've never tried decrypting luks with keyfiles. I'll have to explore it, since for some daemons (I haven't launched them since I migrated the boxes to s6), I really need all disks/partitions (even external disks) up and running after boot.
Perhaps the keyfile is even a more secure model, I don't know. But so far, any key I host on the boxes is encrypted with some sort of passphrase (like the gpg and ssh ones). I originally was concerned (when I 1st encrypted the disks) I'd have to keep a non encrypted key somewhere, in order to decrypt the disk. Then I realized with grub one could encrypt boot with the key, and somehow, have a way for grub to decrypt boot... I never got the time to experiment with that, :), but it seems it's time to... I do keep boot as a separate partition from the root one and the uefi one.
Another thing for me to investigate is, how to generate a key for an already encrypted partition with password, since that might pose another challenge.
At any rate, thanks a lot for the research and trials. I had hope I didn't have to got the hard way just yet, but it'll be interesting for sure...
Thanks again !
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: OpenPGP digital signature
More information about the artix-general mailing list