Mailing List Archive

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 <markknecht@gmail.com> wrote:

>
>
> On Mon, Apr 17, 2023 at 4:57?AM Michael <confabulate@kintzios.com> wrote:
> >
> > On Monday, 17 April 2023 00:29:49 BST Arsen Arsenovi? wrote:
> > > Wol <antlists@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:~$
>

On Mon, Apr 17, 2023 at 8:18?AM Michael <confabulate@kintzios.com> wrote:
>
> On Monday, 17 April 2023 14:31:08 BST Mark Knecht wrote:
<SNIP>
> > 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\UBUN
> > TU \SHIMX64.EFI)
> > mark@science2:~$
>
> This shows the efibootmgr is using the first disk and boots the Windows
> BOOTMGFW.EFI, or Ubuntu's shimX64.efi from there.

OK, that part makes perfect sense and the files are there.

Additionally the GUID in each HD(...) entry matches the GUID on
/dev/nvme0n1p1
which has a type "EFI system partition" in fdisk. Good so far.

<SNIP>

> > The 'problem' with this setup is that all of the grub/efibootmgr stuff
> > is on both drives
>
> Are you sure?

Yes, there is a directory but that directory, which did have a Kubuntu
boot image in the past, is now empty.

HISTORY. I bought the computer with Win 10 installed and a
second empty M.2 drive. To install Kubuntu I switched BIOS to
boot from that drive, installed Kubuntu which populated the EFI
directory with all of the stuff you're showing me. I did not know about
the efibootmgr at the time as this was my fist new MB in about 8
years.

Early on I went to Windows by changing BIOS because, for what
ever reason the Kubuntu install didn't see the Windows disk. I
am assuming that was probably me completely disabling it in
BIOS but I don't remember the details.

Later on a Kubuntu update found Windows, updated the EFI
stuff on the Windows drive and then, I see this morning,
erased everything out of the Kubuntu EFI partition but
left the partition there.

<SNIP>i
>
> This is where the ESP is mounted, but you'll find /boot directory is on
your /
> dev/nvme1n1p3 block device, along with your kernels, initrd images and
> vimlinuz symlinks.
>

Correct.

ESP? EFI System Partition possibly?


> Your GRUB EFI bootable image is on /dev/nvme0n1p1, under
/boot/efi/EFI/ubuntu/
>
> > tmpfs 3.2G 64K 3.2G 1% /run/user/1000
> > mark@science2:~$
>
> I would think Ubuntu installed GRUB on nvme0n1p1 ESP, which it detected by
> scanning your disks. If your nvme0n1p1 fails and has to be removed, you
will
> need to create a new ESP somewhere on the ubuntu disk and then you can
> reinstall GRUB after you reboot with a LiveUSB, or while still running
ubuntu.

Understood. Thanks.

One thing I haven't decoded is why Windows is 0000 and Kubuntu is 0003.

I now better understand Mitch D.'s point that the pointers to which OS to
boot are not in a disk file, like the old grub configuration, but rather in
Flash memory on the motherboard. I suppose the numbering is just the
luck of the draw, or that 0001 and 0002 were used at one time and no longer
present, but that's just a guess.

For anyone following along or reading later, there's an easily read web page
on things you can do with efibootmgr located here:

https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples

Also, the Windows app similar to efibootmgr (but untested by me) is
possibly called bootcfg.exe

- Mark

On Monday, 17 April 2023 17:52:25 BST Mark Knecht wrote:

> One thing I haven't decoded is why Windows is 0000 and Kubuntu is 0003.

See below ...


> I now better understand Mitch D.'s point that the pointers to which OS to
> boot are not in a disk file, like the old grub configuration, but rather in
> Flash memory on the motherboard. I suppose the numbering is just the
> luck of the draw, or that 0001 and 0002 were used at one time and no longer
> present, but that's just a guess.

Exactly the latter, they are no longer present. I copy kernel images manually
to /boot/EFI/Gentoo/ and run 'efibootmgr --create' to add entries to the UEFI
boot menu with my choice of labels. They are added being numbered
incrementally. If I remove some of the older menu entries, their
corresponding numbers are also removed and become available for any new
bootable .efi images I may add in the future.

In addition, if I boot with any USB drives attached, the UEFI firmware will
scan such devices and add any bootable images to the UEFI boot menu stored in
NVRAM, by numbering such images incrementally. This will further increase the
numbers of boot menu entries, which once the USB devices are removed their
entry number will become vacant and available to be reallocated.

On Mon, Apr 17, 2023 at 10:11?AM Michael <confabulate@kintzios.com> wrote:
>
> On Monday, 17 April 2023 17:52:25 BST Mark Knecht wrote:
>
> > One thing I haven't decoded is why Windows is 0000 and Kubuntu is 0003.
>
> See below ...
>
>
> > I now better understand Mitch D.'s point that the pointers to which OS
to
> > boot are not in a disk file, like the old grub configuration, but
rather in
> > Flash memory on the motherboard. I suppose the numbering is just the
> > luck of the draw, or that 0001 and 0002 were used at one time and no
longer
> > present, but that's just a guess.
>
> Exactly the latter, they are no longer present. I copy kernel images
manually
> to /boot/EFI/Gentoo/ and run 'efibootmgr --create' to add entries to the
UEFI
> boot menu with my choice of labels. They are added being numbered
> incrementally. If I remove some of the older menu entries, their
> corresponding numbers are also removed and become available for any new
> bootable .efi images I may add in the future.
>
> In addition, if I boot with any USB drives attached, the UEFI firmware
will
> scan such devices and add any bootable images to the UEFI boot menu
stored in
> NVRAM, by numbering such images incrementally. This will further
increase the
> numbers of boot menu entries, which once the USB devices are removed their
> entry number will become vacant and available to be reallocated.
>

Ah, so in that case if I booted the original Kubuntu install from a USB
stick
then possibly an entry was used doing that. I also used memtest86 prior
to the Kubuntu install so possibly that was an entry.

Anyway, it makes more sense now.

If you go back into the archives for this list, list December I asked a
question
"Duel boot - How to verify boot loader updates?". That was maybe a month
or two after I noticed the Kubuntu ESP being changed and the Windows
ESP being mounted instead. I just never finished the thread what with the
holidays and visitors, etc.

I appreciate the help so thanks and maybe the thread will help someone
else one of these days.

Cheers,
Mark

Mitch,

On Monday, 2023-04-17 08:15:51 -0400, you wrote:

> I just took a quick glance at the ebuild, and it looks like it should print
> a reminder ("Re-run grub-install to update installed boot code!") every
> time you upgrade from an older version to a newer one, but it also looks
> like the reminder gets skipped if you're re-emerging the same version.
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.06-r4.ebuild#n314

Thankyou very much for this information. But is there anyone out there
who skims through tons of SUCCESSFUL emerge log files after every rou-
tine upgrade? Personally, I only check the logs in case of build fai-
lures or conflicts.

By the way, I only see this message in the build logs for versions 2.06-
r4 and 2.06-r6, but not in older logs. So maybe that's a rather new ad-
dition to the ebuild file?

Since I do my routine upgrades via a script anyway, I now retrieve the
name of the most recent Grub build log before I really start "emerge"
and after "emerge" finished, and if the two names differ and the newer
file contains this "Re-run ..." message, I now run "grub-install" from
within this script. Problem solved.

But I have the vague feeling there should be a more foolproof solution.

Sincerely,
Rainer

On 17/04/2023 17:52, Mark Knecht wrote:
> Later on a Kubuntu update found Windows, updated the EFI
> stuff on the Windows drive and then, I see this morning,
> erased everything out of the Kubuntu EFI partition but
> left the partition there.

I had a similar problem trying to install SUSE to dual boot a laptop. I
made the mistake of letting Windows wipe the disk and install itself,
with the result I was left with a tiny EFI partition. I couldn't install
linux because there was no room.

My latest attempt (when I get gentoo video working) will be to *add*
Windows to a working system.

Cheers,
Wol

You can probably use a portage hook to do it. I haven't tested it, but
something along the lines of creating a file at
"/etc/portage/env/sys-boot/grub" which contains an implementation of the
"post_pkg_postinst()" function. Then, you can copy the logic from the
ebuild to determine whether the version number has changed. Realistically
though, I'd probably skip the conditional logic and let the hook run
grub-install every time.

Some ebuilds print rather important messages, and if you're updating
software regularly, there shouldn't be tons of messages in
/var/log/portage/elog/summary.log. At the very least, I would configure it
to email me a copy of the messages so that I can review them as soon as I
can.

On Mon, Apr 17, 2023 at 4:26?PM Dr Rainer Woitok <rainer.woitok@gmail.com>
wrote:

> Mitch,
>
> On Monday, 2023-04-17 08:15:51 -0400, you wrote:
>
> > I just took a quick glance at the ebuild, and it looks like it should
> print
> > a reminder ("Re-run grub-install to update installed boot code!") every
> > time you upgrade from an older version to a newer one, but it also looks
> > like the reminder gets skipped if you're re-emerging the same version.
> >
> >
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.06-r4.ebuild#n314
>
> Thankyou very much for this information. But is there anyone out there
> who skims through tons of SUCCESSFUL emerge log files after every rou-
> tine upgrade? Personally, I only check the logs in case of build fai-
> lures or conflicts.
>
> By the way, I only see this message in the build logs for versions 2.06-
> r4 and 2.06-r6, but not in older logs. So maybe that's a rather new ad-
> dition to the ebuild file?
>
> Since I do my routine upgrades via a script anyway, I now retrieve the
> name of the most recent Grub build log before I really start "emerge"
> and after "emerge" finished, and if the two names differ and the newer
> file contains this "Re-run ..." message, I now run "grub-install" from
> within this script. Problem solved.
>
> But I have the vague feeling there should be a more foolproof solution.
>
> Sincerely,
> Rainer
>

Never mix Windows with real OS's if you can avoid it. I have separate
machine for Windows.

Lee ????

On Mon, Apr 17, 2023, 1:41 PM Wols Lists <antlists@youngman.org.uk> wrote:

> On 17/04/2023 17:52, Mark Knecht wrote:
> > Later on a Kubuntu update found Windows, updated the EFI
> > stuff on the Windows drive and then, I see this morning,
> > erased everything out of the Kubuntu EFI partition but
> > left the partition there.
>
> I had a similar problem trying to install SUSE to dual boot a laptop. I
> made the mistake of letting Windows wipe the disk and install itself,
> with the result I was left with a tiny EFI partition. I couldn't install
> linux because there was no room.
>
> My latest attempt (when I get gentoo video working) will be to *add*
> Windows to a working system.
>
> Cheers,
> Wol
>
>

On Monday, 17 April 2023 21:41:09 BST Wols Lists wrote:
> On 17/04/2023 17:52, Mark Knecht wrote:
> > Later on a Kubuntu update found Windows, updated the EFI
> > stuff on the Windows drive and then, I see this morning,
> > erased everything out of the Kubuntu EFI partition but
> > left the partition there.
>
> I had a similar problem trying to install SUSE to dual boot a laptop. I
> made the mistake of letting Windows wipe the disk and install itself,
> with the result I was left with a tiny EFI partition. I couldn't install
> linux because there was no room.
>
> My latest attempt (when I get gentoo video working) will be to *add*
> Windows to a working system.

Can you not just resize the partition?

--
Regards,
Peter.

On 17/04/2023 23:36, Peter Humphrey wrote:
> On Monday, 17 April 2023 21:41:09 BST Wols Lists wrote:
>> On 17/04/2023 17:52, Mark Knecht wrote:
>>> Later on a Kubuntu update found Windows, updated the EFI
>>> stuff on the Windows drive and then, I see this morning,
>>> erased everything out of the Kubuntu EFI partition but
>>> left the partition there.
>>
>> I had a similar problem trying to install SUSE to dual boot a laptop. I
>> made the mistake of letting Windows wipe the disk and install itself,
>> with the result I was left with a tiny EFI partition. I couldn't install
>> linux because there was no room.
>>
>> My latest attempt (when I get gentoo video working) will be to *add*
>> Windows to a working system.
>
> Can you not just resize the partition?
>
Not any more :-)

But I don't tend to do that sort of thing. Which is why my main (linux
only) machine has pretty much all the disk in one huge raid partition
with lvm on top ...

Cheers,
Wol