Browse Source
Some firmware seems to take an objection with EFI nvram entries being deleted after one is added, resulting in the entire entry table being reset to the last known good state. This is problematic, as ultimately deployments can time out if we previously booted with Networking, and the machine, while commanded to do other wise, reboots back to networking regardless. We will now delete entries first, before proceeding. Additionally, for general use, this pattern may serve the community better by avoiding cases where we would have previously just relied upon efibootmgr[0] to warn us of duplicate entries. [0]:changes/17/817017/1103aa22ece/src/efibootmgr.c (L228)
Change-Id: Ib61a7100a059e79a8b0901fd8f46b9bc41d657dc Story: 2009649 Task: 43808 (cherry picked from commit67eddfa7e3
) (cherry picked from commit33b39705a5
) (cherry picked from commit8fca145739
)
3 changed files with 51 additions and 24 deletions
@ -0,0 +1,6 @@
|
||||
--- |
||||
fixes: |
||||
- | |
||||
Fixes cases where duplicates may not be found in the UEFI |
||||
firmware NVRAM boot entry table by explicitly looking for, and deleting |
||||
for matching labels in advance of creating the EFI boot loader entry. |
Loading…
Reference in new issue