On Tuesday, 25 May 2021 16:23:01 BST Peter Humphrey wrote: > Thanks for the offer, Michael, but let me clear a few things up first. > > 1. I don't use symlinks in /boot.
This allows a simpler single boot partition (ESP) & filesystem set up (VFAT). > 2. I don't use grub, nor any other boot manager. From what you've written below you have installed and now use systemd-boot. > 3. ...unless you count bootctl, from sys-boot/systemd-boot. OK, bootctl is a command interfacing with the UEFI firmware API, while systemd-boot, once you install it, is a 3rd party boot manager as I've mentioned in my previous message. Disambiguation: a) UEFI boot manager - the 'native' EEPROM based UEFI boot loader/manager. It scans all .efi executables, inc. Linux et al OS kernel images stored on the ESP; updates and stores a list of .efi executables in its database and; presents them in the UEFI boot menu as manually selectable boot options. Unless the user enters the UEFI boot menu at start up, by pressing a key like F2, the first .efi executable on the list will be loaded and run. The list of executables can be manipulated using the efibootmgr command, or the UEFI menu interface itself. b) efibootmgr - a userspace command interfacing with the UEFI firmware API, used to manipulated the UEFI executable applications listed in the UEFI database. c) bootctl - a userspace command interfacing with the UEFI firmware API like efibootmgr and also with the systemd-boot boot manager (if installed). d) systemd-boot - a 3rd party boot manager (like GRUB, rEFInd, syslinux, etc.). > 4. I have the existing ESP mounted on /boot. It belongs to Windows and > cannot be enlarged beyond 100MB. This should not be a problem per se, unless bootctl & systemd-boot, with its own Boot Loader specification limitations, *must* be used as their developers intended (more below). For example, on this box I have: # du -s -h /boot/*/* 3.1M /boot/BOOT/boot.sdi 1.6M /boot/EFI/Boot 27M /boot/EFI/Gentoo 25M /boot/EFI/Microsoft My ESP is 273MB, but the MSWindows boot files plus Gentoo with two kernels (no initrd.gz) take up only 56.7M. I could add two more kernels in there and still receive change from 100M - mind you some kernels are more frugally configured than others. I notice you have /dev/nvme1n1p1 named as "boot". Is this a secondary boot partition? What is its mountpoint? What does it contain? > 5. I have a small second system on the Gentoo disk called Rescue, so I have > a multiple-boot system. > > # tree -L 3 /boot > /boot > ├── EFI > │ ├── Boot > │ │ └── bootx64.efi > │ ├── Linux > │ ├── Microsoft > │ │ ├── Boot > │ │ └── Recovery > │ └── systemd > │ └── systemd-bootx64.efi > ├── System.map-5.10.27-gentoo > ├── System.map-5.10.27-gentoo-rescue > ├── amd-uc.img > ├── config-5.10.27-gentoo > ├── config-5.10.27-gentoo-rescue > ├── loader > │ ├── entries > │ │ ├── 08-gentoo-rescue-5.10.27.conf > │ │ ├── 09-gentoo-rescue-5.10.27.nonet.conf > │ │ ├── 30-gentoo-5.10.27.conf > │ │ ├── 32-gentoo-5.10.27.nox.conf > │ │ └── 34-gentoo-5.10.27.nonet.conf > │ ├── loader.conf > │ └── random-seed > ├── vmlinuz-5.10.27-gentoo > └── vmlinuz-5.10.27-gentoo-rescue > > # parted -l > [...] > Model: Samsung SSD 970 EVO Plus 250GB (nvme) > Disk /dev/nvme0n1: 250GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 1 1049kB 106MB 105MB fat32 EFI system partition boot, esp > 2 106MB 123MB 16.8MB Microsoft reserved partition > msftres > 3 123MB 249GB 249GB ntfs Basic data partition msftdata > 4 249GB 250GB 580MB ntfs Basic data partition hidden, > diag > > Model: Samsung SSD 970 EVO Plus 250GB (nvme) > Disk /dev/nvme1n1: 250GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 1 1049kB 269MB 268MB ext4 boot > 2 269MB 34.6GB 34.4GB linux-swap(v1) swap-1 swap > 3 34.6GB 51.8GB 17.2GB ext4 rescue > 4 51.8GB 86.2GB 34.4GB ext4 root > 5 86.2GB 90.5GB 4295MB ext4 local > 6 90.5GB 103GB 12.9GB ext4 home > 7 103GB 129GB 25.8GB ext4 common > [...] > > I followed the installation handbook, boot-loader section, to create a UEFI > boot entry. I followed the syntax precisely, with several variations at > various attempts. In every case, the UEFI BIOS listed the new entry but > couldn't execute it. This should work to launch your systemd-boot: efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "systemd-boot" -- loader "\EFI\Boot\bootx64.efi" This would also work, if vmlinuz-5.10.27-gentoo, config-5.10.27-gentoo, and System.map-5.10.27-gentoo are stored on the ESP under the EFI/ directory, e.g. in EFI/Linux/, to launch your current kernel directly: efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Gentoo-5.10.27" -- loader "\EFI\Linux\vmlinuz-5.10.27-gentoo" NOTE: According to its specification, the systemd-boot requires a boot partition "... large enough (let’s say 250MB) ...". If it is smaller, "... a new suitably sized (let’s say 500MB) XBOOTLDR partition ..." is meant to be created to be used as $BOOT. I suppose this is to allow enough space for the devs of various Linux distributions to auto-drop their kernels in there without running out of space. Other 3rd party boot managers are not as demanding. > I want to be shown a list of systems to boot immediately after the POST, > which I'm sure efibootmgr can't do, Right, efibootmgr can be run in a console/terminal on an already up and running Linux OS. Just like bootctl. Neither of them can run immediately after POST, because they are not efi applications. Typically, UEFI firmware do not present a list of efi applications to the user - unless you interrupt the boot process and get into the UEFI menu by pressing an appropriate key. The UEFI firmware will always load and execute the first item on its list, if left to its own devices. If the first item is misconfigured/missing, it'll try to run the next one and so on. > so I ran 'bootctl install' to install > the code (where?) to give me the ability. The systemd-boot installs its efi executable in two places: a) EFI/systemd/systemd-bootx64.efi b) EFI/Boot/bootx64.efi <== Default/fall back efi executable while at the same time it adds it as the first entry in the UEFI firmware boot list, so it is loaded and executed first by the firmware. Once it is launched the systemd-boot will read its own loader configuration files and present a list to the user. > That works, though I do remove > the directory with the 32-hex-digit name, and install my own loader.conf. Sure, the systemd-boot loader configuration files can be edited and overwritten. > The system seems to be stable now. Which is a good enough proof your configuration just works(TM). :-) If it suits your needs, then arguably you don't need to do anything else. If it doesn't suit your needs quite right, you could seek alternatives. I can think of 2 other options you may want to look into. 1. A minimalist option is to not use any 3rd party boot manager and stick with the MoBo's UEFI firmware. By default and without intervention, you will always boot the first ordered entry in the UEFI boot menu, without delay. When you need an alternative kernel/OS, you will press the appropriate key during POST to enter the UEFI menu and select another entry from its boot menu manually. The efibootmgr will have to be used every time you install a new kernel to update/configure the UEFI boot menu list. 2. Use some other better suited 3rd party boot manager (not systemd-boot). The principle is broadly the same as your present setup. Each boot manager has its own idiosyncrasies and commands of choice. GRUB is quite automated, although you can overwrite its grub.conf menu and decline using update-grub, or grub-mkconfig to generate it. Then again, why would you select such a heavily automated and complicated piece of software, only to bypass the very functionality its devs wanted to offer? Contrastingly, syslinux is very simple and lightweight, but you have to manually configure its also very simple boot menu. PS. The UEFI firmware will scan more than a single VFAT partition marked as ESP type, but as far as I know this will only work if the ESP is on the first disk - I haven't tried it.
signature.asc
Description: This is a digitally signed message part.
