RHEL 10: bootupd update firmware #5761
Conversation
|
/kickstart-test --kstest-pr 1260 rpm-ostree-container-bootc |
|
Let's enable this test for RHEL when this will be ready for merge: |
|
This PR is stale because it has been open 60 days with no activity. |
|
This PR was closed because it has been stalled for 30 days with no activity. |
This is required to write an entry to the EFI boot manager, which we ought to do (anaconda does it when installing the bootloader itself). Without this, boot of the installed system will only work if it's configured to try and boot from the hard disk using the fallback path. Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit 0b2fc13) Resolves: RHEL-40896
If leavebootorder was specified through kickstart or kernel boot arguments we won't pass `--update-firmware` to bootupdctl. That will avoid creation of the UEFI entry for the bootloader and give people possibility for additional tweaking or debugging. This was requested by bootloader developers. Suggested-by: Timothée Ravier <tim@siosm.fr> (cherry picked from commit 28d1aed) Resolves: RHEL-40896
jkonecny12
force-pushed
the
rhel-10-bootupd-update-firmware
branch
from
564a832
to
c4c7fe2
Compare
|
When I'm testing this change on CentOS Stream 10 on Kickstart test, I'm getting this issue: |
|
Hi @cgwalters, could you please take a look if you have any idea what could be cause of this? Is it a bug in bootupd or maybe I'm doing something wrong? |
|
"Access Denied" - is this possibly a generic secure boot issue where the firmware isn't trusting the centos signing key? |
|
Hmm, could be. I honestly have issues to run official CentOS ISO on EUFI VM when using virt-manager but it works when running virt-install. May be a secure boot configuration? |
|
I wonder, @cgwalters should the secure boot feature work on CentOS Stream 10? |
Enable installation of the EFI entry from the bootupd project.
Backport of the #5508.
Resolves: RHEL-40896