[Bug 1228863] New: System asking for recovery key while booting a default mode encrypted Aeon system after automatic update
https://bugzilla.suse.com/show_bug.cgi?id=1228863 Bug ID: 1228863 Summary: System asking for recovery key while booting a default mode encrypted Aeon system after automatic update Classification: openSUSE Product: openSUSE Aeon Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Transactional Update Assignee: rbrown@suse.com Reporter: happymab.dev@outlook.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- When I booted the system after the automatic update on 04 Aug 2024, the system asked for the recovery key. I booted the system using the recovery key and tried the following to fix the issue: - sudo sdbootutil update-predictions - sudo sdbootutil --ask-pin update-predictions - Clear TPM in BIOS and run sudo sdbootutil --ask-pin update-predictions None of the above actions fixed the issue. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c1 --- Comment #1 from Martin Abele <happymab.dev@outlook.com> --- Created attachment 876480 --> https://bugzilla.suse.com/attachment.cgi?id=876480&action=edit Output of "sudo sdbootutil -vv --ask-pin update-predictions" -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c2 --- Comment #2 from Martin Abele <happymab.dev@outlook.com> --- Above output is the current state of the system after clearing the TPM2 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c3 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |happymab.dev@outlook.com Flags| |needinfo?(happymab.dev@outl | |ook.com) --- Comment #3 from Richard Brown <rbrown@suse.com> --- And what is the output of the same command but without —ask-pin? Because you wiped your TPM you may have wiped the pin Maybe just -v instead of vv to make the logs a little more readable -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c4 Artur Kaufmann <arturkaufmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arturkaufmann@gmail.com --- Comment #4 from Artur Kaufmann <arturkaufmann@gmail.com> --- This is my output, after troubleshooting referred to clear TPM and then update-predictions [artur@gregory ~]$ sudo sdbootutil -v update-predictions Garbage after device path end, ignoring. Garbage after device path end, ignoring. /var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/550-firmware-code-late.pcrlock.d/generated.pcrlock written. Garbage after device path end, ignoring. Garbage after device path end, ignoring. /var/lib/pcrlock.d/250-firmware-config-early.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/550-firmware-config-late.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/600-gpt.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/630-shim-efi-application.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/640-boot-loader-efi-application.pcrlock.d/generated.pcrlock written. /var/lib/pcrlock.d/641-sdboot-loader-conf.pcrlock written. /var/lib/pcrlock.d/650-kernel-efi-application.pcrlock.d/linux-1.pcrlock written. /tmp/sdbootutil.xIRias/cmdline.pcrlock written. /var/lib/pcrlock.d/710-kernel-cmdline-boot-loader.pcrlock.d/cmdline-1.pcrlock written. /tmp/sdbootutil.xIRias/cmdline.pcrlock written. /var/lib/pcrlock.d/710-kernel-cmdline-boot-loader.pcrlock.d/cmdline-2.pcrlock written. /tmp/sdbootutil.xIRias/cmdline.pcrlock written. /var/lib/pcrlock.d/710-kernel-cmdline-boot-loader.pcrlock.d/cmdline-3.pcrlock written. Garbage after device path end, ignoring. Garbage after device path end, ignoring. Couldn't find component '350-action-efi-application' in event log. Couldn't find component '750-enter-initrd' in event log. Didn't find component '800-leave-initrd' in event log, assuming system hasn't reached it yet. Didn't find component '850-sysinit' in event log, assuming system hasn't reached it yet. Didn't find component '900-ready' in event log, assuming system hasn't reached it yet. Skipped 2 components after location '940-' (950-shutdown, 990-final). Unable to recognize 2 components in event log. Event log record 9 (PCR 6, "Raw: Dell Configuration Information 1") not matching any component. Event log record 30 (PCR 14, "Raw: MokList\000") not matching any component. PCR 0 (platform-code) matches event log and fully consists of recognized measurements. Including in set of PCRs. PCR 4 (boot-loader-code) is touched by component we can't find in event log. Removing from set of PCRs. PCR 5 (boot-loader-config) matches event log and fully consists of recognized measurements. Including in set of PCRs. PCR 7 (secure-boot-policy) matches event log and fully consists of recognized measurements. Including in set of PCRs. PCR 9 (kernel-initrd) matches event log and fully consists of recognized measurements. Including in set of PCRs. PCRs dropped from protection mask: 4 (boot-loader-code) PCRs in protection mask: 0 (platform-code), 5 (boot-loader-config), 7 (secure-boot-policy), 9 (kernel-initrd) Predicted future PCRs in 1.503ms. WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:391:Esys_StartAuthSession_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x0000018b) Failed to allocate encryption session: State not recoverable Error creating the policy! Please, provide the recovery PIN to register the new policy NVIndex policy created -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c5 --- Comment #5 from Artur Kaufmann <arturkaufmann@gmail.com> --- Created attachment 876485 --> https://bugzilla.suse.com/attachment.cgi?id=876485&action=edit sudo sdbootutil -vv update-predictions Detailed output of sdbootutil. Short output is in comment 4 https://bugzilla.opensuse.org/show_bug.cgi?id=1228863#c4 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c6 --- Comment #6 from Martin Abele <happymab.dev@outlook.com> --- Created attachment 876487 --> https://bugzilla.suse.com/attachment.cgi?id=876487&action=edit Output of "sudo sdbootutil -v update-predictions" -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c7 --- Comment #7 from Martin Abele <happymab.dev@outlook.com> --- Is it a chicken - egg problem? With ask-pin option the pin is not valid because the TPM was wiped and without the option, the system insists to provide the recovery pin... What command is used to enroll the TPM during the installation or during firstboot respectively? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c8 --- Comment #8 from Richard Brown <rbrown@suse.com> --- (In reply to Martin Abele from comment #7)
Is it a chicken - egg problem? With ask-pin option the pin is not valid because the TPM was wiped and without the option, the system insists to provide the recovery pin...
What command is used to enroll the TPM during the installation or during firstboot respectively?
I think it’s more likely your claim that you’re resetting or clearing your TPM is false/incorrect, or incomplete If you compare the logs from comments #4 and #6 you see evidence of different event log entries which should be impossible if the system is booting the same OS each time with a clear TPM Are you sure you’re clearing the TPM each time, and not booting into any other OS? (Dell maintenance/recovery tools would count as a different OS) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c10 --- Comment #10 from Martin Abele <happymab.dev@outlook.com> --- (In reply to Richard Brown from comment #8)
(In reply to Martin Abele from comment #7)
Is it a chicken - egg problem? With ask-pin option the pin is not valid because the TPM was wiped and without the option, the system insists to provide the recovery pin...
What command is used to enroll the TPM during the installation or during firstboot respectively?
I think it’s more likely your claim that you’re resetting or clearing your TPM is false/incorrect, or incomplete
If you compare the logs from comments #4 and #6 you see evidence of different event log entries which should be impossible if the system is booting the same OS each time with a clear TPM
Are you sure you’re clearing the TPM each time, and not booting into any other OS? (Dell maintenance/recovery tools would count as a different OS)
I used the "Clear TPM" function in Dell's bios. And this is now greyed out, indicating that the TPM is empty. I don't have any other OS nor recovery or diagnostic partitions anymore. It's just Aeon, nothing else. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c11 --- Comment #11 from Martin Abele <happymab.dev@outlook.com> --- Oh. now I see what you mean by contradicting logs of comment #4 and comment #6. This are indeed two different cases. It seems that Artur Kaufmann has a similar issue and posted his logs and comments also. This is indeed not the same system. My (Martin Abele) logs and comments are one case and Artur Kaufmann's logs and comments are a different case. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c21 --- Comment #21 from Martin Abele <happymab.dev@outlook.com> --- (In reply to Alberto Planas Dominguez from comment #15)
(In reply to Martin Abele from comment #0)
- sudo sdbootutil update-predictions
This should fail, as the predictions cannot be updated if the current state is invalid
- sudo sdbootutil --ask-pin update-predictions
This should work. If it didn't we need to debug this. I will try to reproduce it, but with the PIN you can rewrite the TPM policy always.
- Clear TPM in BIOS and run sudo sdbootutil --ask-pin update-predictions
This will never work. Once the TPM is clear, there is no policy, pin or anything that can be used. You need to fully re-enroll the system.
(I will update https://en.opensuse.org/Portal:MicroOS/FDE#Re-enrollment with more updated information later this week=
Hi Alberto, The re-enrollment as described in https://en.opensuse.org/Portal:MicroOS/FDE#Re-enrollment worked for me as well. My system boots without asking for a password or recovery key again. Thanks a lot for providing this description. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c22 Marc Thomas <opensuse@radok.me> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |opensuse@radok.me --- Comment #22 from Marc Thomas <opensuse@radok.me> --- While the re-enrollment was working for me with 20240807 and I could start without PIN, I got the recovery PIN again with 20240808. Initially I thought this was because I messed around with the recovery key slots to rotate my recovery key, but the update ran in the background at the same time. To make sure it's not me I did a reinstall and then did the following: Cleared TPM via: echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request Reboot Entered PIN. localhost:~ # tpm2_dictionarylockout -Tdevice:/dev/tpmrm0 --setup-parameters --max-tries=5 --clear-lockout localhost:~ # /usr/lib/systemd/systemd-pcrlock remove-policy WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:391:Esys_StartAuthSession_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x0000018b) Failed to remove NV index, assuming data out of date, removing policy file. Removed policy file '/var/lib/systemd/pcrlock.json'. Removed policy file '/boot/efi/loader/credentials/pcrlock.aeon.cred'. localhost:~ # systemd-cryptenroll --wipe=tpm2 /dev/nvme1n1p2 Wiped slot 0. localhost:~ # sdbootutil --ask-pin update-predictions Garbage after device path end, ignoring. Garbage after device path end, ignoring. Recovery PIN: Garbage after device path end, ignoring. NVIndex policy created localhost:~ # systemd-cryptenroll --tpm2-device=auto /dev/nvme1n1p2 Automatically using pcrlock policy '/var/lib/systemd/pcrlock.json'. Please enter current passphrase for disk /dev/nvme1n1p2: (press TAB for no ec••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• New TPM2 token enrolled as key slot 0. localhost:~ # systemd-cryptenroll /dev/nvme1n1p2 SLOT TYPE 0 tpm2 2 recovery After the next reboot the system still requests the PIN. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c24 --- Comment #24 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #23)
If I understand you, you mean that the system is asking again for a key. Can be the recovery PIN or any enrolled password. Right?
Correct, I was asked for the recovery PIN.
To debug this, please, do not mangle with the TPM, nor re-enroll the system. Doing this actions first will hide the read bug that we can to get rid off, and more importantly, if you system gets compromised and a key is asked to continue the boot you will find yourself giving your password to a rogue system!
Understood, I will stop doing that. Initially I thought that I did something wrong - so i tried the TPM wipe/re-enroll.
If a password is asked you need to discover what did goes wrong. The password is asked if the measurements are not the expected one, and to debug this you need to check the table from
/usr/lib/systemd/systemd-pcrlock
I see that from the PCRs you mentioned the 7 has a red X on R and C. Should I attach the output, or is this information that should stay on the system? I will not do the unenroll for now in case you need anything else from the current state. Please let me know if I can continue. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c26 --- Comment #26 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #25)
It is possible that PCR7 is ignored in your system. Do you see a component associated in PCR7 in the row that has "Sbat-<some UUID>" in the description column?
There were a total of 9 lines for PCR7, 4 had components 1 of those had SbatLevel-<uuid>
Lets try what I wrote (unenroll, enroll, reboot, and check)
If recovery key is not requested, lets wait to the next update to see if now the it is required. In than moment the first thing will be check the PCR values to understand what is broken.
I was asked for the recovery key again after running the commands below. Commands and output (I had to add the method to get it running): localhost:~ # sdbootutil unenroll --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.aGwm26/initramfs -a date btrfs awk grub2-editenv Wiped slot 0. localhost:~ # systemd-cryptenroll /dev/nvme1n1p2 SLOT TYPE 2 recovery localhost:~ # sdbootutil enroll --ask-pin --method=tpm2 Garbage after device path end, ignoring. Garbage after device path end, ignoring. Recovery PIN: Garbage after device path end, ignoring. NVIndex policy created Enrolling with TPM2 (pcrlock): /dev/nvme1n1p2 No slots to remove selected. 🔐 Please enter current passphrase for disk /dev/nvme1n1p2: ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• New TPM2 token enrolled as key slot 0. localhost:~ # systemd-cryptenroll /dev/nvme1n1p2 SLOT TYPE 0 tpm2 2 recovery /usr/lib/systemd/systemd-pcrlock: Garbage after device path end, ignoring. Couldn't find component '250-firmware-config-early' in event log. Couldn't find component '710-kernel-cmdline-boot-loader' in event log. Couldn't find component '750-enter-initrd' in event log. Didn't find component '800-leave-initrd' in event log, assuming system hasn't reached it yet. Didn't find component '850-sysinit' in event log, assuming system hasn't reached it yet. Didn't find component '900-ready' in event log, assuming system hasn't reached it yet. Skipped 2 components after location '940-' (950-shutdown, 990-final). Unable to recognize 3 components in event log. Event log record 10 (PCR 1, "Raw: \fSmbiosTable\000\001\000\000\000\000\000\000\000D\025\375\362\224\227,J\231.\345\273\317 \343\224\000@\312w\000\000\000\000") not matching any component. Event log record 37 (PCR 12, "String: initrd=\aeon\6.10.3-1-default\initrd-927abaf71095967ff2c0c66a669b8abf774c661b quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=3b7b704d-a19d-4d5c-b3d8-844c2f43d595 rootflags=subvol=@/.snapshots/3/snapshot systemd.machine_id=e0cdf1aa6e3f48d1ad509e14e955592f") not matching any component. Event log record 29 (PCR 14, "Raw: MokList\000") not matching any component. PCR 0, 2, 4, 7 and 9 all have green checkmarks in every column now. Is 10 somehow involved? That's the only one with an X in the H column and a red hash. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c28 --- Comment #28 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #27)
But this SbatLevel has an associated component? Its column was empty, right? It was: 620-secureboot-authority Authority: SbatLevel-<guid>
/usr/lib/systemd/systemd-pcrlock:
Garbage after device path end, ignoring. Couldn't find component '250-firmware-config-early' in event log. Couldn't find component '710-kernel-cmdline-boot-loader' in event log. Couldn't find component '750-enter-initrd' in event log.
Aha this last two looks the cause.
Can you see if the new initrd is generated, and the new boot entry (/boot/efi/EFI/loader/entries) is pointing to the new initrd? Can you also compare the cmdline from the boot entry with the event log? To do that check the cmdline that appears in systemd-pcrlock with the one in the boot entry.
I think I would need more help here to get you exactly what you need, as I'm just a normal user - but I'll try. The "entries" folder I found in /boot/efi/loader/entries, this folder contains 5 files. Last file is named aeon-6.10.3-1-default-5.conf and contains the following: # Boot Loader Specification type#1 entry title Aeon 20240809 version 5@6.10.3-1-default sort-key aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=3b7b704d-a19d-4d5c-b3d8-844c2f43d595 rootflags=subvol=@/.snapshots/5/snapshot systemd.machine_id=e0cdf1aa6e3f48d1ad509e14e955592f linux /aeon/6.10.3-1-default/linux-f431a68473f70f7db938d56c1a4f039aa439998e initrd /aeon/6.10.3-1-default/initrd-927abaf71095967ff2c0c66a669b8abf774c661b /usr/lib/systemd/systemd-pcrlock PCR 12 is the following: 12 kernel-config ipl ✓ <long hash> F - String: initrd=\aeon\6.10.3-1-default\initrd-927abaf71095967ff2c0c66a669b8abf774c661b <same options as in the boot loader entry> One thing I noticed: /boot/initrd -> initrd-6.10.3-1-default is currently shown in red. Is this correct?
Are you loading the last snpashot? In think so, I did not select anything before boot if you mean that. My /etc/os-release shows 20240809 as VERSION_ID. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c29 --- Comment #29 from Marc Thomas <opensuse@radok.me> --- Is there anything else I could get from the systems current state that could help? If not I would try it with tumbleweed and systemd-boot for now and reinstall Aeon if needed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c31 --- Comment #31 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #30)
Ah my bad, Marc. I got busy with other tasks. All good, did not want to be pushy - I just thought maybe I can reproduce in TW so we'd have more information if it's an Aeon only thing.
I am a bit lost with your issue, so let me retake it thinking out of loud.
A)
localhost:~ # sdbootutil unenroll --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.aGwm26/initramfs -a date btrfs awk grub2-editenv
Dracut should not complain with anything related with GRUB, as should not be installed. Can you check that this is the case? (zypper se grub2, or rpm -qa | grep grub2) zypper se grub2 shows no packages with an 'i'.
# Remove the pcrlock files rm -fr /var/lib/pcrlock.d Done.
# Take note of the active default boot entry sdbootutil list-entries --only-default localhost:~ # sdbootutil list-entries --only-default aeon-6.10.3-1-default-10.conf
# Check the contents. # Replace 6.10.3-1-default with the output from last command # Take note of the initrd name. There is a hash at the end. sdbootutil show-entry 6.10.3-1-default OK. Gave me back the expected entry with his hash: initrd /aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3
# Do the unenroll / enroll dancing. # No error message should appear when calling dracut. # This should generate a new initrd sdbootutil unenroll --method=tpm2 Dracut shows an error immediately. localhost:/var/tmp # sdbootutil unenroll --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.vhLGSX/initramfs -a date btrfs awk grub2-editenv Wiped slot 0.
I checked and the destination directory is not created. localhost:/var/tmp # ll /var/tmp/dracut.vhLGSX/initramfs ls: cannot access '/var/tmp/dracut.vhLGSX/initramfs': No such file or directory
sdbootutil enroll --ask-pin --method=tpm2 localhost:/var/tmp # sdbootutil enroll --ask-pin --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.7ZJw15/initramfs -a date btrfs awk grub2-editenv Garbage after device path end, ignoring. Garbage after device path end, ignoring. Recovery PIN: Garbage after device path end, ignoring. NVIndex policy created Enrolling with TPM2 (pcrlock): /dev/nvme0n1p2 No slots to remove selected. 🔐 Please enter current passphrase for disk /dev/nvme0n1p2: ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• New TPM2 token enrolled as key slot 0.
Same issue, but with a different folder name that also is not created. I did a reboot after this step.
# Check again the last initrd # Pbly the hash will be different. Check that the initrd is in place sdbootutil show-entry 6.10.3-1-default The hash has not changed initrd /aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3
So probably dracut can't do it's thing as the dir is missing. I could create the dir and run it again, but I don't understand what it really does so I would not mess with it. Thanks for all your help so far, really appreciate it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c33 --- Comment #33 from Marc Thomas <opensuse@radok.me> --- Created attachment 876698 --> https://bugzilla.suse.com/attachment.cgi?id=876698&action=edit Output of dracut --reproducible --force --tmpdir /var/tmp my_initrd -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c39 --- Comment #39 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #36)
(In reply to Alberto Planas Dominguez from comment #35)
You will have again /aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3 in place.
Ah, I confirmed. The initrd gets created. But in my case the recovery key is not asked.
For me it looks like this: localhost:~ # mv /boot/efi/aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3 /boot/efi/aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3.bla localhost:~ # sdbootutil unenroll --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.CE2tTo/initramfs -a date btrfs awk grub2-editenv Wiped slot 0. localhost:~ # sdbootutil enroll --ask-pin --method=tpm2 dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.0LLJ6I/initramfs -a date btrfs awk grub2-editenv Garbage after device path end, ignoring. Garbage after device path end, ignoring. sha1sum: /boot/efi/aeon/6.10.3-1-default/initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3: No such file or directory It did not recreate 3b3 but 2 new files: localhost:~ # la -alt /boot/efi/aeon/6.10.3-1-default/ total 648512 drwxr-xr-x. 2 root root 32768 Aug 14 17:09 . -rwxr-xr-x. 1 root root 59957517 Aug 14 17:09 initrd-2428b73242baf475546ea3c352a5533b5eacc893 -rwxr-xr-x. 1 root root 53319086 Aug 14 17:08 initrd-123e708017d6800bc39f2a502befaffc6fda8e3e -rwxr-xr-x. 1 root root 59957603 Aug 14 14:06 initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3.bla <removed all other files listed> Key was not asked. localhost:~ # sdbootutil show-entry 6.10.3-1-default initrd /aeon/6.10.3-1-default/initrd-2428b73242baf475546ea3c352a5533b5eacc893 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c40 --- Comment #40 from Marc Thomas <opensuse@radok.me> --- Created attachment 876707 --> https://bugzilla.suse.com/attachment.cgi?id=876707&action=edit Output of localhost:~ # /usr/lib/systemd/systemd-pcrlock >> pcrlock I added the messages shown in the shell on top. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c41 --- Comment #41 from Marc Thomas <opensuse@radok.me> --- It seems after the rename of the file the enrollment no longer works. localhost:~ # systemd-cryptenroll /dev/nvme0n1p2 No longer shows a TPM entry. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c44 --- Comment #44 from Marc Thomas <opensuse@radok.me> --- (In reply to Alberto Planas Dominguez from comment #42)
(In reply to Marc Thomas from comment #41)
It seems after the rename of the file the enrollment no longer works.
localhost:~ # systemd-cryptenroll /dev/nvme0n1p2
No longer shows a TPM entry.
What file are you referring, initrd? No new initrd is generated?
Since I did the rename of initrd-a67e4f4c8aca4aa4f1b50919c64448ccb79b13b3 I had issues enrolling the TPM again (see comment 39). It did not ask for the recovery key but created a new initrd. Also systemd-cryptenroll /dev/nvme0n1p2 did not show that the TPM was enrolled. Somehow this is now working again and the TPM could be enrolled today. Yes, secure boot is enabled: localhost:~ # mokutil --sb-state SecureBoot enabled Did another unrenroll/enroll - nothing changed. I have also attached the current pcrlock. I would like to give a reinstall a try if you don't mind. Nothing on the system is currently important - so it's quick and painless. Could it also be that the fTPM is causing these issues? Should I wipe that beforehand? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c45 --- Comment #45 from Marc Thomas <opensuse@radok.me> --- Created attachment 876783 --> https://bugzilla.suse.com/attachment.cgi?id=876783&action=edit pcrlock after another enroll. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c46 --- Comment #46 from Marc Thomas <opensuse@radok.me> --- This is now a completely different machine. I gave up running Aeon on the other one, as it was a dual boot one which is not a supported configuration. This happened on a machine where only Aeon is installed. After installing 20241030 the recovery key was requested. Running sudo sdbootutil -vvv update-predictions is not successful (see file sdbootutil_update-predictions.txt) and ends with: WARNING:esys:src/tss2-esys/api/Esys_PolicyOR.c:286:Esys_PolicyOR_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_PolicyOR.c:100:Esys_PolicyOR() Esys Finish ErrorCode (0x000001c4) Failed to add OR policy to TPM: tpm:parameter(1):value is out of range or is not correct for the context Failed to submit super PCR policy: State not recoverable Error creating the policy! Please, provide the recovery PIN to register the new policy NVIndex policy created Running sudo sdbootutil -vvv --ask-pin update-predictions is also not successful (see file sdbootutil_ask-pin_update-predictions.txt) and ends with: WARNING:esys:src/tss2-esys/api/Esys_NV_Write.c:310:Esys_NV_Write_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_NV_Write.c:110:Esys_NV_Write() Esys Finish ErrorCode (0x0000099d) Failed to write NV index: tpm:session(1):a policy check failed Failed to write to NV index: State not recoverable Error creating the policy! Provided PIN incorrect or TPM2 locked after too many retries NVIndex policy created Pin has been copy/pasted to rule out typos. I have rebooted the machine before the re-enroll to make sure it still does not work. The only way to fix this for me was a re-enroll of the TPM via the guide. After these steps the machine boots normally without asking for the recovery. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c47 --- Comment #47 from Marc Thomas <opensuse@radok.me> --- Created attachment 878342 --> https://bugzilla.suse.com/attachment.cgi?id=878342&action=edit sdbootutil -vvv update-predictions after update to 20241030 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c48 --- Comment #48 from Marc Thomas <opensuse@radok.me> --- Created attachment 878343 --> https://bugzilla.suse.com/attachment.cgi?id=878343&action=edit sdbootutil -vvv --ask-pin update-predictions after update to 20241030 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 Alberto Fabbri <solo.albif@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |solo.albif@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c50 --- Comment #50 from Marc Thomas <opensuse@radok.me> ---
The only way to fix this for me was a re-enroll of the TPM via the guide. After these steps the machine boots normally without asking for the recovery.
I understand then that we cannot reproduce the PolicyOR error message now?
Currently not, anything I should run next time? If so, I would also forward this to the Telegram channel as I was not the only one with the issue. Maybe someone there still has it and can chime in. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c59 --- Comment #59 from Artur Kaufmann <arturkaufmann@gmail.com> --- (In reply to Alberto Planas Dominguez from comment #58)
(In reply to Artur Kaufmann from comment #57)
Created attachment 878444 [details]
Attached you can find all actions, as update-predictions failed and the TPM stays locked.
Thanks a lot. As I see the re-enrollment worked. I understand that now the system boot without asking the password?
Yes, it worked now again properly.
What is more interesting is now 2 entries where selected and no PolicyOR error was present.
My working theory now is that there are TPM2s with different limits of PolicyOR branches. Some are 8, other 4, and yours seem to be 2.
BR
Maybe the revision of the TPM2.0 chip is also important
sudo tpm2_getcap properties-fixed | grep TPM2_PT_REVISION -A2 TPM2_PT_REVISION: raw: 0x8A value: 1.38
BR -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c61 Guillermo Perez <guillermopf10@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guillermopf10@gmail.com --- Comment #61 from Guillermo Perez <guillermopf10@gmail.com> --- Got the same problem, booting after update always prompts for recovery key. Previously, the machine always booted in default mode without any problems. Aeon is installed on a SSD and there aren't any other disks with boot partitions, I have a HDD formatted in NTFS from an old windows installation but it was always used as mass storage and got no traces of any OS installation on it. There wasn't any recent hardware nor UEFI changes. Tried the following solutions: 1) reverting to various snapshots, without any luck 2) Running # sdbootutil --ask-pin update-predictions 3)Following the instructions on comment 56, which got me the following results: Ran # rm -fr /var/lib/pcrlock.d . File gets removed. Tried to update and got the following error: ~> sdbootutil -v --ask-pin update-predictions Error: Can't determine root subvolume After that, tried # systemd-cryptenroll to see if the PC could boot in default mode and got: No device specified, defaulting to '/dev/nvme0n1p2'. SLOT TYPE 1 tpm2 2 recovery But the fact that can't determine root subvolume and there's not a device, I'm afraid after rebooting, instead of getting the recovery key prompt, I simply will be unable to boot. So, as a summary: * I'm getting asked for a recovery key after an update. * None of the provided solutions ITT seems to work, and * I may have made it worse and I don't know why. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228863 https://bugzilla.suse.com/show_bug.cgi?id=1228863#c65 --- Comment #65 from Guillermo Perez <guillermopf10@gmail.com> --- (In reply to Alberto Planas Dominguez from comment #64)
(In reply to Guillermo Perez from comment #63)
(In reply to Alberto Planas Dominguez from comment #62)
(In reply to Guillermo Perez from comment #61)
~> sdbootutil -v --ask-pin update-predictions Error: Can't determine root subvolume
Do you have a default snapshot?
sudo snapper ls
This should show a list of snapshots, and one of the should be marked with "*". If this is not the case, somehow you system lacks of default subvolume.
No, I've got only the one reverted (marked with a - and the last one, marked with +) No default snapshots.
This is the main issue in your system. sdbootutil (actually snapper) cannot find the default snapshot, because you do no have one. You can mark a new one with btrfs or snapper (snapper modify --default). Your issue is not really related with sdbootutil afaict
Yes, that was I thought and made a new default by rolling back (forward tbh) and it worked. running again the sdbootutil command got a different error then, about the new state and the old being the same and therefore not committing the changes. I don't know exactly because at this point I almost immediately reboot to see if the prompt for recovery key disappeared. Which didn't. After all of that I threw the towel and reinstalled the system. Partially unrelated, but it would be nice if, for some next uodate, the echo for the recovery key wouldn't be obscured, it's pretty frustrating to enter that string and not being able to see any typos. Anyway, thank you very much for your help, i really appreciate it. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com