[bug]: Using a temporary key seems to break automatic TPM2 unlocking

[SharkPlush]

I'm not sure if I did something very wrong or this is a bug.

I ran:

sudo sdbootutil enroll --method=tpm2 --no-measure-pcr

Then I ran this code:

issue6() {
    set -e
    # Problem: Aeon should have 'tpm2-measure-pcr=yes' set in /etc/crypttab if using normal encryption mode
    # Solution: add tpm2-measure-pcr=yes if tpm2-device=auto is set
    if grep '^aeon_root' /etc/crypttab | grep -qF 'tpm2-device=auto'; then
	    # Default Mode detected, now search for missing config
	    if ! grep '^aeon_root' /etc/crypttab | grep -qF 'tpm2-measure-pcr=yes'; then
                echo 'issue6 detected  - tpm2-measure-pcr=yes not set - correcting'
                # We find the root device.
                rootdev=/dev/$(dmsetup deps -o devname /dev/mapper/aeon_root | cut -d '(' -f2 | cut -d ')' -f1)
                # We make a temporary key because when using PCR 15 for the first time a lUKS key is needed.
                keyfile=$(mktemp /tmp/aeon-check.XXXXXXXXXX)
                # I would use the same method tik uses to create a keyfile but sdbootutil doesn't like it
                head -c 1024 /dev/urandom | base64 > "$keyfile"
                chmod 400 ${keyfile}
                cryptsetup luksAddKey --token-only --batch-mode --new-key-slot=31 ${rootdev} ${keyfile}
                sed -i '/^aeon_root/ s/$/,tpm2-measure-pcr=yes/' /etc/crypttab
                sdbootutil update-predictions PW=$(< "$keyfile") --measure-pcr
                sdbootutil mkinitrd
                # Wipe the temporary LUKS key
                systemd-cryptenroll --wipe-slot=31 ${rootdev}
                rm ${keyfile}
                echo 'issue6 corrected'
	    fi
    fi
}

The output of this code was:

+ echo 'issue6 detected  - tpm2-measure-pcr=yes not set - correcting'
issue6 detected  - tpm2-measure-pcr=yes not set - correcting
++ dmsetup deps -o devname /dev/mapper/aeon_root
++ cut -d '(' -f2
++ cut -d ')' -f1
+ rootdev=/dev/nvme0n1p2
++ mktemp /tmp/aeon-check.XXXXXXXXXX
+ keyfile=/tmp/aeon-check.83ZautLLna
+ head -c 1024 /dev/urandom
+ base64
+ chmod 400 /tmp/aeon-check.83ZautLLna
+ cryptsetup luksAddKey --token-only --batch-mode --new-key-slot=31 /dev/nvme0n1p2 /tmp/aeon-check.83ZautLLna
+ sed -i '/^aeon_root/ s/$/,tpm2-measure-pcr=yes/' /etc/crypttab
+ sdbootutil update-predictions PW=4OdVxb9yp9YnSQMZ+qwdv1NUHqen2WCiOppL2U+2y6N0pZx7iOb6QLk8XVLN93gV1r3sbjEqN9Ij rbdfz0rwu8QnaGTvjAxM9XpKCBVmW6pp6vdi0XxeofDUBjpbaRdAx3ai1UJ7GsCLr18UjonE92T3 49vqDN6wF5QDXOjEv3l0Ko6rSL9NyE3rnubvWup04FjTgGj+CKD1bvqNJpkfqVGxs24G5L/B9ZsU R+XuUCfMgk2uZ6Z+8FAvegv0qzr9JjzNIy/h1EN3wuK30+Db6y5SeaWeiQMdSvNxO+SO+bj7aKWS ONZOgB52Itfi945Q2nHgX+2Du5/MvL9cXzb46v/5chh5UQUlwiHMnPjwmskvR1hN+3sYa+Hi4Hnx vwIfpeos2cKjsCrVQ5NyR6AXGYeRQ5F7B79Yn1OCEy2EefGhKDDOwyOlpgEoVfOpa23IbS9cOu9/ Ca8MzpSzcua1q5AGsL5oLIXfhztlXGka2UBh2IqIh3vGA+1EUetw9mx90WHYMuyEdzJ1BpJQH4Kw NlfXgZUCp03hvo+5FPgbExWIohauelKnBU0r2EHMtzwoKSsBBxqpDVtDdsjItmj6yF3nyK/cV0n+ IYx3C13SizrIlH+gRr2Ewa6Nl3NHCrAKxsBtgGmi8fvyhWGiOIIQoZTIKWHOrx2qZXRKf0+iwPWg fLRi6IKTlF2+566k7msUzLtBbOvizcQ9b1dOJoix29IpaTyS3sfbfDdC8fPDMJzr3SatxTWy9NSA 2uqd0oif2ViK2IQoJfjPMvyPWHHVm5LfMH3RdaZRN93ZSNtCm2R7mxQvmTdVn0lTh0SR3e3QVGkY VEhjuE4iK87oa6N1eRfBIVeXdhV4ROv96Jr6U5XWY91+1hYUvPcFMa2kFyehx73m/nECAy3wnVSI kjyQ3LuznWHIIGBS5jITDUzxSeeTjxnKJG1VDDzQCLLg2DAc4C3J99MAb8oj8UXPG2TUzuABblto EgNzXnItOl7MmD/XZSqrNW/xoqwxSG4hNw61smhYMfmnvHeziCvqaJcWGAMcMXYSiBkOhDr2i3zK J7a1UtaGN3fSLHq/QCGUdvJYltteXfKRFsiZMOWQXka7jJcPdDFoPZaCwK7h15A514OG/eGYkqz9 w7tQID/Zpw7HPNjSuwEaT0+aGmt5MEVJbqmgNk8PcqaN0wHyOrWacUnzyfBBPM7UsuoB3YHOVTrJ l8ita4uCQAomxD8RvAkJpcO6onG/BkN7WLTUftUtXUafBqmzYcudbV16oS9dP6SOIgeCLJgtpjTh rZGBD3DwCwrXgQ483FHaHZCIpRY2M6qYQVaAtrfyj0Qel7uytC5FWy2z3HYs3uqQWiyBIFdEMw== --measure-pcr
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
NVIndex policy created
+ sdbootutil mkinitrd
dracut-install: ERROR: installing 'grub2-editenv'
dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.dkmhQZh/initramfs -a date btrfs awk grub2-editenv
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
NVIndex policy created
+ systemd-cryptenroll --wipe-slot=31 /dev/nvme0n1p2
Wiped slot 31.
+ rm /tmp/aeon-check.83ZautLLna
+ echo 'issue6 corrected'
issue6 corrected
+ exec

Everything seems fine so I reboot and I get an error on boot "The validation of PCR 15 failed".

I add "measure-pcr-validator.ignore=yes" into my kernel cmdline, boot, enter the password.

From this point on no matter what I did (update predictions, clear TPM2, re-enroll), I'd always get that error on boot.

I managed to get rid of it by running:

sudo transactional-update dup --continue --non-interactive pkg in --force --recommends patterns-glibc-hwcaps-x86_64_v3

But my system doesn't auto unlock anymore, doesn't matter how much I try re-enrolling.

[SharkPlush]

I booted into an older snapshot and it asked me for the password.

After entering the password I got the "The validation of PCR 15 failed". error again and I did the bypass in the kernel cmdline.

After booting I sudo sdbootutil update-predictions --ask-pin and it asked me for my PIN and LUKS2 password like it wants to update PCR15 also.

I rebooted into the same older snapshots and the same "The validation of PCR 15 failed" error appeared, but after entering the bypass into the kernel cmdline the system did auto unlock with a PCR15 invalid warning.

[SharkPlush]

Fixed by (I think) by booting into that same older snapshots and running:

sudo sdbootutil mkinitrd

Rebooted into the snapshot fine without the "PCR 15 Failed" error, updated from that older snapshot and booted into the latest snapshot fine to.

I'm still unsure if this is a bug or I did something bad so I'll leave this issue open for you to decid that.

[TobiPeterG]

Ah interesting, I had something similar yesterday. I noticed #333 while trying to enroll the TPM to my disk, which I had problems with because after enrolling using sdbootutil enroll --method=tpm2 and running sdbootutil update-predictions --measure-pcr directly afterwards and after rebooting the system, I saw the two boot entries, one with counting and one without (#333). I selected the one without and my system didn't auto-unlock and I got the PCR 15 warning. I ran sdbootutil update-prediction --measure-pcr after using the cmdline option to boot the system, rebooted, selected the entry without boot counting again and it didn't auto-unlock and showed the PCR 15 error. Then I worked around #333 by removing /etc/kernel/tries and wanted to report the auto-unlock issue after one final 3rd attempt and this time it worked - but now I also only had one boot entry (without counting).

Since the entry with boot counting was the one sdbootutil regenerated and the one without was the "old" one from before enrolling, could it be that this broke the complete setup (so booting into an old initrd) @aplanas ? Could something similar happen here as well @SharkPlush ? Is the expected PCR15 value stored in the initrd?

[SharkPlush]

aeon-6.17.6-1-default-247.conf  aeon-6.17.7-1-default-261+2-1.conf  aeon-6.17.7-1-default-264.conf    aeon-6.17.7-1-default-267+3.conf
aeon-6.17.6-1-default-248.conf  aeon-6.17.7-1-default-262+3.conf    aeon-6.17.7-1-default-265+3.conf  aeon-6.17.7-1-default-267.conf
aeon-6.17.7-1-default-251.conf  aeon-6.17.7-1-default-262.conf      aeon-6.17.7-1-default-265.conf    aeon-6.17.7-1-default-268.conf
aeon-6.17.7-1-default-254.conf  aeon-6.17.7-1-default-263+3.conf    aeon-6.17.7-1-default-266+3.conf  aeon-6.17.7-1-default-269.conf
aeon-6.17.7-1-default-256.conf  aeon-6.17.7-1-default-263.conf      aeon-6.17.7-1-default-266.conf    aeon-6.17.7-1-default-270.conf

I cannot remember exactly but the issue started between 262-265 then rest are just from me trying to fix the issue or a normal update.

Snapshot 267 is where I did the final update from an older snapshot to the latest update atm.

   # │ Type   │ Pre # │ Date                         │ User │   Used Space │ Cleanup │ Description             │ Userdata
─────┼────────┼───────┼──────────────────────────────┼──────┼──────────────┼─────────┼─────────────────────────┼──────────────
  0  │ single │       │                              │ root │              │         │ current                 │
247  │ single │       │ Wed 05 Nov 2025 14:07:15 EET │ root │   992.00 KiB │ number  │ Snapshot Update of #246 │ important=yes
248  │ single │       │ Thu 06 Nov 2025 16:41:57 EET │ root │ 1,008.00 KiB │ number  │ Snapshot Update of #247 │ important=yes
251  │ single │       │ Sat 08 Nov 2025 11:24:45 EET │ root │    43.48 MiB │ number  │ Snapshot Update of #250 │ important=yes
254  │ single │       │ Mon 10 Nov 2025 01:48:44 EET │ root │    21.88 MiB │ number  │ Snapshot Update of #253 │ important=yes
256  │ single │       │ Tue 11 Nov 2025 03:49:34 EET │ root │    24.47 MiB │ number  │ Snapshot Update of #255 │ important=yes
261  │ single │       │ Fri 14 Nov 2025 00:18:13 EET │ root │     4.02 MiB │ number  │ Snapshot Update of #256 │
262  │ single │       │ Fri 14 Nov 2025 00:19:34 EET │ root │   504.00 KiB │ number  │ Snapshot Update of #261 │ important=yes
263  │ single │       │ Fri 14 Nov 2025 21:34:34 EET │ root │   512.00 KiB │ number  │ Snapshot Update of #262 │ important=yes
264  │ single │       │ Fri 14 Nov 2025 21:49:20 EET │ root │   496.00 KiB │ number  │ Snapshot Update of #263 │ important=yes
265  │ single │       │ Fri 14 Nov 2025 21:52:22 EET │ root │   176.00 KiB │ number  │ Snapshot Update of #264 │ important=yes
266  │ single │       │ Fri 14 Nov 2025 22:35:11 EET │ root │   348.00 KiB │ number  │ Snapshot Update of #265 │
267  │ single │       │ Fri 14 Nov 2025 22:42:10 EET │ root │   476.80 MiB │ number  │ Snapshot Update of #238 │
268  │ single │       │ Fri 14 Nov 2025 23:38:49 EET │ root │   488.00 KiB │ number  │ Snapshot Update of #247 │ important=yes
269  │ single │       │ Sat 15 Nov 2025 02:50:10 EET │ root │   504.00 KiB │ number  │ Snapshot Update of #268 │
270* │ single │       │ Sun 16 Nov 2025 00:12:14 EET │ root │    88.44 MiB │ number  │ Snapshot Update of #269 │

I don't know if this is useful for you but better more info than less.

[aplanas]

sudo sdbootutil enroll --method=tpm2 --no-measure-pcr

Before I replicate the issue locally, did you double checked that the tpm2-measure-pcr= parameter was missing in /etc/crypttab?

            sdbootutil update-predictions PW=$(< "$keyfile") --measure-pcr

Ah this is weird, this should not work, right?

PW=$(< "$keyfile") sdbootutil update-predictions --measure-pcr

# cat test.sh 
#! /bin/bash

echo "Hi $NAME"

# chmod a+x ./test.sh 
# echo MyName > f
localhost:~ # ./test.sh NAME="$(<f)"
Hi 
localhost:~ # NAME="$(<f)" ./test.sh 
Hi MyName

• sdbootutil update-predictions PW=4OdVxb9yp9YnSQMZ+qwdv1NUHqen2WCiOppL2U+2y6N0pZx7iOb6QLk8XVLN93gV1r3sbjEqN9Ij rbdfz0rwu8QnaGTvjAxM9XpKCBVmW6pp6vdi0XxeofDUBjpbaRdAx3ai1UJ7GsCLr18UjonE92T3 49vqDN6wF5QDXOjEv3l0Ko6rSL9NyE3rnubvWup04FjTgGj+CKD1bvqNJpkfqVGxs24G5L/B9ZsU R+XuUCfMgk2uZ6Z+8FAvegv0qzr9JjzNIy/h1EN3wuK30+Db6y5SeaWeiQMdSvNxO+SO+bj7aKWS ONZOgB52Itfi945Q2nHgX+2Du5/MvL9cXzb46v/5chh5UQUlwiHMnPjwmskvR1hN+3sYa+Hi4Hnx vwIfpeos2cKjsCrVQ5NyR6AXGYeRQ5F7B79Yn1OCEy2EefGhKDDOwyOlpgEoVfOpa23IbS9cOu9/ Ca8MzpSzcua1q5AGsL5oLIXfhztlXGka2UBh2IqIh3vGA+1EUetw9mx90WHYMuyEdzJ1BpJQH4Kw NlfXgZUCp03hvo+5FPgbExWIohauelKnBU0r2EHMtzwoKSsBBxqpDVtDdsjItmj6yF3nyK/cV0n+ IYx3C13SizrIlH+gRr2Ewa6Nl3NHCrAKxsBtgGmi8fvyhWGiOIIQoZTIKWHOrx2qZXRKf0+iwPWg fLRi6IKTlF2+566k7msUzLtBbOvizcQ9b1dOJoix29IpaTyS3sfbfDdC8fPDMJzr3SatxTWy9NSA 2uqd0oif2ViK2IQoJfjPMvyPWHHVm5LfMH3RdaZRN93ZSNtCm2R7mxQvmTdVn0lTh0SR3e3QVGkY VEhjuE4iK87oa6N1eRfBIVeXdhV4ROv96Jr6U5XWY91+1hYUvPcFMa2kFyehx73m/nECAy3wnVSI kjyQ3LuznWHIIGBS5jITDUzxSeeTjxnKJG1VDDzQCLLg2DAc4C3J99MAb8oj8UXPG2TUzuABblto EgNzXnItOl7MmD/XZSqrNW/xoqwxSG4hNw61smhYMfmnvHeziCvqaJcWGAMcMXYSiBkOhDr2i3zK J7a1UtaGN3fSLHq/QCGUdvJYltteXfKRFsiZMOWQXka7jJcPdDFoPZaCwK7h15A514OG/eGYkqz9 w7tQID/Zpw7HPNjSuwEaT0+aGmt5MEVJbqmgNk8PcqaN0wHyOrWacUnzyfBBPM7UsuoB3YHOVTrJ l8ita4uCQAomxD8RvAkJpcO6onG/BkN7WLTUftUtXUafBqmzYcudbV16oS9dP6SOIgeCLJgtpjTh rZGBD3DwCwrXgQ483FHaHZCIpRY2M6qYQVaAtrfyj0Qel7uytC5FWy2z3HYs3uqQWiyBIFdEMw== --measure-pcr

Ops, seems that the PW has this --measure-pcr extra at the end. I think this was the issue.

• sdbootutil mkinitrd
  dracut-install: ERROR: installing 'grub2-editenv'
  dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.dkmhQZh/initramfs -a date btrfs awk grub2-editenv

Seems also that there is a module that requires grub2-editenv. That should not be present.

[aplanas]

I do not think that this is an issue with sdbootutil?

[SharkPlush]

Before I replicate the issue locally, did you double checked that the tpm2-measure-pcr= parameter was missing in /etc/crypttab?

I didn't check but the script should for you

if ! grep '^aeon_root' /etc/crypttab | grep -qF 'tpm2-measure-pcr=yes'; then

Seems also that there is a module that requires grub2-editenv. That should not be present.

I've always had these errors on Aeon is this not normal?

[aplanas]

I've always had these errors on Aeon is this not normal?

I do not think so. Looks like that there is a module that is requiring this grub module. We can find the name of the module with grep -R grub /usr/lib/dracut/modules.d/

[SharkPlush]

aeon@localhost:~> sudo grep -R grub /usr/lib/dracut/modules.d/
[sudo] password for : 
/usr/lib/dracut/modules.d/30firstboot/firstboot-detect.service:# In this mode, the zipl initrd uses grub2-emu to kexec the real kernel
/usr/lib/dracut/modules.d/30firstboot/firstboot-detect.service:ConditionKernelCommandLine=!initgrub
/usr/lib/dracut/modules.d/30ignition/ignition-kargs-helper.sh:grubcfg="/sysroot/etc/default/grub"
/usr/lib/dracut/modules.d/30ignition/ignition-kargs-helper.sh:orig_kernelopts="$(grep GRUB_CMDLINE_LINUX_DEFAULT "${grubcfg}")"
/usr/lib/dracut/modules.d/30ignition/ignition-kargs-helper.sh:sed -i "s|^\(GRUB_CMDLINE_LINUX_DEFAULT=\).*|\1\"$kernelopts\"|" /etc/default/grub
/usr/lib/dracut/modules.d/30ignition/ignition-kargs-helper.sh:/usr/sbin/grub2-mkconfig > /boot/grub2/grub.cfg
/usr/lib/dracut/modules.d/30ignition/ignition-kargs-helper.sh:    chroot /sysroot grub2-editenv - set health_checker_flag=0 || true
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:#   recover using grub
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:  grub2-editenv - set health_checker_flag=0
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:try_grub_recovery()
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:    try_grub_recovery
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:    try_grub_recovery
/usr/lib/dracut/modules.d/50health-checker/health-checker-emergency.sh:  try_grub_recovery
/usr/lib/dracut/modules.d/50health-checker/module-setup.sh:    inst_multiple date btrfs awk grub2-editenv
/usr/lib/dracut/modules.d/98selinux-microos/selinux-microos-relabel.sh:# In this mode, the zipl initrd uses grub2-emu to kexec the real kernel
/usr/lib/dracut/modules.d/98selinux-microos/selinux-microos-relabel.sh:if getargbool 0 'initgrub'; then

[aplanas]

@danyspin97

/usr/lib/dracut/modules.d/50health-checker/module-setup.sh:    inst_multiple date btrfs awk grub2-editenv

This is the old health-checker, right? Is there a new update without this requirement?

[SharkPlush]

I came across this and it seems to still be an issue: openSUSE/health-checker#20

This is might provide more information to this issue as the installer for Aeon will use a temporary key when enrolling the TPM2 for the first time during install: AeonDesktop/Project#27

I'm not 100% sure the linked issue is related to mine but given the context of a temporary key being used during install it might be?

I think it might be worth mentioning that tik uses keyctl for providing the key so different to my method. I also don't know if this is useful info but (I think) you can see how it's being created here if that matters: https://github.com/sysrich/tik/blob/main/usr/lib/tik/lib/tik-functions#L365

^ This temporary key will be deleted after Aeon installs and reboots. During installation a permanent key will be enrolled AFTER the TPM2 enrollment.