On Tue, 1 Oct 2019 at 22:38, Peter Humphrey <[email protected]> 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
