Cryptsetup does not understand tpm2-device option

Asked by Christopher Hall

The end goal is to have tpm2 autounlock using systemd-cryptenroll. The systemd-cryptenroll functionality for tpm2 was just turned on yesterday, before that it said 'tpm2 not supported on this build'

I have this working on fedora

The pieces needed are tpm2-tools
a tpm2 chip/ post gen 8 intel proccessor
the tpm2-tss module

You enroll the key in the tpm register 7 with
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdx

You update crypttab to put tpm2-device=auto,discard in the options
then you add the tpm2-tss to the initramfs module list and update-initramfs

The last step makes it look like cryptsetup is not built to support tp2 devices. Is this something that needs to be updated with cryptsetup?

update-initramfs: Generating /boot/initrd.img-5.15.0-40-generic
cryptsetup: WARNING: sda3_crypt: ignoring unknown option 'tpm2-device'

Question information

Language:
English Edit question
Status:
Needs information
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Bernard Stafford (bernard010) said :
#1
Revision history for this message
Christopher Hall (christopher88hall) said :
#2

I am aware of the system-cryptenroll bug thread, I'm the last poster on it.

The issue I am having is with cryptsetup, systemd-cryptenroll enrolls the key in the tpm properly

Revision history for this message
Bernard Stafford (bernard010) said :
#3

https://github.com/systemd/systemd/issues/22129
https://gist.github.com/chrisx8/cda23e2d1fa3dcda0d739bc74f600175
Read the very last entry on github.
Has to do with Trust and permissions.
Edit the permissions and the trust of signed ca certs for server.
https://gist.github.com/chrisx8/cda23e2d1fa3dcda0d739bc74f600175?permalink_comment_id=3920068
Question: Do you have LUKES2-partitioning ?

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#4

None of these are the same issue.

The error it gives is pretty self-explanatory, cryptsetup does not think tpm2-device is a valid option, for engaging with the partition.

root@ubuntu:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.15.0-40-generic
cryptsetup: WARNING: sda4_crypt: ignoring unknown option 'tpm2-device'
root@ubuntu:~# cat /etc/crypttab
sda4_crypt UUID=1e25ad74-6f97-46d3-9f1e-e1ed2082f2d7 none tpm2-device=auto

The TPM has decryption keys registered in slot number 7. To Auto decrypt a luks2 partition.

I don't think this has anything to do with trust and permissions or exotic configs. I think this has to do with the builds not having TPM2. support enabled. Systemd-cryptenroll was just compiled with it on 2 days ago in jammy-updates.

Revision history for this message
Manfred Hampl (m-hampl) said :
#5

For diagnostic purposes, what is the output of the commands

uname -a
lsb_release -crid
command -v update-initramfs
command -v cryptsetup
dpkg -S $(command -v update-initramfs) $(command -v cryptsetup)
apt policy initramfs-tools cryptsetup-bin

Revision history for this message
Christopher Hall (christopher88hall) said :
#6

here you go

root@ubuntu:~# uname -a
Linux ubuntu 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:54:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy
root@ubuntu:~# command -v update-initramfs
/usr/sbin/update-initramfs
root@ubuntu:~# command -v cryptsetup
/usr/sbin/cryptsetup
root@ubuntu:~# dpkg -S $(command -v update-initramfs) $(command -v cryptsetup)
initramfs-tools: /usr/sbin/update-initramfs
dpkg-query: no path found matching pattern /usr/sbin/cryptsetup
root@ubuntu:~# apt policy initramfs-tools cryptsetup-bin
initramfs-tools:
  Installed: 0.140ubuntu13
  Candidate: 0.140ubuntu13
  Version table:
 *** 0.140ubuntu13 500
        500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu jammy/main i386 Packages
        100 /var/lib/dpkg/status
cryptsetup-bin:
  Installed: 2:2.4.3-1ubuntu1
  Candidate: 2:2.4.3-1ubuntu1
  Version table:
 *** 2:2.4.3-1ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Manfred Hampl (m-hampl) said :
#7

Strange.
In https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1969375/comments/17 the same commands that you used in comment #18 did work.

Do you have the package libtss2-rc0 installed?

Revision history for this message
Christopher Hall (christopher88hall) said :
#8

right,it worked for dean huffman but there are two of us in that thread having the 'cryptsetup doesnt understand tpm2-device'

I'm guessing hes got packages or package versions on his testbox that we dont have.

root@ubuntu:~# apt install libtss2-rc0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libtss2-rc0 is already the newest version (3.2.0-1ubuntu1).

Revision history for this message
Manfred Hampl (m-hampl) said :
#9

You might consider trying to contact dean huffman to ask him about the package versions that he has.

Revision history for this message
Dean Huffman (deanhuff) said :
#10

@christopher88hall, which packages are you looking for specifically? For my setup, I install my machines with via a clout-init script, the encrypted luks partitions already existed on the system prior to me upgrading systemd and setting up systemd-cryptenroll.

here's what my test box is running for starts with systemd & starts with crypt:

root@testbox:~# apt list | egrep -i '^systemd|^crypt' | grep installed

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

cryptsetup-bin/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed,automatic]
cryptsetup-initramfs/jammy,now 2:2.4.3-1ubuntu1 all [installed,automatic]
cryptsetup/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed,automatic]
systemd-container/jammy-updates,jammy-proposed,now 249.11-0ubuntu3.3 amd64 [installed]
systemd-sysv/jammy-updates,jammy-proposed,now 249.11-0ubuntu3.3 amd64 [installed]
systemd-timesyncd/jammy-updates,jammy-proposed,now 249.11-0ubuntu3.3 amd64 [installed]
systemd/jammy-updates,jammy-proposed,now 249.11-0ubuntu3.3 amd64 [installed]

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#11

Im not exactly sure what Im looking for here, Some possible reason why 2 of us are hitting the cryptsetup doesnt know what tpm2-device=auto is while you didnt. This is a fresh ubuntu 22.04 lts luks2 encrypted from the beginning. I know you method works because Ive replicated it on fedora, but something is off inside ubuntu 22.04

The versions look the same,

Here's the diff between mine and yours

for some reason my cryptsetup-initramfs says jammy,jammy,now. I dont know why it would list twice like that

chris@testbox:~$ diff mine his
1,3c1,3
< cryptsetup-bin/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed]
< cryptsetup-initramfs/jammy,jammy,now 2:2.4.3-1ubuntu1 all [installed]
< cryptsetup/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed]
---
> cryptsetup-bin/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed,automatic]
> cryptsetup-initramfs/jammy,now 2:2.4.3-1ubuntu1 all [installed,automatic]
> cryptsetup/jammy,now 2:2.4.3-1ubuntu1 amd64 [installed,automatic]
5d4
< systemd-oomd/jammy-updates,jammy-proposed,now 249.11-0ubuntu3.3 amd64 [installed,automatic]

Revision history for this message
Manfred Hampl (m-hampl) said (last edit ):
#12

Is the option 'tpm2-device' contained in /etc/fstab or in /etc/crypttab (or both)?

In any case, it is just shown as "warning" and should not do any harm.

Revision history for this message
Manfred Hampl (m-hampl) said :
#13

@Dean Huffman:
Do you have 'tpm2-device=auto' in your /etc/crypttab file?

Revision history for this message
Dean Huffman (deanhuff) said :
#14

On my target device, I have a fairly complex set of partitions to support lvm snapshots and read-only file systems when run in a production environment. This particular box hasn't been configured with either read-only or snapshots yet.

In short, the vg_system volume group is unencrypted while the vg_skyview volume group contains all the encrypted logical volumes. See output of files below:

root@testbox:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/vg_system/lv_root during curtin installation
/dev/disk/by-id/dm-uuid-LVM-tuGy77pUEcJr33VKdr3s9mXxT87VoC0QBCF5HbYd6qMJtRfCFu23P9LwJjpUe6K5 / ext4 defaults 0 1
# /maptiles was on /dev/vg_system/lv_maps during curtin installation
/dev/disk/by-id/dm-uuid-LVM-tuGy77pUEcJr33VKdr3s9mXxT87VoC0Qds5XTPA3P5P14U7gooJjLjZ7N79SBPMp /maptiles ext4 defaults 0 1
/dev/disk/by-id/dm-uuid-LVM-tuGy77pUEcJr33VKdr3s9mXxT87VoC0QEdHC515zlwbRmy1kWYr3TeBxYeeB6eOs none swap sw 0 0
# /var/log was on /dev/vg_system/lv_var_log during curtin installation
/dev/disk/by-id/dm-uuid-LVM-tuGy77pUEcJr33VKdr3s9mXxT87VoC0QGufbLLr77WCndWbpES8Hew6gDd16C8GU /var/log ext4 defaults 0 1
# /home was on /dev/vg_skyview/lv_home during curtin installation
/dev/disk/by-id/dm-uuid-LVM-HtWqk4fAntnlSnmZEMgMIfCzHOgwsBk3fN3hKQdyBgDlWX8TE4AQZLNEt1oTUdOc /home ext4 defaults 0 1
# /opt/skyview was on /dev/vg_skyview/lv_opt_skyview during curtin installation
/dev/disk/by-id/dm-uuid-LVM-HtWqk4fAntnlSnmZEMgMIfCzHOgwsBk35UCwBwt186CFUbEi4ddWkHnYkO8VsKd0 /opt/skyview ext4 defaults 0 1
# /services was on /dev/vg_skyview/lv_services during curtin installation
/dev/disk/by-id/dm-uuid-LVM-HtWqk4fAntnlSnmZEMgMIfCzHOgwsBk3v608n2M35XoFxetbQisZOt11Jytyt0ZB /services ext4 defaults 0 1
# /var/log/skyview was on /dev/vg_skyview/lv_var_log_skyview during curtin installation
/dev/disk/by-id/dm-uuid-LVM-HtWqk4fAntnlSnmZEMgMIfCzHOgwsBk3c9VjK5sG9Xt3C9hAH7MzmDBDrSvGiYCq /var/log/skyview ext4 defaults 0 1
# /upload was on /dev/vg_skyview/lv_upload during curtin installation
/dev/disk/by-id/dm-uuid-LVM-HtWqk4fAntnlSnmZEMgMIfCzHOgwsBk3D4oUWu7c8lqNxDpMnSHys07FF9hQXlJe /upload ext4 defaults 0 1
# /var/apps was on /dev/vg_system/lv_var_apps during curtin installation
/dev/disk/by-id/dm-uuid-LVM-tuGy77pUEcJr33VKdr3s9mXxT87VoC0Qgo0iM3T10gTdY2kGleiR2fWBRLABPIhQ /var/apps ext4 defaults 0 1
# /boot was on /dev/sda2 during curtin installation
/dev/disk/by-uuid/8ae09c96-a898-4760-ad1c-b3267189aec1 /boot ext4 defaults 0 1
# /boot/efi was on /dev/sda1 during curtin installation
/dev/disk/by-uuid/884C-5B54 /boot/efi vfat defaults 0 1
/swap.img none swap sw 0 0

root@testbox:~# cat /etc/crypttab
#dm_crypt-0 UUID=6e4e776f-96f2-4124-be2d-95c5bad15c0b none luks
dm_crypt-0 UUID=6e4e776f-96f2-4124-be2d-95c5bad15c0b none tpm2-device=auto
root@testbox:~# lvs
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  lv_home vg_skyview -wi-ao---- 15.00g
  lv_opt_skyview vg_skyview -wi-ao---- 1.00g
  lv_services vg_skyview -wi-ao---- 1.00g
  lv_upload vg_skyview -wi-ao---- 15.00g
  lv_var_log_skyview vg_skyview -wi-ao---- 15.00g
  lv_maps vg_system -wi-ao---- 185.00g
  lv_root vg_system -wi-ao---- 20.00g
  lv_swap vg_system -wi-ao---- 5.00g
  lv_var_apps vg_system -wi-ao---- 9.41g
  lv_var_log vg_system -wi-ao---- 10.00g

root@testbox:~# pvs
  PV VG Fmt Attr PSize PFree
  /dev/mapper/dm_crypt-0 vg_skyview lvm2 a-- <154.33g <107.33g
  /dev/sda3 vg_system lvm2 a-- <291.00g 61.58g

root@testbox:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 61.9M 1 loop /snap/core20/1328
loop1 7:1 0 61.9M 1 loop /snap/core20/1518
loop2 7:2 0 78.1M 1 loop /snap/lxd/22467
loop3 7:3 0 101.3M 1 loop /snap/lxd/23155
loop4 7:4 0 43.6M 1 loop /snap/snapd/14978
loop5 7:5 0 47M 1 loop /snap/snapd/16010
sda 8:0 0 447.1G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 750M 0 part /boot
├─sda3 8:3 0 291G 0 part
│ ├─vg_system-lv_root 253:0 0 20G 0 lvm /
│ ├─vg_system-lv_maps 253:1 0 185G 0 lvm /maptiles
│ ├─vg_system-lv_swap 253:2 0 5G 0 lvm [SWAP]
│ ├─vg_system-lv_var_log 253:3 0 10G 0 lvm /var/log
│ └─vg_system-lv_var_apps 253:4 0 9.4G 0 lvm /var/apps
└─sda4 8:4 0 154.3G 0 part
  └─dm_crypt-0 253:5 0 154.3G 0 crypt
    ├─vg_skyview-lv_home 253:6 0 15G 0 lvm /home
    ├─vg_skyview-lv_opt_skyview 253:7 0 1G 0 lvm /opt/skyview
    ├─vg_skyview-lv_services 253:8 0 1G 0 lvm /services
    ├─vg_skyview-lv_var_log_skyview 253:9 0 15G 0 lvm /var/log/skyview
    └─vg_skyview-lv_upload 253:10 0 15G 0 lvm /upload

root@testbox:~# blkid
/dev/mapper/vg_system-lv_maps: UUID="20194ce5-5987-455f-8d02-7db715446697" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg_system-lv_var_apps: UUID="796dc11b-6b19-4e34-842e-b4a717baaec6" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg_system-lv_swap: UUID="be5d046f-f83b-44bc-9beb-d1f41e625ddf" TYPE="swap"
/dev/mapper/vg_system-lv_root: UUID="1a51219a-4e33-4c2e-9eb8-be9fdc55d8f6" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sda4: UUID="6e4e776f-96f2-4124-be2d-95c5bad15c0b" TYPE="crypto_LUKS" PARTUUID="b8949375-acdb-425a-b66e-068b0ee4e7ef"
/dev/sda2: UUID="8ae09c96-a898-4760-ad1c-b3267189aec1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="de726e6b-e414-4240-95a6-8c5add68d28b"
/dev/sda3: UUID="HqoE9Y-yQ6f-HFqy-l7la-FG79-YCiW-7tfm7S" TYPE="LVM2_member" PARTUUID="9fcd7353-eddd-4873-963f-44828b33b662"
/dev/sda1: UUID="884C-5B54" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="62f333b9-855a-40a0-a9b9-12feeceb6f53"
/dev/mapper/vg_system-lv_var_log: UUID="89200282-3f81-4c37-a441-ae9607efe28e" BLOCK_SIZE="4096" TYPE="ext4"
/dev/loop1: TYPE="squashfs"
/dev/mapper/vg_skyview-lv_upload: UUID="00d2d281-7664-419b-8ac4-26bfdf73dd11" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg_skyview-lv_services: UUID="4898db92-431f-46ba-bd4c-f950b72d6028" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg_skyview-lv_home: UUID="7ece77eb-0ef0-47c4-971d-8d561f5e4800" BLOCK_SIZE="4096" TYPE="ext4"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/mapper/vg_skyview-lv_var_log_skyview: UUID="7edcca48-a7fd-4c52-bb5a-5e684f85a118" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg_skyview-lv_opt_skyview: UUID="a21a42be-39a3-472b-bd07-0bb8d2fe9ba2" BLOCK_SIZE="4096" TYPE="ext4"
/dev/loop5: TYPE="squashfs"
/dev/mapper/dm_crypt-0: UUID="wuB7gB-xZ1H-aC3X-lkOa-XVqn-9x9C-mPhdGn" TYPE="LVM2_member"
/dev/loop3: TYPE="squashfs"

Revision history for this message
Christopher Hall (christopher88hall) said :
#15

I think it's got to be something to do with the way the system is installed, a missing package or something like that. I think the cloud-init system is doing something differently than the 2204 ISO.

I did notice when we were looking at those packages earlier several of yours said installed, automatic. Where the ones that came off the iso didn't say that so I'm wondering if there's some kind of meta package that includes some other packages that might act as plugins to cryptsetup that the 2204 ISO doesn't

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#16

I wanted to test this out on ubuntu server, as that appears to be what the cloud-init stuff relates to and I am hitting the same issue

root@test:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.15.0-40-generic
cryptsetup: WARNING: dm_crypt-0: ignoring unknown option 'tpm2-device'

After additional combing through dean's output above it looks like /dev/sda4 6e4e776f-96f2-4124-be2d-95c5bad15c0b is not the root filesystem, that's about the only discrepancy I can find. That still doesnt make any sense as to why cryptsetup couldnt interpret it

I have noticed that dean's /dev/sda4 that the tpm is unlocking is not a root device, I am testing that angle to see if it works a non-root device

Revision history for this message
Manfred Hampl (m-hampl) said :
#17

I am quite sure that the message comes from /lib/cryptsetup/functions

@Christoper Hall and @Dean Huffman, can you both please report the output of

grep "ignoring unknown option" /lib/cryptsetup/functions
grep tpm2 /lib/cryptsetup/functions

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#18

This tested as working on a non-root filesystem.

So thats why its working on his box and not for the others.

 I tested it by adding another 1Gig virtual harddrive and manually partitioned it, luksformatted it, and put ext4 on it. I threw it in the crypttab file. Enrolled the keys for it in the tpm register. Update- Initramfs didnt throw any errors and the crypt container was popped open when I rebooted without manual inputs.

dns-support@test:~$ grep "ignoring unknown option" /lib/cryptsetup/functions
                   cryptsetup_message "WARNING: $CRYPTTAB_NAME: ignoring unknown option '$0'";
dns-support@test:~$ grep tpm2 /lib/cryptsetup/functions

Its not included in the functions there in that /lib/cryptsetup/functions file, but that begs the question, why does it work then, for non-root filesystems?

Revision history for this message
Christopher Hall (christopher88hall) said :
#19

I know this is very much offroading but I swapped in dracut inplace of ubuntu's native system., because I wasnt getting this issue with fedora.

 It had all kinds of errors, but it didnt complain about tpm2-device=auto. So it looks to be narrowed down to how the initramfs is built. It looking like a bug report but Im not sure where to file it

dns-support@test:~$ sudo dracut --regenerate-all --force > dracutoutput
dns-support@test:~$ grep tpm2 dracutoutput
dns-support@test:~$

Revision history for this message
Dean Huffman (deanhuff) said :
#20

@m-hampl

root@testbox:~# grep "ignoring unknown option" /lib/cryptsetup/functions
                cryptsetup_message "WARNING: $CRYPTTAB_NAME: ignoring unknown option '$o'";
root@testbox:~# grep tpm2 /lib/cryptsetup/functions
root@testbox:~#

Revision history for this message
Manfred Hampl (m-hampl) said :
#21

"why does it work then"

My interpretation of the "functions" script:
The message is just a warning.
The only effect is that the "tpm2-device=auto" option is not forwarded to the following steps (whatever they are).
Apparently the next steps don't need it anyhow.

Ideas for possible next steps (not sure whether worth trying):

- add -v (verbose) to update-initrams (attention lots of output!)
- modify /lib/cryptsetup/functions and add
         tpm2-device) ;;
somewhere between line 227 ("# and now the flags") and line 247 (a few lines above the message "ignoring unknown option")

The important question is:
Does your setup work despite the "ignoring unknown option" message?

Revision history for this message
Christopher Hall (christopher88hall) said :
#22

>Does your setup work despite the "ignoring unknown option" message?

No it does not use the tpm2 to decrypt the root filesystem. The end goal is to be able to turn the system on, have the tpm2 chip decrypt it and hit the login screen without any input. I've managed to get arch and fedora to do this so I know its possible.

>- modify /lib/cryptsetup/functions and add
         tpm2-device) ;;
> somewhere between line 227 ("# and now the flags") and line 247 (a few lines above the message "ignoring unknown option")

I actually tried this earlier, and followed the error chain. It leads to

/usr/share/initramfs-tools/hooks/cryptroot
CRYPTTAB_OPTION_tpm2-device=auto: not found

this makes me think initramfs-tools is the guity party, but maybe cryptsetup?

fedora and ubuntu both seem to be running the same version of cryptsetup buy maybe they were compiled differently?

Revision history for this message
Manfred Hampl (m-hampl) said :
#23

"this makes me think initramfs-tools is the guity party, but maybe cryptsetup?"

The script /usr/share/initramfs-tools/hooks/cryptroot is used by initramsfs-tools, but it is provided by cryptsetup

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#24

interesting, these initrd governing systems seem very different, I cant find a cryptroot at all on the fedora machine except a cryptroot-ask.sh which looks nothing like the cryptroot file on ubuntu.

So if I were to make a bug report It would go under cryptsetup or maybe just keep the original bug thread going? The original issue with systemd-cryptenroll is a solved and fixed issue. That part does it's job well. This bug is just the next one down the road towards tpm2 unlocked systems

Looks like its this package that is responsible for cryptroot
https://packages.ubuntu.com/jammy/all/cryptsetup-initramfs/filelist

Revision history for this message
Jonathan Jia (jonathanjia) said (last edit ):
#25

I've been experiencing a very similar issue to Christopher Hall.

Only for root filesystem:
- Crypsetup complains "WARNING : ... : ignoring unknown option 'tpm2-device' (as well as 'tpm2-pin') when running "update-initramfs"
- On boot, the root filesystem does not try to unlock via tpm at all; it immediately attempts to ask for password/recovery key (ie. the other unlock methods)
- Does not matter if I try tpm or tpm-with-pin; problem persists

It is very important to add that this only affects the root filesystem; I have a second drive attached to the system that works perfectly normally, unlike the errors above experienced by only the root filesystem. This means that while at boot I have the enter password/recovery key for root filesystem, I am still prompted (shortly afterwards) to enter my TPM-Pin (or auto-unlock with no prompt if just using tpm) to unlock the other drive's filesystem.

When I try attaching the root filesystem after boot, it seems to work normally with the tpm; I don't know why.

FYI: I'm trying to get "tpm-with-pin" working however the root filesystem does not want to work on boot (so Will McElderry's script only solves half the problem)

Has anyone resolved the issue yet?

(I'm on "Debian Bookworm", but posting here as Christopher seems to be experiencing an identical problem)

Revision history for this message
Christopher Hall (christopher88hall) said (last edit ):
#26

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1980018

There is another parallell bug report on this

Where it sits right now is the devs dont want to take the time to fix it because "It's not perfectly secure" despite almost none of the other options for luks unlocking also being perfectly secure, and most other distros having added support for it already. It was added to the wished for items list months ago and nothing has happened with it until you posted here.

Will's patches fix it.

Can you help with this problem?

Provide an answer of your own, or ask Christopher Hall for more information if necessary.

To post a message you must log in.