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

[Michael]

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.