On Mon, Apr 17, 2023 at 4:57 AM Michael <confabul...@kintzios.com> wrote:
>
> On Monday, 17 April 2023 00:29:49 BST Arsen Arsenović wrote:
> > Wol <antli...@youngman.org.uk> writes:
> > > On 16/04/2023 22:30, Mitch D. wrote:
> > >> Wol, can you elaborate on why you think Grub is deprecated on EFI
> > >> systems?
> > >
> > > Because EFI is a boot manager?
> >
> > That is not the case any more than the classic IBM PC boot procedure is.
> > There is technical capability for UEFI firmware to act in such a manner,
> > but, in practice, this is not at all the case.
> >
> > The technical capability comes from the fact that boot entities have a
> > lil' bit of metadata attached to them.
>
> The ability of UEFI to boot linux kernels, as long as they are built with
the
> EFI boot stub enabled, may render 3rd party boot managers and their boot
> loaders redundant. However, as already mentioned below, the flexibility
and
> customisability of GRUB and other boot manager exceeds any UEFI firmware
I've
> come across.
>
>
> > > Why chain-load boot managers?
> >
> > In theory, EFI implementations should provide boot
> > managers. Unfortunately, in practice these boot managers are often so
> > poor as to be useless. The worst I've personally encountered is on
> > Gigabyte's Hybrid EFI, which provides you with no boot options
> > whatsoever, beyond choosing the boot device (hard disk vs. optical disc,
> > for instance). I've heard of others that are just as bad. For this
> > reason, a good EFI boot manager—either standalone or as part of a boot
> > loader—is a practical necessity for multi-booting on an EFI
> > computer. That's where rEFInd comes into play.
> > - https://rodsbooks.com/refind/
>
> I've stopped using GRUB and have been using the UEFI firmware to boot
directly
> Gentoo for more than 10 years now. Given I have also flashed some of the
> MoBos' chipset with new UEFI firmware a dozen times or more, I have not
> experienced any MoBo failures as yet. Also, the ESP partition formatted
with
> FAT32 has remained quite resilient too. No loss of data or fs corruption
yet
> (keeps fingers crossed and checks backups).
>
> My particular systems setup and use case suits this approach, but I
appreciate
> people who multiboot daily/frequently, or need to boot LiveISOs off the
disk
> may find GRUB and friends to be a more suitable solution.
>
>
My needs are quite simple but efibootmgr, set up by the Kubuntu install
on a separate M.2 from the Windows install the machine came with, works for
me. I always start the day in Kubuntu, then reboot to Windows if I'm working
on music:
1) The simple view of the two installations:
mark@science2:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
Boot0003* ubuntu
mark@science2:~$
2) The more complicated view with GUIDs and such:
mark@science2:~$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
HD(1,GPT,2052c843-0057-494a-a749-e8ec3676514a,0x800,0x32000)/File(\EF
I\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4
.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0003* ubuntu
HD(1,GPT,2052c843-0057-494a-a749-e8ec3676514a,0x800,0x32000)/File(\EFI\UBUNTU
\SHIMX64.EFI)
mark@science2:~$
3) To get to Windows I can choose it in the OS screen if I'm sitting there
but the most reliable way for me to get from Kubuntu to Windows is to just
tell the system to go to Windows at the next boot using a batch file in
Kubuntu:
mark@science2:~$ cat bin/RebootWindows
sudo efibootmgr -n 0000
reboot
mark@science2:~$
The 'problem' with this setup is that all of the grub/efibootmgr stuff
is on both drives and I'm never sure which drive is being used at
which time as I have Kubuntu on nvme1 and Windows boot
manager on nvme0 which I'm never comfortable with but the
Ubuntu stuff figured it out so I don't argue. Pity me if I ever have to
do a reinstall.
mark@science2:~$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.2G 3.7M 3.2G 1% /run
/dev/nvme1n1p3 916G 622G 248G 72% /
tmpfs 16G 66M 16G 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/nvme0n1p1 96M 32M 65M 33% /boot/efi
tmpfs 3.2G 64K 3.2G 1% /run/user/1000
mark@science2:~$
