Closed fionera closed 11 months ago
Sadly this is not the case for Slot B where even after multiple attempts and reboots the entries are not available
Slot B had a bug (will be fixed with https://review.monogon.dev/c/monogon/+/2031) and Dell deleted bootentries when they arent in the boot order. That is probably the reason why debugging was that flaky.
Closing for now as we migrated away from bootentries for A/B: https://github.com/monogon-dev/monogon/issues/263
This is a tracker issue to find out what the EFI firmware of
(Dell|.+)?
Servers have against us. TL;DR:Speculation: Dell seems to scan all ESP partitions for a cache file and adds entries that are stored there back to efivars.
This is my debugging story on a Dell PowerEdge R6515:
Running in alpine based recovery environment
Validate current efi config
run binary to execute metropolis update routine for adding boot entries
validate result
reboot again into recovery
boot entries are sorted differently and are missing
Metropolis Slot B
@lorenz suspects the firmware setting "UEFI Variable Access" is set to protected, which is sadly not the case.
We arent writing the PartitionStartBlock and PartitionSizeBlocks inside the EFI entries as they are optional. Turns out that the firmware is adding that ?!? (This is speculation as there is too much weird behaviour).
After this happend, it was impossible to delete entries either with
efibootmgr
or the firmware configuration screen.After deleting the ESP partition that on sda (from the default ubuntu installation), it was possible to delete their boot entries. See speculation under TLDR.
It was also tested if adding PartitionStartBlock and PartitionSizeBlocks to the entries will make them survive but no change in behavior was found.
@fionera remembers there is some Dell folder in our ESP which apparently is used by Dell to cache things? Deleting this doesnt help