I’m trying to install IncusOS on the same machine I’d tried to get IncusOS running last December. The system boots, but it goes into a loop showing an error
ERROR Failed to run: systemd-cryptenroll --unlock-tpm2-device-auto --recovery-key /dev/sdb10: exit status 1 (Automatically discovered security TPM2 token unlocks volume.)
In the image customizer, I had selected USB type, Operation usage, stable channel, pasted in my client cert, and no TPM 2.0 module. In my system firmware setup, I enabled secure boot and set the TPM device to “hidden.” I downloaded IncusOS_202608102114.img and flashed it to a 256 GB microSD card in a USB 3.0 reader. During boot, IncusOS displays a message about falling back to swtpm, as expected. IncusOS had rebooted once on its own before getting to this state.
Is there an issue with swtpm and cryptenroll, or is it just not possible to run IncusOS on this admittedly outdated hardware?
I deployed a fresh system using swtpm yesterday and that worked just fine, though that system really didn’t have any TPM at all. Maybe yours isn’t hiding it hard enough somehow?
I tried again with a fresh download of IncusOS_202608290126. Unfortunately, with this old machine, I still get the same “automatically discovered security TPM2 token unlocks volume” error. It does say across the top of the screen that it’s using swtpm.
@johnp789 when your IncusOS system starts up, do you see the message No TPM detected. IncusOS will attempt to fall back to a a less-secure swtpm implementation. right after IncusOS is starting... ? If you do, then I think something’s going wrong with swtpm initialization; if you don’t, then there’s an issue with your system not fully hiding the physical TPM, which then results in two different TPMs being available and systemd-cryptenroll is getting confused.
Also, it’s interesting that you’re getting that error for /dev/sdb10, which is the second partition that is LUKS-encrypted. If you reinstall, do you consistently only see the error on that partition, or do you also see an error for /dev/sdb9?
I’m leaning towards thinking this is an issue with the “hidden” physical TPM not being so hidden. If I manually corrupt the swtpm state I get a different error, not one propagating from an -ENOENT like what you’re seeing.
Also, I booted another live-USB Linux distribution, got to a shell, and confirmed that there was nothing like /dev/tpm0 present there.
On this latest IncusOS reinstall (live USB boot, actually), I saw the error for /dev/sdb10 again. I haven’t noticed if a different partition is ever reported with an error, unfortunately.
So something very strange is going on then with swtpm… trying to reproduce what you’re seeing in a VM hasn’t been successful so far. I have ruled out both the swtpm service not properly running and corrupted swtpm state, as those both result in different errors. I wonder if there’s perhaps some sort of service dependency ordering issue that for whatever reason is cropping up on your particular hardware.
It’s also really weird that you’re not encountering an error trying to encrypt the 9th (swap) partition before the 10th (root) partition.
@johnp789 could you share details about the system you’re attempting to run IncusOS on? (Particularly, CPU and RAM would be interesting.)
I’ve managed to get the same failure as you reported by attempting to run IncusOS on a VM with extremely limited RAM resulting in the swtpm service failing in the initrd. When swtpm then starts up post-initrd, the TPM state is incorrect and therefore fails to properly setup disk encryption. (The error “No such device or address” turned out to be quite misleading, as the TPM itself exists and works; it’s the PCR policy embedded into IncusOS that doesn’t properly match and fails.)
I think what may be happening for you is that systemd-repart is either failing or not completing before the initrd exits. In my case, with the busted swtpm, systemd-repart also failed in the initrd, but then launched once the system was running. IncusOS also started, but exited with an error about the swap partition not existing. The incus-osd service then auto-restarted after a brief delay, during which time systemd-repart completed, and so on the “second” first start IncusOS found the expected partitions but now with a bogus TPM state hit the same error you’re seeing.
I’ve got a PR that will catch a swtpm failure in the initrd during boot, and after the next IncusOS release I’d be interested to see if you still see the same failure, or see a report that swtpm has also failed for your system.
The old machine I’m trying to get running is an HP t630 thin client with an AMD GX-420GI CPU and 16 GB of RAM. There is a 128 GB SATA SSD installed which I can try as a target storage device if I can get past the boot issues. The Infineon TPM chiporiginally shipped as a TPM 1.2 device, but I’ve done a firmware update to make it TPM 2.0 compatible.
I actually have a second t630, too, with 8 GB RAM and a 256 GB SSD. When I bought them as used computers 5 years ago, I had planned to use them for a mini hobby cluster setup.
Please let me know if there is anything I can test on this machine.
If I manually corrupt the swtpm state I get a different error, not one propagating from an -ENOENT like what you’re seeing.