On Thursday, 27 May 2021 09:22:33 BST Peter Humphrey wrote: > On Wednesday, 26 May 2021 14:49:01 BST Michael wrote: > > 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). > > How do symlinks work on a FAT32 partition?
They don't. Hence binary Linux distributions' boot files are typically spread over two partitions, ESP and /. Distributions which deploy symlinks of vmlinuz, vmlinuz.old and initrd.gz, initrd.gz.old, plus all the kernel files they point to, have these stored on the OS / partition under /boot/. The OS / partition is invariably formatted with a filesystem which supports symlinks, e.g. ext4. The 3rd party boot manager's efi image is stored instead on the ESP, in a subdirectory under mountpoint /boot/efi. When a distribution's kernel update/install scripts are run, the latest kernel images are copied to /boot/ and the vmlinuz and initrd.gz symlinks are replaced accordingly. The boot manager's efi image under /boot/efi does not change, unless it has a new version installed. > --->8 > > > > 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" > > It didn't, but ... Hmm ... if neither "\EFI\systemd\systemd-bootx64.efi", nor the fallback image "\EFI\Boot\bootx64.efi" allowed you to boot Gentoo, then I suspect this was because something was amiss with the systemd-boot configuration. The UEFI firmware would be able to load and run either of the above files (one is a copy of the other). Thereafter, it would be up to the systemd-boot image to manage the boot process and load whatever you had pointed it to and it had managed to find. Of course, this assumes the systemd-boot entry was above the Microsoft boot manager entry in the UEFI boot menu list. Running 'efibootmgr' or going into the UEFI menu at start up would confirm the list order as far as the MoBo firmware is concerned. > > 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: > > That's the point I was missing - where those three files live. I had them at > the root of the FS, as implied by the installation wiki. Right, the installation handbook is trying to cover all bases and the permutations of partition table types, partitions, fs formats and mountpoints are large. The idea of using vmlinuz symlinks at the root of /boot is to simplify/script the installation of a new kernel. The boot manager just needs to be configured to boot vmlinuz and vmlinuz old and this does not change. What does change is the kernel image these symlinks point to. Keeping kernel images on the OS / partition means the ESP itself can be quite small too, since only the boot manager efi image and a fallback image need to be stored on it. The systemd-boot specification expects devs to drop their kernels within a suitably named subdirectory within the EFI directory, which is why systemd- boot is averse to a small size ESP. > --->8 > > > 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. > > I don't want to start on about grub. I washed my hands of it a few years > ago, after struggling to set it up to offer a choice including a kernel > with three run-level options: default, no X and no network. Heh! I've always felt GRUB2, as opposed to GRUB-legacy, was trying to solve a problem I never had. ;-) That said, GRUB2 offers minimal hassle when used with vanilla configurations. > > 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. > > That may be Wol's answer. > > Thanks again for all the work you've put into this, Michael. You're welcome. :-) I found choosing a tool which is a best fit for the user requirements is usually easier than trying to bend a less suitable tool to do what you desire. If a boot menu at *each* start up is a must, have you given syslinux any consideration? It is simpler to configure and probably more flexible than systemd-boot.
signature.asc
Description: This is a digitally signed message part.
