Created attachment 1954428 [details] Dell UEFI0073 Error Description of problem: In an environment where secure boot is enabled, it is not possible to PXE boot (without custom policies) `ironic-python-agent` to perform introspection. Users can introspect with secure boot disabled, enable secure boot (without custom policies) post introspection, and successfully provision using shipped RHEL hardened image. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Enable secure boot in BIOS 2. Start baremetal node introspection Actual results: Unable to PXE boot `ironic-python-agent` without custom secure boot policies. Expected results: `ironic-python-agent` is PXE bootable without custom secure boot policies. Additional info:
The issue here is that the iPXE efi is not signed with the Red Hat key, and even if it was the boot would need to start with a shim efi to allow the Red Hat key without intervention. Doing a grub network boot would allow end-to-end secure boot, since the boot execution order is shim -> grub -> ironic-python-agent. I have proposed this backport[1] to enable this in 17.1. Grub network boot is not as robust as grub local boot or iPXE network boot, so I don't think we can recommend this as a solution in all cases. If it works for particular scenarios it can be used. If the iPXE efi was signed with the Red Hat key that would present more options. I'll raise a bz against the ipxe package. We could then explore the following: - Customers can manually add the Red Hat key with a custom Secure Boot policy - An enhancement request to shim to boot to something other than grubx64.efi - Hackery to get shim to boot iPXE by renaming ipxe-snponly-x86_64.efi to grubx64.efi (I actually confirmed this works!) [1] https://review.opendev.org/c/openstack/puppet-ironic/+/879087
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2023:4577
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days