originally posted under #1473 (comment) by @natterangell
Debian still asks for the password when booting though (in addition). Is that expected behaviour? I do have encrypted swap, not sure if that affects it(?)
It all depends on the partition scheme. If using BRTFS (same as if using BRTFS under Qubes 4.1+ partition scheme) then two LUKS containers are expected to be unlocked from the TPM disk unlock key. So you should go back into Boot options -> show boot options -> save as default, and answer yes to reseal TPM disk unlock key. But this time, pass the two LUKS containers (eg /dev/sda2 /dev/sda3). Qubes default TLVM partition scheme has it all under a single LUKS container. I guess the information under https://osresearch.net/InstallingOS/#compatibility is not specific enough and could be improved, or the code could suggest found LUKS partitions only to confuse less the user.... Note that BRTFS is not supported within Heads. Only ext4 and TLVM (Thin LVM volume support without thin-lvm-tools). If needs be and tangent is to go torward XFS and BRTFS, we could try to add those tools as well. Note that #1446 is adding support for EXT4 repair tools and ExFat repair tools as well which is now the default for bought sdcards and thumb drives, where Thin LVMs are more and more despised for their added complexity which slows down disk operations.
Also, I'm not sure if https://osresearch.net/InstallingOS/#default-boot-and-disk-unlock is true anymore, since my testing with Talos II and debian invalidates the statement there saying that init doesn't process crypttab: it does, otherwise I would not be able to boot into my OS. @krystian-hebel you reported something similar. What is your partition scheme on Talos II's debian install?
The magic happening in the background here is:
- Heads tries to extract OS initrd and find crypttab there.
- if found, it reuses the UUID there and overrides the config pointing to LUKS key for that entry(ies)
- It creates a secret.cpio containing crypttab override file and the secret used to unlock the LUKS container(s)
- It kexec to the final OS, passing that additional cpio in memory to be extracted on top of initramfs memory
- The OS goes through its normal init script, checks crypttab and attempts to use exposed crypttab file.
@natterangell : So if only one LUKS container is overriden out of many, the final OS will ask for as many LUKS container it doesn't know how to unlock. Let me know if specifying both LUKS containers when setuping a TPM disk unlock key worked (it should: the logic parses those entries and will fail if the partition provided is not a LUKS drive, otherwise leaving slot 0 untouched (disk recovery key) and kills slot1 and then replaces slot 1 with the in-memory generated key corresponding to sealed secret in TPM, which TPM disk unlock key is unsealed with sealed measurements and NV region passphrase. This is why you type a different passphrase on Heads (TPM NV region passphrase to unlock TPM disk unlock key) then on Final OS (Disk recovery key). Hope this clarified everything. Would appreciate if you could do a PR on heads-wiki if that information is unclear to you.
Related: asked question to @marmarek at https://forum.qubes-os.org/t/btrfs-and-qubes-os/6967/28 to see if BRTFS was expected to become the default partition scheme over current TLVM default, since QubesOS is first citizen of Heads. But if all OSes are moving away of TLVM, Heads will need to choose what to support in kernel and on filesystem tools provided for recovery shell. Heads cannot support everything since we are limited in ROM space (until we can switch to squashfs/overlayfs, when: undefined).
It all depends on the partition scheme. If using BRTFS (same as if using BRTFS under Qubes 4.1+ partition scheme) then two LUKS containers are expected to be unlocked from the TPM disk unlock key. So you should go back into Boot options -> show boot options -> save as default, and answer yes to reseal TPM disk unlock key. But this time, pass the two LUKS containers (eg /dev/sda2 /dev/sda3). Qubes default TLVM partition scheme has it all under a single LUKS container. I guess the information under https://osresearch.net/InstallingOS/#compatibility is not specific enough and could be improved, or the code could suggest found LUKS partitions only to confuse less the user.... Note that BRTFS is not supported within Heads. Only ext4 and TLVM (Thin LVM volume support without thin-lvm-tools). If needs be and tangent is to go torward XFS and BRTFS, we could try to add those tools as well. Note that #1446 is adding support for EXT4 repair tools and ExFat repair tools as well which is now the default for bought sdcards and thumb drives, where Thin LVMs are more and more despised for their added complexity which slows down disk operations.
Also, I'm not sure if https://osresearch.net/InstallingOS/#default-boot-and-disk-unlock is true anymore, since my testing with Talos II and debian invalidates the statement there saying that init doesn't process crypttab: it does, otherwise I would not be able to boot into my OS. @krystian-hebel you reported something similar. What is your partition scheme on Talos II's debian install?
The magic happening in the background here is:
@natterangell : So if only one LUKS container is overriden out of many, the final OS will ask for as many LUKS container it doesn't know how to unlock. Let me know if specifying both LUKS containers when setuping a TPM disk unlock key worked (it should: the logic parses those entries and will fail if the partition provided is not a LUKS drive, otherwise leaving slot 0 untouched (disk recovery key) and kills slot1 and then replaces slot 1 with the in-memory generated key corresponding to sealed secret in TPM, which TPM disk unlock key is unsealed with sealed measurements and NV region passphrase. This is why you type a different passphrase on Heads (TPM NV region passphrase to unlock TPM disk unlock key) then on Final OS (Disk recovery key). Hope this clarified everything. Would appreciate if you could do a PR on heads-wiki if that information is unclear to you.
Related: asked question to @marmarek at https://forum.qubes-os.org/t/btrfs-and-qubes-os/6967/28 to see if BRTFS was expected to become the default partition scheme over current TLVM default, since QubesOS is first citizen of Heads. But if all OSes are moving away of TLVM, Heads will need to choose what to support in kernel and on filesystem tools provided for recovery shell. Heads cannot support everything since we are limited in ROM space (until we can switch to squashfs/overlayfs, when: undefined).