-
Notifications
You must be signed in to change notification settings - Fork 97
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
Consecutive device flashes (UKI) with FDE can start failing #2511
Comments
I apologize for the inconvenience. It seems that the issue you're experiencing with consecutive device flashes utilizing a UKI image with Secure Boot and FDE enabled is a valid concern. As a bot, I can't directly fix this issue, but I'll ensure that the problem is recognized as valid by labeling it as "triage". This means the issue is being looked into by our team. |
It also happened just now on the first flash, immediately after resetting the TPM. So it seems it is totally random when this happens. |
could be that we are hitting TPM protections? https://ubuntu.com/core/docs/troubleshooting |
I verified this; the TPM unlocks normally every time. It also only affects the |
Seems to be that the OEM partition is not discovered properly, even after locking it. I think this part is wrong:
As the oem is never found (nvme0n1p3 is persistent) so the check doesnt wait for it properly, then the mounting fails becuase its not there
So we may be missing a retry with a proper check that calls the unlock again to unlock the oem as well. In the second case, issue seems similar bu the check works in that case, as oem is not available and calling kcrypt several times dont seem to work as it only shows the persistent one:
|
I build a UKI image locally with to try to reproduce on my Asus PN64:
I created a UKI image with enki but it doesn't boot: I guess it's too big for the PN64 firmware 🤷 ? |
may be able to try with fedora which is usually smaller? |
If you uninstall the |
I guess this fix? #2566 |
The bug indeed is that sometimes the expected device LABEL is confused with the wrong partition.
When this happens, the device flash fails. I guess there's some randomization happening in the list of luks devices, sometimes causing this switchup. |
@jimmykarily Is there any update on this issue? |
Not on my side. I'll try to give it a try with Ubuntu after applying this first: #2566 hoping the image will be small enough to allow me to boot it on my HW. |
because otherwise, sometimes the encrypted partition doesn't show up as type: crypto_LUKS but as type: unknown making kcrypt skip it completely Part of kairos-io/kairos#2511 (an additional seems to be needed in kairos-agent when locking the partitions to fully fix the issue) Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
We found the issue. One PR created (kcrypt) one pending (kairos-agent). |
Great, well done!! |
because otherwise, sometimes the encrypted partition doesn't show up as type: crypto_LUKS but as type: unknown making kcrypt skip it completely Part of kairos-io/kairos#2511 (an additional seems to be needed in kairos-agent when locking the partitions to fully fix the issue) Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
Kairos version:
CPU architecture, OS, and Version:
Describe the bug
When flashing a device - with a UKI image and Secure Boot + FDE enabled - for multiple consecutive times. the process starts failing on the mounting/unmounting of LUKS devices. Typically the failure looks like this:
When retrying another flash immediately after, sometimes this problem occurs:
To Reproduce
Flash a real device multiple times with an image that performs Secure Boot & FDE
Expected behavior
Luks partitions get mounted/unmounted normally during device flash
Logs
Additional context
If I go into the BIOS and reset the TPM data, the next device flash tends to always succeed.
This might be coincidence but it has worked every time so far.
The text was updated successfully, but these errors were encountered: