Description of problem: The SYSLINUX PXE menu managed by pxemenu.py will timeout and boot to the next boot option if nothing is selected. https://git.beaker-project.org/cgit/beaker/tree/LabController/src/bkr/labcontroller/pxemenu.py#n112 The UEFI efidefault menu currently doesn't have this option and, instead, sits at the GRUB menu. This request would be to add the following to the top of efidefault menu default=0 timeout=60 title Boot using next entry in UEFI Boot Order quit Version-Release number of selected component (if applicable): All How reproducible: Every time Steps to Reproduce: 1. Boot UEFI system set to use grub efi bootloader that doesn't have job scheduled 2. Arrive at GRUB menu / list of distros Actual results: efidefault menu sits waiting for human interaction Desired results: Eventual timeout and proceed to next boot option like with legacy PXE/BIOS systems
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1207376
Does this actually work with the GRUB 0.97 version we are currently using for x86 EFI? Bug 1207376 talks about exiting to firmware but that's in GRUB2. If GRUB 0.97 doesn't support this properly (and I suspect it doesn't, but we can test it) then this would be predicated on switching to GRUB2 for x86 EFI, which is also part of bug 1087090.
We have an EFI system that takes over 45 minutes to reboot and this bug is casuing some serious grief. If we accidentally do a reboot instead of rhts-reboot we need to catch the POST at the right time and hit escape to skip the netboot.
We might be able to fix this issue by working on Bug 1087090 which is already one of the top priority items.
(In reply to Dan Callaghan from comment #3) > Does this actually work with the GRUB 0.97 version we are currently using > for x86 EFI? Bug 1207376 talks about exiting to firmware but that's in GRUB2. > > If GRUB 0.97 doesn't support this properly (and I suspect it doesn't, but we > can test it) then this would be predicated on switching to GRUB2 for x86 > EFI, which is also part of bug 1087090. Your are right, GRUB 0.97 does not support this as the firmware does not fallback booting from hard disk when quitting from the menu list. To fix this problem, we will switch to GRUB2 for x86 EFI systems when the bug fix for bug 1087090 is released.
(In reply to matt jia from comment #6) So to be 100% clear, Matt you tried making efidefault like this as per David's suggestion: default=0 timeout=60 title Boot using next entry in UEFI Boot Order quit and when you let GRUB 0.97 boot that default config, and wait 60 seconds for the timeout, you see what happen exactly? And this is on our HP Z420 test system right? (Also David has suggested "quit" but we are using "exit" elsewhere, not sure if they are just aliases for the same GRUB command or if there is some difference between them? Can you confirm, Matt?)
(In reply to Dan Callaghan from comment #7) > (In reply to matt jia from comment #6) > > So to be 100% clear, Matt you tried making efidefault like this as per > David's suggestion: > > default=0 > timeout=60 > title Boot using next entry in UEFI Boot Order > quit > > and when you let GRUB 0.97 boot that default config, and wait 60 seconds for > the timeout, you see what happen exactly? And this is on our HP Z420 test > system right? IYes, I was using my HP420 test system. When it was timeout, it loaded into a place where you can configure system, set boot options etc. I can show you if you want to have a look. > > (Also David has suggested "quit" but we are using "exit" elsewhere, not sure > if they are just aliases for the same GRUB command or if there is some > difference between them? Can you confirm, Matt?) The legacy GRUB is using "quit" https://www.gnu.org/software/grub/manual/legacy/grub.html#quit. I cannot find "exit" command from GRUB2 official documentation. It has been mentioned in here http://members.iinet.net/~herman546/p20/GRUB2%20CLI%20Mode%20Commands.html#exit
Okay, so based on our testing this is CANTFIX for GRUB 0.97 ("efigrub") because quitting from GRUB doesn't actually boot the next entry, it returns to the firmware instead. The solution is to switch the systems to boot GRUB2 instead, which is now a tested and documented configuration as per bug 1087090.