`ujust setup-luks-tpm-unlock` fails on bluefin-dx

[Floppy-disko]

Describe the bug

In a fresh install following this article for the framework 16: https://universal-blue.discourse.group/t/bluefin-bazzite-for-framework-laptops/1820 To enable tpm unlocking I have to run: ujust setup-luks-tpm-unlock I get: error: Recipe 'setup-luks-tpm-unlock' failed with exit code 1 Tpm unlocking is not enabled since I get asked a password even when having secure boot enabled

What did you expect to happen?

I expected to enable tpm unlocking for the root partition

[m2Giles]

There should of been an additional error message above the line that says error: ...

What did that say?

[StudioLE]

I get the same error, although on a desktop as opposed to Framework laptop

First time I ran

ujust setup-luks-tpm-unlock

This will modify your system and enable TPM2 auto-unlock of your LUKS .... are you good with this? y
Device /dev/disk/by-uuid/ is not compatible.
Enrolling TPM2 unlock requires your existing LUKS2 unlock password

Device /dev/disk/by-uuid is not compatible.
Failed to allocate libcryptsetup context: Block device required
TPM2 already present in initramfs.

TPM2 LUKS auto-unlock configured. Reboot now.

Subsequent runs just return:

Our backup already exists at /etc/crypttab.known-good\nExiting...
error: Recipe `setup-luks-tpm-unlock` failed with exit code 1

[m2Giles]

Thank you for that log.

In your case it is not finding a disk encrypted with luks2 or at least its not finding one with the expected name. Is your disk encrypted with luks2?

Additionally, the script will not rerun if there is a backup of the crypttab. You can remove it with ujust remove-luks-tpm-unlock

[StudioLE]

Yes, the disk shows as "LUKS Encryption (version 2)" . Is there any documentation for how this ujust feature works?

[m2Giles]

With ujust --choose you can see what each individual command will run. For the tpm unlock it will run the following script:

https://github.com/ublue-os/config/blob/main/build/ublue-os-luks/luks-enable-tpm2-autounlock

This script was tested on numerous devices before including it on systems by default.

[StudioLE]

From my vague reading the script seems to make an assumption that DISK_UUID is valid. There's no check of whether it's empty or that the disk even exists.

DISK_UUID=$(sudo awk '{ print $2 }' /etc/crypttab | cut -d= -f2)

https://github.com/ublue-os/config/blob/5c4144d38a2a61e44ca704ffdf2d50bbcb9ff7ed/build/ublue-os-luks/luks-enable-tpm2-autounlock#L16-L17

In my case /etc/crypttab is empty meaning DISK_UUID is empty, and CRYPT_DISK is then assigned /dev/disk/by-uuid/ and passed to all the subsequent commands which presumably fail but the script only seems to check whether commands succeed, in the event of failure it just seems to keep going?

[m2Giles]

The script has set -u set which should fail on unbound variables.

I'm now curious why that is not occuring in your case.

Additionally, if you do not have a crypttab setup are you manually running cryptsetup on each mounting of your drive?

/etc/cryptsetup is automatically populated with the root disk when using the installer and selecting encrypted disk.

[fiftydinar]

The script has set -u set which should fail on unbound variables.

But the variable isn't unbound, it's empty. That's a difference.

[m2Giles]

Ah. I see.

We'll add that to the script. We will likely refactor it a bit to handle some more situations. Maybe we'll only get the luks uuid from the kargs and not relying on crypttab.

[StudioLE]

It also doesn't have -o pipefail

Without which (I think) a failure of cryptsetup luksDump $CRYPT_DISK

in this line:

cryptsetup luksDump $CRYPT_DISK | grep systemd-tpm2 > /dev/null

would be ignored because the grep still succeeds.

Bash is a pretty poor scripting engine due to its complexity. I would highly recommend rewriting these in something less prone to error if the intention is to present them so visibly to user (as I highlight in #1487).

edit: This would also make it easier to audit what the script is doing. Whereas bash syntax is such a mess that that becomes near impossible for even advanced users.

[StudioLE]

Additionally, if you do not have a crypttab setup are you manually running cryptsetup on each mounting of your drive?

/etc/cryptsetup is automatically populated with the root disk when using the installer and selecting encrypted disk.

It's an additional partition encrypted with LUKS2 that already existed when I installed Bluefin as part of a multiboot setup so I didn't tick that little box in the installer. At present I'm manually opening the Gnome "Disks" GUI utility to decrypt/mount it which is rather tedious. So when I saw this ujust command advertised it seemed precisely what I was looking for, alas it now seems this is not the kind of use case that the script is designed for.

[m2Giles]

Okay. That was outside the scope of what was envisioned for that script.

The script is expecting to decrypt the root device that was setup using the installer.

I've rewritten the script in the repo that it lives in. See here https://github.com/ublue-os/config/pull/302

It is again focused on that smaller scope and will explicitly fail out it it cannot find the disk. Additionally it will get the disk from the kernel cmdline instead of /etc/crypttab.

For your current specific use case. I would recommend looking at the specific tool we are using which is systemd-cryptenroll. You can review the man page which has examples at the bottom for enrolling a key into a key slot. You will also need to add your drive to the crypttab and fstab for it to auto unlock and auto mount or write the appropriate units.

Additionally, this is far different than what the original issue that was posted. That they could not decrypt their root device with a tpm using the script.