Bug 1030612

Summary: rhts_post snippet doesn't preserve full existing EFI boot order
Product: [Retired] Beaker Reporter: Bill Peck <bpeck>
Component: schedulerAssignee: Dan Callaghan <dcallagh>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 0.14CC: aigao, alemay, asaha, bpeck, ctatman, dcallagh, dcantrell, gbeshers, gbeshers, jburke, jdonohue, lkardos, llim, loriann, lszubowi, pholica, prarit, qwan, randerso, rja, rmancy, tee, xjia
Target Milestone: 0.14.4Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 889509 Environment:
Last Closed: 2013-12-19 05:09:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 889509    
Bug Blocks:    

Comment 2 Nick Coghlan 2013-11-15 07:58:17 UTC
The Beaker rhts_post snippet aims to ensure systems are always reverted to using network boot by default (allowing Beaker to reprovision them), without altering which mechanism will be used for the *next* boot operation. Currently, this relies on the command:

  BOOT=$(/usr/sbin/efibootmgr -v | grep BootOrder | awk '{print $2}' | awk -F, '{print $1}')

This only reports the *first* element in the boot order, rather than the entire current boot order.

Unfortunately, this causes problems with some UEFI firmware that will *add* boot entries for all possibilities not listed in the boot order, even if such entries already exist. If such systems are reprovisioned many times, then the number of duplicated boot entries may grow to the point where the system's firmware can no longer handle it.

While that's a firmware bug, it's prevalence (and the fact that efibootmgr doesn't include an implicit workaround) means that Beaker *must* ensure the entire boot order is preserved - it can't rely on the firmware and/or efibootmgr filling in the missing entries. That means the extraction of the next boot setting and the extraction of the current boot order need to be separated in the rhts_post snippet:

=======================
# If efibootmgr exists then re-order boot options
if [ -x '/usr/sbin/efibootmgr' ]; then
    BOOT=$(/usr/sbin/efibootmgr -v | grep BootOrder | awk '{print $2}')
    PXE_SLOT=$(/usr/sbin/efibootmgr -v | grep -i BootCurrent | awk '{print $2}')
    # This will put the boot order back to what it was before the install.
    # When first setting up a system make sure you put the netboot entry first.
    if [ ! -z $PXE_SLOT ]; then
       # Remove PXE entry from the boot order and add it to the front
       NEWBOOT=$(echo $BOOT| sed -e 's/$PXE_SLOT,//')
       NEWBOOT=$(echo $NEWBOOT| sed -e 's/,$PXE_SLOT,//')
       NEWBOOT=$(echo $NEWBOOT| sed -e 's/,$PXE_SLOT//')
       /usr/sbin/efibootmgr -o $PXE_SLOT,$NEWBOOT
       # Ensure next boot still uses previous head of the boot order
       NEXTBOOT=$(awk -F, '{print $1}' $BOOT)
       /usr/sbin/efibootmgr -n $NEXTBOOT
    fi
fi
=======================

Comment 4 Dan Callaghan 2013-11-21 05:42:18 UTC
This will be fixed with the patch for bug 1031876.

http://gerrit.beaker-project.org/2519