To mount the decrypted disk during boot, it's necessary to make the kernel aware of the fact that it's something that should be mounted. There are several ways to do this, two of which are:
1. The most preferable way, I think, would be to use something like kpartx from multipath-tools. Kpartx is a very simple C program, and device mapper is used directly in that case. You could also use partprobe. So the command is something like `kpartx -a disk` or `partprobe disk`.
2. Another option is to use LVM, like described here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... (there are also other encryption options described there). Using LVM is a solution that works more out-of-the-box, but, of course, then you always depends on LVM, which may not be something you want.
If I use the keyfile feature, the dt2000 boot will automatically unlock my FDE, making the inconvenience a bit of a wash with arguably improved overall security. It's also nice that I can unlock the dt2000 in private or otherwise independently from the laptop, since it has a battery. Think bathroom break to unlock, insert to boot on return kind of thing. It also supports a read-only mode, requiring switching to writable whenever updating the kernel/initrd.
For a laptop, you’re already lugging it around anyway, just remove the USB drive whenever you shut it down.
all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.
Thank you Captain Obvious.
> And unlike the other folders, if you lose this one you lose the whole system
Yeah, that's how encryption works.
> but bit flips for any reason
Way to move the goalposts. Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. Which, again, is totally overkill for the average user.
If your entire system is vulnerable to a single bit flip and you don't care then, you may be on the wrong website.
> Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either.
This is HN, not your typical computer user's website. My personal desktop workstations use both registered ECC and mirrored ZFS (along with immutable reproducible builds, among other things to enhance system integrity and reliability).
And I have no compunction whatsoever about recommending on this site that people use cheap and easy methods to safeguard against LUKS header corruption, like backup USBs and faraday bags.
That's an extremely cheap form of risk management that could prevent loss of your entire hard drive due to a single bit flip. If I were recommending something prohibitively expensive relative to the potential losses, your objections might be reasonable, but I'm not.
> Which, again, is totally overkill for the average user.
Again, this isn't a site for the average user, expect folks here to practice and recommend higher standards for computer system management.