UEFI boot order, Re: Tip: Remote FAI install

Steffen Grunewald steffen.grunewald at aei.mpg.de
Fri Dec 24 10:35:50 CET 2021


Seasons greeting to everyone,

there's something that didn't let me rest since I discovered it.
A while back I had suggested to restore the UEFI BootOrder that was in effect
before GRUB-EFI was installed:

On Fri, 2021-09-17 at 11:24:52 +0200, Thomas Lange wrote:
> >>>>> On Fri, 17 Sep 2021 11:06:30 +0200, Steffen Grunewald <steffen.grunewald at aei.mpg.de> said:
> 
>     > That would either involve additions to GRUB_EFI/10-setup itself, or two
>     > extra scripts 09-x and 11-x which would have to communicate e.g. via
>     > ${LOGDIR}/bootorder ...
>     > I can imagine using an extra class, e.g. RESTORE_UEFI_ORDER, to make this
>     > optional (but I can't see the drawbacks of doing it by default).
> 
> Hi Steffen,
> 
> I also had this problem with my UEFI machines. Currently I delete the
> first boot entry manually, which is "boot Debian from disk".

When? Not while the system is to be running, and to be rebooted into the
installed system instead of FAI... it would require to move the HD boot
entry more to the end of the BootOrder list instead.

> I was thinking of a small shell script that moves the network boot
> entry in the UEFI BootOrder to the first place, without deleting the
> "boot Debian from disk" entry. I had not time to implement it yet.

That's the important difference to my suggested approach - which has the
pitfall that it requires an active "boot from HD" entry before FAI is run.
For empty disks, this obvioulsy isn't the case (the UEFI BIOS seems to 
look for EFI partitions, and if there is none, only PXE and EFI Shell
entries can be found, no matter what is set in the BIOS boot order -
this the old boot order would not be suitable).

> But maybe just restoring the original boot order is also a good
> solution.

It's not, for the reason outlined above - if the system hasn't been EFI
installed before, that is.

I've written a script to change the BootOrder on the system already running
now; this leaves some minimal risk of the system not booting (which would
require a manual pass through BIOS to put PXE on top again), but I'm
planning to add it to scripts/GRUB_EFI.
The (bash) code still needs some cleanup (and perhaps it could be made more
efficient by using Perl and internal variable storage), but the basic idea
is to
- check for availability of UEFI (/sys) and EFI boot manager
- loop over a predefined order of "PXE HD OTHER SHELL" (which, I suppose, would
   fit a FAI-ready setup most)
  - find lines matching "^Boot[0-9A-F][0-9A-F][0-9A-F][0-9A-F]\*" in "efibootmgr"
   output (only use active entries?)
  - extract the four digit hex code, and determine the type from the full string
  - output the code if type matches the outer loop item
- pipe through xargs | tr " " "," to get a proper comma-separated list
- use "efibootmgr -o"

Caveat: if for some reason PXE on NIC1 (0007 here) is prioritized over NIC0 (0006)
this order would be reversed! (More pitfalls are imaginable. Not all network
interfaces are identified by their order number, I've seen MAC addresses only...)

Also a fixed BootOrder (defined as an environment variable, or via a file) does
NOT work! Different (but same-type, same-batch) machines, for unknown reasons,
may present different initial numbers for the UEFI entries!

> I hope we get more feedback on what should be the default behaviour
> in FAI.

If there was a way to stop GRUB from modifying the BootOrder we might know whether
that actually would be sufficient (if the BIOS order would be kept as-is).

Best,
 Steffen


-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany
~~~
Fon: +49-331-567 7274
Mail: steffen.grunewald(at)aei.mpg.de
~~~


More information about the linux-fai mailing list