Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uki: TPM is not able to unlock after kairos-agent upgrade #2579

Closed
nianyush opened this issue May 22, 2024 · 13 comments
Closed

Uki: TPM is not able to unlock after kairos-agent upgrade #2579

nianyush opened this issue May 22, 2024 · 13 comments
Labels
bug Something isn't working triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed

Comments

@nianyush
Copy link

nianyush commented May 22, 2024

have tried both ubuntu 24.04 and fedora, same result. kairos version 3.0.11

Installation is successfult but after upgrading the image, its not able to boot correctly after reboot. Only a login prompt is shown but not able to login with username and password. However, after a hard reboot(2nd reboot after kairos upgrade), TPM is able to correctly unlock the partition and everything seems to start to work.

image

@nianyush nianyush added bug Something isn't working triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed labels May 22, 2024
@nianyush
Copy link
Author

@3pings

@ci-robbot
Copy link
Collaborator

Hello nianyush, thank you for reporting this issue. I am a bot, an experiment of @mudler and @jimmykarily, here to help with the triage and auditing of Github issues.

Based on the description provided, it seems like you have encountered a bug related to TPM unlocking after a kairos-agent upgrade. To help us better understand the issue, please make sure to provide the following information:

  1. A detailed description of the issue.
  2. Steps to reproduce (if it's a bug).
  3. Mention the versions of the relevant artifacts being used.

For example, you could provide more information about the versions of kairos, kairos-agent, and any other relevant software being used. This will help our team in identifying any potential compatibility issues and reproduce the bug.

Once you have provided the required information, we will be able to label the issue appropriately and address it accordingly.

Thank you for your contribution to the kairos project, and please feel free to reach out if you have any further questions or concerns. Remember, I am a bot, but I am here to assist with the auditing process.

@nianyush
Copy link
Author

One thing to note is that this hw is having a quite low efi size limit(<400M)

@jimmykarily
Copy link
Contributor

It's the same issue discussed here: #2429

@jimmykarily
Copy link
Contributor

It's the same issue discussed here: #2429

or not, I'm not sure. In my case, PCR 11 value also changed (and machine-id as well) which I can't explain but does explain why unlocking fails in my case.

@nianyush
Copy link
Author

nianyush commented May 22, 2024

yes i dont get why #2429 woudl be relevant in this case. If PCR 11 value changed, then 2nd reboot should not work at all? It looks to me that some state is being carried over while doing a soft reboot @jimmykarily

@Itxaka
Copy link
Member

Itxaka commented May 22, 2024

Could easily be a tpm issue as well...if it only happens in this hardware :(

@nianyush
Copy link
Author

Reset also failed on this hw because our provider was throwing out some npe error
image

@nianyush
Copy link
Author

nianyush commented May 22, 2024

It seems like our provider is trying to write sys logs to these locations. Maybe because tpm is not unlocked, these location were not getting mounted? If this is the case, i would expect kairos to throw some error and not entering into recovery mode
logPaths := []string{"/dev/log", "/var/run/syslog", "/var/run/log"}

@Itxaka
Copy link
Member

Itxaka commented May 22, 2024

/var/run should be either symlinked to /run or a special FS, same with /dev so they should be there since boot I think, maybe the /var/run/log dir is not there?

@mudler
Copy link
Member

mudler commented May 22, 2024

Might be related to systemd/systemd#30728 systemd/systemd#30971

@mudler
Copy link
Member

mudler commented May 22, 2024

this ended up being caused by measurement mismatch when fast reboot option is enabled in the BIOS. The solution was to disable Fast reboots.

Reference key pointers in : Dasharo/dasharo-issues#415 (comment)

@mudler
Copy link
Member

mudler commented May 22, 2024

Closing this as there are no actionable items as for now. Please re-open the issue @nianyush @3pings if anything else is needed from our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed
Projects
Archived in project
Development

No branches or pull requests

5 participants