UEFI boot order, Re: Tip: Remote FAI install

[Steffen Grunewald]

On Mon, 2021-02-08 at 12:31:22 -0600, John G Heim wrote:
> In these days when so many of us are working from home, I thought I'd give a
> tip I discovered today on how to trigger an FAI install remotely.
> 
> For years I've been triggering an FAI install remotely by wiping the hard
> drive and hoping PXE boot was somewhere in the boot sequence. That had the
> drawback of making the machine unbootable if anything went wrong. But on a
> machine with a EUFI, you can tell it to reorder the boot sequence for the
> next reboot.
> 
> 1. Display a list of the boot devices with the efibootmgr command:
> 
> # efibootmgr -v
> 
> Take not of the hex number assigned to your network interface. On my
> desktop, the disk is device 0 and the NIC is F.
> 
> 2. Change the boot  sequence for the next boot:
> 
> # efibootmgr -o F,0
> 
> This tells the EUFI to boot from the NIC first, and if that fails, to boot
> from the hard disk. The sequence should return to the previous sequence
> after one reboot.
> 
> 3. Reboot.
> 
> If you have FAI configured to reboot the target machine when it is finished,
> you should be able to ssh back into a fully loaded Linux machine once the
> install is done.

Good morning fellow FAIers.


First, thanks John for your instructions.


I found that the devil is in the details, and the overall approach might be
wrong... Let me explain.


I received a couple new machines yesterday, and - of course - BOOT mode was
set to UEFI (with LEGACY still available - if you can get your hands on the
BIOS settings, that is).
After some tweaking of my rather old package lists (which still had "grub2"
in them in several places... conflicting with "grub-efi" nowadays), I was
able to install one of the machines - once.
It turned out that the boot order was modified by the grub setup step,
putting the HD ("debian") entry on top of the network interfaces (1-4 for me,
BTW).
This would disable any subsequent installation, in particular from power-off
state, which is somewhat counterintuitive if you've been used to the LEGACY
order for a long time that would not change, so you'd have Network first,
and HD further down the list - non-existence of a matching TFTP entry (after
having run fai-chboot) would just boot the installed system, but if there
was a fresh entry I would get a FAI run.
Not so for UEFI: with the boot order changed, I would have to re-change it
to get another network boot, either by running "efibootmgr" as above (which
requires a running machine) or by hand (which requires direct access to the
machine to change the BIOS setting). That's not exactly FAI style...

There is a way out though.
*IF* one takes the BootOrder line from "efibootmgr" output *BEFORE* running
the grub installer, and restores it *AFTER*, boot order would be the same
as before (= as once set in the BIOS, usually network first). Problem gone.

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).


Thomas, does this make sense?

Cheers, 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
~~~