|
Bugzilla – Full Text Bug Listing |
| Summary: | Still required to enter recovery key after running update-predictions | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Aeon | Reporter: | Tim Kwakman <tim> |
| Component: | Base | Assignee: | Richard Brown <rbrown> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Tim Kwakman
2024-07-29 11:24:20 UTC
My system: MB: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX CPU: AMD Ryzen™ 5 5600X × 12 GPU: AMD Radeon™ Pro WX 3200 Series Log 1 shows your TPM was hardware locked at the point of recording that log "Provided PIN incorrect or TPM2 locked after too many retries" The correct solution to resolving that issue is recorded here: https://en.opensuse.org/Portal:Aeon/Troubleshooting#%22Provided_PIN_Incorrect_or_TPM2_locked_after_too_many_retries%22 There isn't a timestamp between Logs #1 and #2, but it's possible your workaround only worked because sufficient time passed between Log #1 to allow any re-enrollment to work Because, if the TPM was still locked, your workaround of wiping slot should have been blocked also. (Or..it might have been blocked.. I think your removing the /var/lib/systemd/pcrlock.json did nothing besides spend time that might have helped) Therefore there's no evidence of an actual bug here, just an incorrect reaction to your hardwares warning in Log #1 resulting in a satisfactory conclusion after time or persistence. (In reply to Richard Brown from comment #2) > Log 1 shows your TPM was hardware locked at the point of recording that log > > "Provided PIN incorrect or TPM2 locked after too many retries" > > The correct solution to resolving that issue is recorded here: > > https://en.opensuse.org/Portal:Aeon/ > Troubleshooting#%22Provided_PIN_Incorrect_or_TPM2_locked_after_too_many_retri > es%22 > > There isn't a timestamp between Logs #1 and #2, but it's possible your > workaround only worked because sufficient time passed between Log #1 to > allow any re-enrollment to work > > Because, if the TPM was still locked, your workaround of wiping slot should > have been blocked also. (Or..it might have been blocked.. I think your > removing the /var/lib/systemd/pcrlock.json did nothing besides spend time > that might have helped) > > Therefore there's no evidence of an actual bug here, just an incorrect > reaction to your hardwares warning in Log #1 resulting in a satisfactory > conclusion after time or persistence. Creation of log #1: 29 July 2024 12∶36∶18 Creation of log #2: 29 July 2024 13∶03∶19 I did run "Clear TPM" from the bios settings, it did not resolve the issue. Yesterday I tried things for hours - The update-predictions command always returned the error, the wipe-slot command always worked if I remember correctly. What can I check to confirm if this is a bug or just lucky timing? (In reply to Tim Kwakman from comment #3) > > Creation of log #1: 29 July 2024 12∶36∶18 > Creation of log #2: 29 July 2024 13∶03∶19 > > I did run "Clear TPM" from the bios settings, it did not resolve the issue. > Yesterday I tried things for hours - The update-predictions command always > returned the error, the wipe-slot command always worked if I remember > correctly. > > What can I check to confirm if this is a bug or just lucky timing? I don't know. that would have to be a function of your systems hardware TPM. It's your hardware which locked everything and there's no log shown so far that shows any problem with Aeon writing to an unlocked TPM but failing Considering this bug as a duplicate of 1228416 and that's likely to have been the root cause.. though it's hard to say for sure without a better understanding of the systems own TPM logs *** This bug has been marked as a duplicate of bug 1228416 *** |