curtin-dev team mailing list archive

[Dimitri John Ledkov <dimitri.ledkov+lp@xxxxxxxxxxxxx>]

> This looks good.  Can we get a comment in the commit message describing the
> failure?
> In particular, I'm also looking to understand if this failure is reproducible
> in VMTest so we can add that scenario to VMTest in this commit as well.

There are no failures per-se. Specifically efibootmgr writes out any boot entry you ask it to write with whichever path to any non-existing boot loader.

Then if one is not doing network boot; or network boot grub uses `exit 1` (whilst using grub2 from focal-proposed and up); attempt to boot directly the `centos` menu entry is done, and that fails logging OS failure error into BMC, the esp \EFI\BOOT\BOOTX64.efi is usually discovered, which executes and creates the centos menu entry from \efi\boot\centos\bootx64.csv file with different capitalisation of the menu entry; whilst also removing any existing (broken/invalid) entries. And then booting into that. Then doing selinux autorelabel. Then finally booting normally.

To model this into a VMTest one would do something like this:
1) at the end of deploy, remember all efibootmgr entry numbers & values
2) figure out which entry number was the centos one
3) set it to be bootnext entry
4) reboot
5) instance should come as the centos one; with efibootmgr -v reporting that the centos is unchanged from the values remembered in step 1)
6) current bootentry should also be the one we remembered to be in step 2)
-- 
https://code.launchpad.net/~xnox/curtin/+git/curtin/+merge/396823
Your team curtin developers is requested to review the proposed merge of ~xnox/curtin:lp1906379-2 into curtin:master.