Grub and Windows Boot Manager are bootloaders, and they can be "on" a drive, but efibootmgr is not. Your EFI is part of your motherboard, and efibootmgr is just a tool that helps you configure your EFI. The actual EFI configuration is stored on your motherboard, not on either drive. For what it's worth, I vaguely remember a similar tool available in Windows. If you change your configuration in efibootmgr, you would see the changes in the Windows tool, too, because you only have one EFI (which both tools can access).
On Mon, Apr 17, 2023, 09:32 Mark Knecht <markkne...@gmail.com> wrote: > > > 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:~$ >
