Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Mick]

On Tue, 1 Oct 2019 at 22:38, Peter Humphrey <peter@××××××××××××.uk> wrote:
>
> On Tuesday, 1 October 2019 18:47:25 BST Mick wrote:
>
> > As I understand it this ID must be the ID bootctl itself reports.
> > However, earlier bootctl versions do not have this set-default ID
> > subcommand.  If you run bootctl with no arguments does it show up?
>
> No, it behaves the same as 'bootctl status'.

OK, 'bootctl --help' and 'man bootctl' ought to show if the installed
version comes with the full list of options or not.


> > If you follow the UEFI spec and store one kernel per EFI/
> > subdirectory, the UEFI firmware will pick them up on its own and the
> > efibootmgr will list them.
> >
> > I would think bootctl will also pick them up and add them in its own menu.
>
> My impression is that efibootmgr only picks up what it's written itself, and
> what the BIOS has filled in. Bootctl does do as you say, though.

The efibootmgr is just a userspace application which interacts with
the UEFI firmware's API to modify the UEFI NVRAM boot manager data.
Unless *you* run it explicitly to change or list the UEFI boot
entries, it will not do anything.

The probing and listing of boot entries is not performed by the
efibootmgr application, but by the UEFI boot manager itself.  The UEFI
boot manager probes the disks for an ESP and then reads and lists the
.efi files in the ESP, provided these were stored as per the UEFI
specification.

The systemd-boot/bootctl reads all /loader/entries/*.conf, and
populates its boot menu with these.  However, /loader/entries/*.conf
files can be generated automagically, as long as you follow the
systemd boot loader specification – yes, I know, yet another
specification!  According to this specification you can/must:

For NON-UEFI bootable images:

1. Drop in the ”$BOOT/loader/entries/ directory one or more
configuration snippets with the suffix “.conf one for each boot menu
item.
2. To differentiate between OS installations and a number of kernels
in each installation you may name each .conf file by including the
machine ID (/etc/machine-id or the D-Bus machine ID for OSes that lack
/etc/machine-id), the kernel version (as returned by uname -r) and an
OS identifier (The ID field of /etc/os-release).  These will be used
to prioritise menu entries.

For UEFI bootable images:

3. Add kernels, initrds, et al. in $BOOT/EFI/Linux/ – the bootable
image should have an .efi suffix.
4. It is recommended to place these files in a vendor and OS and
installation specific directory.

More and better detailed information can be found in the spec:

https://systemd.io/BOOT_LOADER_SPECIFICATION.html


> > If you use a suitable alphanumeric nomenclature to elevate the
> > subdirectory of your kernel of choice, it should be selected as the
> > default (hopefully).
>
> Nope:
>
> # tree /boot/EFI
> /boot/EFI
> ├── BOOT
> │   └── BOOTX64.EFI
> ├── systemd
> │   └── systemd-bootx64.efi
> └── TestSys
>     └── BOOT
>         └── bootX64.efi

The 'BOOT' subdirectory has a specific function, as I mentioned
before.  It is the fallback bootable image, when others fail.  I
suppose the first BOOT subdirectory will take precedence, but having
two of those might confuse matters during parsing of images.


> # ls /boot/loader/entries
> 08-gentoo-4.19.66-rescue.conf        40-gentoo-4.19.66.conf
> 09-gentoo-4.19.66-rescue.nonet.conf  42-gentoo-4.19.66.nox.conf
> 30-gentoo-4.19.72.conf               44-gentoo-4.19.66.nonet.conf
> 32-gentoo-4.19.72.nox.conf           90-testsys-4.19.72.conf
> 34-gentoo-4.19.72.nonet.conf         92-testsys-4.19.72.nonet.conf
>
> Bootctl has picked the test system as its default (90-testsys-4.19.72), and
> the boot menu comes up with it selected; that's why I want to change bootctl's
> default selection. The two files bootx64.efi (modulo case) are identical
> kernel images except for CONFIG_LOCALVERSION="<...>".

Right, I don't know why the bootctl parses the entries .conf files in
this particular order.  The spec suggests to use a naming convention
as per 2. above which *should* work with less effort.


> > Meanwhile, assuming you have set the systemd-boot timeout to a value
> > greater than 0, you could try pressing 'd' after you move  the cursor
> > to the desired kernel image.  I think it sets the selected image as a
> > default, but I don't have a systemd-boot available to see if it merely
> > boots the existing default setting.
>
> That's it! I didn't know about that - where is it documented?

Have you looked at the fine manual for 'systemd-boot'?  :-)

> Thank you for your own patience, Mick.  :)

Don't mention it - I'm a sucker for a challenge involving software
creations I care not use myself!  LOL!
-- 
Regards,
Mick