Mailing List Archive

Dual booting with Windows 10
Hello list,

Mynew machine has Win-10 installedon /dev/nvme0n1 with the ESP as partition 1. I want to install Gentoo on /dev/nvme1n1. So far I haven't found a way to set up a working boot arrangement. I've tried mounting the ESP on /efi, on /EFI and on /boot/EFI. Efibootmgr seems to write a boot entry in some of those cases, and it's still there after a reboot - but it isn't visible to the BIOS.

Can anyone offer some enlightenment, please?
Re: Dual booting with Windows 10 [ In reply to ]
On Friday, 21 May 2021 15:42:01 BST peter@prh.myzen.co.uk wrote:
> Hello list,
>
> Mynew machine has Win-10 installedon /dev/nvme0n1 with the ESP as partition
> 1. I want to install Gentoo on /dev/nvme1n1. So far I haven't found a way
> to set up a working boot arrangement. I've tried mounting the ESP on /efi,
> on /EFI and on /boot/EFI. Efibootmgr seems to write a boot entry in some of
> those cases, and it's still there after a reboot - but it isn't visible to
> the BIOS.
>
> Can anyone offer some enlightenment, please?

If your ESP is on /dev/nvme0n1 and you are using vmlinuz symlinks, you can use
/boot/EFI as the mountpoint for the ESP VFAT partition. Your kernels/config/
System.map/initrd.img files will go into /boot, which will be on the same fs
as / on /dev/nvme1, using a fs which supports symlinks.

The efibootmgr '--loader' option should/could be used to specify the path to
your bootloader image, or if you are not using a bootloader image to chainload
your kernel with, point it directly to the path of your kernel; e.g.

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "gentoo-5.10.27" \
--loader "\EFI\gentoo\gentoo-5.10.27.efi"

The BIOS/UEFI menu should be able to list entries of bootable *.efi images, as
long as they are within the subdirectory of /boot/EFI on the ESP, but if you
are using a bootloader, then it is the bootloader image which will run and
chainload your OSs and their kernels.
Re: Dual booting with Windows 10 [ In reply to ]
On Friday, 21 May 2021 20:06:25 BST Michael wrote:
> On Friday, 21 May 2021 15:42:01 BST peter@prh.myzen.co.uk wrote:
> > Hello list,
> >
> > Mynew machine has Win-10 installedon /dev/nvme0n1 with the ESP as
> > partition
> > 1. I want to install Gentoo on /dev/nvme1n1. So far I haven't found a way
> > to set up a working boot arrangement. I've tried mounting the ESP on /efi,
> > on /EFI and on /boot/EFI. Efibootmgr seems to write a boot entry in some
> > of
> > those cases, and it's still there after a reboot - but it isn't visible to
> > the BIOS.
> >
> > Can anyone offer some enlightenment, please?
>
> If your ESP is on /dev/nvme0n1 and you are using vmlinuz symlinks, you can
> use /boot/EFI as the mountpoint for the ESP VFAT partition. Your
> kernels/config/ System.map/initrd.img files will go into /boot, which will
> be on the same fs as / on /dev/nvme1, using a fs which supports symlinks.
>
> The efibootmgr '--loader' option should/could be used to specify the path to
> your bootloader image, or if you are not using a bootloader image to
> chainload your kernel with, point it directly to the path of your kernel;
> e.g.
>
> efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "gentoo-5.10.27" \
> --loader "\EFI\gentoo\gentoo-5.10.27.efi"
>
> The BIOS/UEFI menu should be able to list entries of bootable *.efi images,
> as long as they are within the subdirectory of /boot/EFI on the ESP, but if
> you are using a bootloader, then it is the bootloader image which will run
> and chainload your OSs and their kernels.

Thanks Michael. I've finally got it booting, by resorting to the same hack as I
did on my previous machine.

Using efibootmgr to add a UEFI boot record does create it, but selecting it in
the BIOS fails and it just drops to the next in line: Windows 10. No
adjustments to the --create command resulted in a bootable system, so I had to
run bootctl-install as well and then remove the hex-numbered directory and
restore my own loader.conf. I spent days wrestling with this.

It's clear that I just don't understand UEFI booting. It sounds simple enough,
but it clearly isn't. I've read everything I could find on the subject, to no
avail.

--
Regards,
Peter.
Re: Dual booting with Windows 10 [ In reply to ]
On Monday, 24 May 2021 14:11:00 BST Peter Humphrey wrote:
> On Friday, 21 May 2021 20:06:25 BST Michael wrote:
> > On Friday, 21 May 2021 15:42:01 BST peter@prh.myzen.co.uk wrote:
> > > Hello list,
> > >
> > > Mynew machine has Win-10 installedon /dev/nvme0n1 with the ESP as
> > > partition
> > > 1. I want to install Gentoo on /dev/nvme1n1. So far I haven't found a
> > > way
> > > to set up a working boot arrangement. I've tried mounting the ESP on
> > > /efi,
> > > on /EFI and on /boot/EFI. Efibootmgr seems to write a boot entry in some
> > > of
> > > those cases, and it's still there after a reboot - but it isn't visible
> > > to
> > > the BIOS.
> > >
> > > Can anyone offer some enlightenment, please?
> >
> > If your ESP is on /dev/nvme0n1 and you are using vmlinuz symlinks, you can
> > use /boot/EFI as the mountpoint for the ESP VFAT partition. Your
> > kernels/config/ System.map/initrd.img files will go into /boot, which will
> > be on the same fs as / on /dev/nvme1, using a fs which supports symlinks.
> >
> > The efibootmgr '--loader' option should/could be used to specify the path
> > to your bootloader image, or if you are not using a bootloader image to
> > chainload your kernel with, point it directly to the path of your kernel;
> > e.g.
> >
> > efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "gentoo-5.10.27"
> > \
> > --loader "\EFI\gentoo\gentoo-5.10.27.efi"
> >
> > The BIOS/UEFI menu should be able to list entries of bootable *.efi
> > images,
> > as long as they are within the subdirectory of /boot/EFI on the ESP, but
> > if
> > you are using a bootloader, then it is the bootloader image which will run
> > and chainload your OSs and their kernels.
>
> Thanks Michael. I've finally got it booting, by resorting to the same hack
> as I did on my previous machine.
>
> Using efibootmgr to add a UEFI boot record does create it, but selecting it
> in the BIOS fails and it just drops to the next in line: Windows 10. No
> adjustments to the --create command resulted in a bootable system, so I had
> to run bootctl-install as well and then remove the hex-numbered directory
> and restore my own loader.conf. I spent days wrestling with this.
>
> It's clear that I just don't understand UEFI booting. It sounds simple
> enough, but it clearly isn't. I've read everything I could find on the
> subject, to no avail.

Peter, what efibootmgr stanza do you use to create your UEFI boot records? It
seems the UEFI firmware fails to process what you provided and proceeds to the
next bootable option (Windows 10).

Typically you would either run efibootmgr to inform the UEFI firmware of your
OSs kernels directly, or you would engage the services of a boot manager to
list and boot your chosen OS. In the former, the UEFI firmware will boot the
OS directly. In the latter, the UEFI firmware will load the boot manager and
then the boot manager will select and boot the OS.

The process for updating the UEFI boot menu with available kernel images using
the efibootmgr command, is different to updating the boot menu of a 3rd party
boot manager. The two are not related, other than ultimately loading the
selected kernel/initrd.

Something you should note is unlike 3rd party boot managers, the UEFI firmware
cannot boot directly symlinked vmlinuz and initrd.gz files. This is because
the UEFI parses the contents of the ESP, which is formatted in VFAT - a
filesystem which does not support symlinks. In this case, a 3rd party boot
manager will be launched by the UEFI firmware from within the ESP, which will
be in possession of required 'os-prober' and filesystem drivers to access and
launch the OS kernel/initrd image from your root partition.

You can contact me off list if you want to work through the detail of
configuring your system with and without a boot manager. I think once it
clicks, you'll be able to apply your preferred solution without much trouble
in the future.
Re: Dual booting with Windows 10 [ In reply to ]
On Monday, 24 May 2021 16:14:43 BST Michael wrote:

> You can contact me off list if you want to work through the detail of
> configuring your system with and without a boot manager. I think once it
> clicks, you'll be able to apply your preferred solution without much trouble
> in the future.

Thanks for the offer, Michael, but let me clear a few things up first.

1. I don't use symlinks in /boot.
2. I don't use grub, nor any other boot manager.
3. ...unless you count bootctl, from sys-boot/systemd-boot.
4. I have the existing ESP mounted on /boot. It belongs to Windows and cannot
be enlarged beyond 100MB.
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.

I want to be shown a list of systems to boot immediately after the POST, which
I'm sure efibootmgr can't do, so I ran 'bootctl install' to install the code (where?) to give me the ability. That works, though I do remove the directory
with the 32-hex-digit name, and install my own loader.conf.

The system seems to be stable now.

--
Regards,
Peter.
Re: Dual booting with Windows 10 [ In reply to ]
On 25/05/2021 16:23, Peter Humphrey wrote:
> 4. I have the existing ESP mounted on /boot. It belongs to Windows and cannot
> be enlarged beyond 100MB.

I don't know how this works, but I installed Windows 10 and SUSE
dual-boot. SUSE installed a second 500MB ESP, and it works. Somehow the
system must be able to link the two together.

Cheers,
Wol
Re: Dual booting with Windows 10 [ In reply to ]
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.
Re: Dual booting with Windows 10 [ In reply to ]
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?

--->8

> I notice you have /dev/nvme1n1p1 named as "boot". Is this a secondary boot
> partition? What is its mountpoint? What does it contain?

It's a hangover from my attempts earlier. I'll remove it soon.

--->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 ...

> 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.

> efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Gentoo-5.10.27" --
> loader "\EFI\Linux\vmlinuz-5.10.27-gentoo"

--->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.

> 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.

--
Regards,
Peter.
Re: Dual booting with Windows 10 [ In reply to ]
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.
Re: Dual booting with Windows 10 [ In reply to ]
On Thursday, 27 May 2021 12:01:27 BST Michael wrote:

> 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.

I'll look into it. Thanks for the tip. :)

--
Regards,
Peter.