Description of problem: UEFI hosts, once provisioned are unable to pass the EFI loader screen (pxegrub2_chainload template), since the default entry tries to load Grub from (hd0,0). However, satellite provisioning created a different partitioning layout, creating the EFI partition on (hd0,gpt2). - there's anothere menu entry, which dynamically searches all thee partitions for a presence of BOOTX64.EFI file and use the found partition as the EFI one - this option works. - perhaps changing the 'default' menu entry to this one could fix the issue, howver i can't even see any "default" flag for any of the menuentries for the pxegrub2_chainload template, so i have no idea why the (hd0,0) is higlighted and used as default (it's not even listed first in the list) Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. i used libvirt with ovmf to create a UEFI-based domain 2. i tried both - discovery and a standard bare-metal provisioning to install RHEL7 on the host 3. provisioning went smooth, but when the build is done, the pxe template switches to the pxegrub2_chainload one, which should make the host to boot from the local disk 4. getting the error about not finding the bootloader fw at hd0,0
so this is all caused by the the "PXEGrub2 default local boot" template together with "Default PXE local template entry" global setting. the template's menu entry items are tagged by ids and the grub's "set default" command is configured to inherit this value. since the value is by default "local_chain_hd0", grub automatically highlights that option and tries to boot it - however, this is for bios only. for uefi systems, we would need to use the menu entry added by "pxegrub2_chainload" snippet template which id = "local". if i change the global setting to "local", it works...however all other new BIOS (PXELinux)-based hosts will use this as well, which results in booting: LABEL local MENU LABEL Default local boot MENU DEFAULT LOCALBOOT 0 - which does not work. Perhaps if we came to some universal label and use it for ids for both PXELinux and Grub2 local templates, that would be better.
Lzap: any insights about this one?
In EFI there is no way of chainbooting from MBR just like in BIOS, so these options are meant only for BIOS systems.
Reopening, I did not understand correctly the issue. This is a GA blocker.
Upstream bug assigned to lzap
snap 23, not 63
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, 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/RHSA-2018:2927