Re: [gentoo-user] Dual booting with Windows 10

[Michael]

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.