-
Bug
-
Resolution: Done-Errata
-
Major
-
6.12.3
-
0
-
False
-
-
False
-
ON_QA
-
Release Notes
-
2,050
-
Added link to the RN text of SAT-23052
-
Bug Fix
-
Rejected
-
Rocket
-
-
-
Pass
-
Important
-
Automated
-
None
Description of problem:
After submitting a UEFI-based PXE build in VMware vCenter 7 environment,
- System will boot up in the network
- Complete the PXE boot and system build
- Proceed with a final reboot
- Then it will boot up again and will boot from EFI Network
- Whether I select "Chainload Grub2 EFI from ESP" or "Chainload into BIOS bootloader on first disk" or "Chainload into BIOS bootloader on second disk", none of them can boot me in the OS.
- "Chainload Grub2 EFI from ESP" will leave in online for 2 mins and then simply halt the system.
I don't know what it is but I feel like the issue started since https://bugzilla.redhat.com/show_bug.cgi?id=2112436 and https://github.com/theforeman/foreman/pull/9123 .
It may not be an issue with satellite\foreman but I think it's more of an issue with VMware 7 somehow.
Version-Release number of selected component (if applicable):
Red Hat Satellite 6.11\6.12\6.13
VMware vSphere 7
How reproducible:
100%
Steps to Reproduce:
1. Setup a Satellite 6.11\6.12\6.13 for PXE Booting and building RHEL 7.9 or 9.1 clients
2. Create a VMware Compute Resource and Profile ( set it up for UEFI ).
3. create a host entry using the same along with a host parameter
Name: efi_bootentry
Type: String
Value: Red Hat Enterprise Linux
And submit the host for build
4. Monitor the progress
Actual results:
- System will boot up in the network
- Complete the PXE boot and system build
- Console will show that efibootmgr is reconfiguring the boot order.
- Proceed with a final reboot
- Then it will boot up again and will boot from EFI Network
- Whether I select "Chainload Grub2 EFI from ESP" or "Chainload into BIOS bootloader on first disk" or "Chainload into BIOS bootloader on second disk", none of them can boot me in the OS.
- "Chainload Grub2 EFI from ESP" will leave in online for 2 mins and then simply halt the system.
Even if I don't use the efi_bootentry host param still the situation remains the same.
Expected results:
No such issues and after reboot,
- That VM should honor the boot priority set by UEFI boot Manager ( efibootmgr ) and boot from the correct device
- Even if it boots from Network, It should be able to chainload the OS from HDD correctly.
Additional info:
It's like UEFI Boot Manager settings are completely ignored by BIOS and it's honoring the very initial Boot
When we deploy the system using compute profile, there the default boot order is Network,HDD. And it seems The VM always honors that even if we modify the boot order to be HDD,Network via efibootmgr
Workaround:
1. Go to BIOS of the system after the final reboot and disable the network device in boot order.
2. As ^^ would not be acceptable by anyone, So one hack to fix this issue would be to set HDD,Network as the boot device priority in Compute profile and then use it to build the VM.
More details about the investigation will be posted below.
- external trackers
- links to
-
RHBA-2024:140284 Important: Satellite 6.16.0 release