[gentoo-user] updating /boot directory EFI

[t***@sys-concept.com]

After installing new kernel how to update /boot EFI directory?

From my notes, I have:
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot

or should it be:
grub-mkconfig -o /boot/grub/grub.cfg
efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Gentoo" -l /boot/grub/x86_64-efi/core.efi

Boot partition is:
/dev/nvme0n1p1 = /boot

[t***@sys-concept.com]

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg
efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Gentoo" -l /boot/grub/x86_64-efi/core.efi
/dev/nvme0n1p1   =  /boot

This is not dual boot system, so I don't know why /boot has EFI directory

[Mitch D.]

When you emerge grub, Gentoo compiles and "installs" grub (and some
grub-related tools) to a directory inside your Gentoo installation, just
like other applications. The catch is that grub isn't like other
applications... it needs to run outside of Gentoo, before Linux starts.
This means that Grub isn't very useful sitting inside your Gentoo
installation.

"grub-install" copies Grub from your Gentoo installation to your hard drive
/ SSD / etc. This has nothing to do with your kernel, it only involves
Grub. Rerun this command when you emerge updates to Grub.

"efibootmgr" tells your motherboard's (U)EFI firmware where to find Grub
(or any other bootloader or EFI tool). When you emerge an update for Grub
(and run grub-install), the path shouldn't change, so there's no need to
rerun efibootmgr. This also has nothing to do with your kernel.

"grub-mkconfig" generates a configuration file that Grub reads while the
computer is booting, and generally tells Grub what options to include in
the menu Grub displays. When you update your kernel, you want to update
that menu, so you SHOULD rerun "grub-mkconfig" at this time.

All EFI systems are supposed to have an EFI system partition (ESP). Some
people use the ESP as their boot partition, while other people keep them as
two separate partitions and mount the boot partition as /boot and the ESP
as /boot/EFI. Either way, it's not related to dual-booting.

NOTE: if I remember correctly, there are USE flags that can be enabled to
automatically run grub-install and grub-mkconfig when updates are installed
for Grub and for kernels, respectively.

-Hypoon

Post by t***@sys-concept.com

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg
efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Gentoo" -l

/boot/grub/x86_64-efi/core.efi

Post by t***@sys-concept.com
/dev/nvme0n1p1 = /boot

This is not dual boot system, so I don't know why /boot has EFI directory

[Peter Humphrey]

Post by Mitch D.
All EFI systems are supposed to have an EFI system partition (ESP). Some
people use the ESP as their boot partition, while other people keep them as
two separate partitions and mount the boot partition as /boot and the ESP
as /boot/EFI.

I think certain EFI BIOSes will only co-operate with certain directory
layouts. I've had mixed experiences anyway.

[Lee K]

Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

[Dale]

Post by Lee K
Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

OP:  I can't agree more.  Just a couple weeks ago, my system wouldn't
boot except to a rescue thingy.  I had to boot another media, mount
everything, do some changes and reboot.  If I didn't have notes, it
would have been a nightmare.  Keep in mind, I have a LOT of drives.  I
try to keep the OS on sda at all times tho.  It's a good start.  Given I
just rearranged to add a SSD drive, I'm updating my notes, again.  Also,
keep a known working bootable media available.  It's best to have both a
CD/DVD and a USB stick. 

Always, ALWAYS, have up to date notes on drives, especially those you
would need to boot something else and fix a unbootable system.  Best
advice you may ever get along with having something else to boot from. 

Dale

:-)  :-) 

[t***@sys-concept.com]

Post by Lee K
Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

Thanks Lee, that is really helpful hint.

[Wol]

Post by t***@sys-concept.com

Post by Lee K
Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

Thanks Lee, that is really helpful hint.

Or, seeing as grub is deprecated with EFI, learn how to boot using EFI.

Don't worry, I haven't really learned either :-) I just keep a Slack
live-CD handy ...

Cheers,
Wol

[hitachi303]

A minimal EFI bootloader can show an updated menu for the new kernels
without needing to make regular writes to the EFI variable storage. I
didn't know Grub was deprecated, but there are other options. rEFInd is
pretty. Syslinux is flexible.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader

Default: GRUB

[Mitch D.]

Wol, can you elaborate on why you think Grub is deprecated on EFI systems?

Post by hitachi303

A minimal EFI bootloader can show an updated menu for the new kernels
without needing to make regular writes to the EFI variable storage. I
didn't know Grub was deprecated, but there are other options. rEFInd is
pretty. Syslinux is flexible.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader
Default: GRUB

[Wol]

Post by Mitch D.
Wol, can you elaborate on why you think Grub is deprecated on EFI systems?

Because EFI is a boot manager? Why chain-load boot managers?

Cheers,
Wol

Post by Mitch D.

A minimal EFI bootloader can show an updated menu for the new

kernels

without needing to make regular writes to the EFI variable

storage. I

didn't know Grub was deprecated, but there are other options.

rEFInd is

pretty. Syslinux is flexible.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader
<https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader>
Default: GRUB

[Anna]

Post by Wol

Post by Mitch D.
Wol, can you elaborate on why you think Grub is deprecated on EFI systems?

Because EFI is a boot manager? Why chain-load boot managers?
Cheers,
Wol

Just because you may not see a reason why, doesn't mean that it is
deprecated. GRUB supports UEFI.

[Arsen Arsenović]

Post by Wol

Post by Mitch D.
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.

Post by Wol
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/

Post by Wol
Cheers,
Wol

Post by Mitch D.

A minimal EFI bootloader can show an updated menu for the new

kernels

without needing to make regular writes to the EFI variable

storage. I

didn't know Grub was deprecated, but there are other options.

rEFInd is

pretty. Syslinux is flexible.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader
<https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader>
Default: GRUB

[Michael]

Post by Arsen Arsenović

Post by Wol

Post by Mitch D.
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.

Post by Arsen Arsenović

Post by Wol
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.

[Mark Knecht]

Post by Michael

Post by Arsen Arsenović

Post by Wol

Post by Mitch D.
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.

Post by Arsen Arsenović

Post by Wol
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:

***@science2:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
Boot0003* ubuntu
***@science2:~$

2) The more complicated view with GUIDs and such:

***@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)
***@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:

***@science2:~$ cat bin/RebootWindows
sudo efibootmgr -n 0000
reboot
***@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.

***@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
***@science2:~$

[Michael]

Post by Mark Knecht
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
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
Boot0003* ubuntu
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)

This shows the efibootmgr is using the first disk and boots the Windows
BOOTMGFW.EFI, or Ubuntu's shimX64.efi from there.

Post by Mark Knecht
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
sudo efibootmgr -n 0000
reboot
The 'problem' with this setup is that all of the grub/efibootmgr stuff
is on both drives

Are you sure?

Post by Mark Knecht
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.
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

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.

Your GRUB EFI bootable image is on /dev/nvme0n1p1, under /boot/efi/EFI/ubuntu/

Post by Mark Knecht
tmpfs 3.2G 64K 3.2G 1% /run/user/1000

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.

[Mark Knecht]

<SNIP>

Post by Michael

Post by Mark Knecht
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.

Post by Michael

Post by Mark Knecht
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

Post by Michael

Post by Mark Knecht
TU \SHIMX64.EFI)

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>

Post by Michael

Post by Mark Knecht
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

Post by Michael
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?

Post by Michael
Your GRUB EFI bootable image is on /dev/nvme0n1p1, under

/boot/efi/EFI/ubuntu/

Post by Michael

Post by Mark Knecht
tmpfs 3.2G 64K 3.2G 1% /run/user/1000

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

[Michael]

Post by Mark Knecht
One thing I haven't decoded is why Windows is 0000 and Kubuntu is 0003.

See below ...

Post by Mark Knecht
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.

[Mark Knecht]

Post by Michael

Post by Mark Knecht
One thing I haven't decoded is why Windows is 0000 and Kubuntu is 0003.

See below ...

Post by Mark Knecht
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

[Lee]

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

Lee 😎

Post by Mark Knecht
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

[Wols Lists]

Post by Mark Knecht
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

[Peter Humphrey]

Post by Mark Knecht
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?

[Wols Lists]

Post by Peter Humphrey

Post by Mark Knecht
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

[Mitch D.]

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

Post by Arsen Arsenović

Post by Michael

Post by Arsen Arsenović

Post by Wol

Post by Mitch D.
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.

Post by Michael

Post by Arsen Arsenović
There is technical capability for UEFI firmware to act in such a

manner,

Post by Michael

Post by Arsen Arsenović
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

Post by Michael
EFI boot stub enabled, may render 3rd party boot managers and their boot
loaders redundant. However, as already mentioned below, the flexibility

and

Post by Michael
customisability of GRUB and other boot manager exceeds any UEFI firmware

I've

Post by Michael
come across.

Post by Arsen Arsenović

Post by Wol
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,

Post by Michael

Post by Arsen Arsenović
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

Post by Michael
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

Post by Michael
FAT32 has remained quite resilient too. No loss of data or fs

corruption yet

Post by Michael
(keeps fingers crossed and checks backups).
My particular systems setup and use case suits this approach, but I

appreciate

Post by Michael
people who multiboot daily/frequently, or need to boot LiveISOs off the

disk

Post by Michael
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
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
Boot0003* ubuntu
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)
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
sudo efibootmgr -n 0000
reboot
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.
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

[Mitch D.]

There is a catch related to using EFI without a conventional bootloader. If
you want your boot menu to include details such as kernel versions, then it
would be necessary to run efibootmgr every time you update the kernel. I'm
not sure if the EFI variable storage is resilient to repeated writes, so
this could be dangerous. The alternative is to have a couple generic EFI
boot entries, such as "Gentoo" and "Gentoo (Old Kernel)", which point to
consistent paths, then you replace the kernel at those paths without
needing to update the boot entry each time.

A minimal EFI bootloader can show an updated menu for the new kernels
without needing to make regular writes to the EFI variable storage. I
didn't know Grub was deprecated, but there are other options. rEFInd is
pretty. Syslinux is flexible.

It's probably not a huge issue, but I doubt the EFI data chip on the
motherboard has been chosen for its write endurance.

Post by Wol

Post by t***@sys-concept.com

Post by Lee K
Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

Thanks Lee, that is really helpful hint.

Or, seeing as grub is deprecated with EFI, learn how to boot using EFI.
Don't worry, I haven't really learned either :-) I just keep a Slack
live-CD handy ...
Cheers,
Wol

[Peter Humphrey]

Post by Wol
Or, seeing as grub is deprecated with EFI, learn how to boot using EFI.
Don't worry, I haven't really learned either :-) I just keep a Slack
live-CD handy ...

(I'm tired and it's bedtime, so I hope you'll overlook any boo-boos.)

You can save yourself loads of grub complication and rewriting of boot loaders
by using bootctl from systemd-utils. It will give you plenty of flexibility
too. (Don't ask me why a recent version decided to display boot entries in
reverse order. Beas me.)

$ tree -L 3 /boot
/boot
├── amd-uc.img
├── config-5.15.88-gentoo-rescue
├── config-5.15.94-gentoo
├── config-6.1.19-gentoo-rescue
├── config-6.2.10-gentoo
├── config-6.2.9-gentoo
├── EFI
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Microsoft
│ │ ├── Boot
│ │ └── Recovery
│ └── systemd
│ └── systemd-bootx64.efi
├── loader
│ ├── entries
│ │ ├── 06-gentoo-rescue-5.15.88.conf
│ │ ├── 07-gentoo-rescue-5.15.88.nonet.conf
│ │ ├── 08-gentoo-rescue-6.1.19.conf
│ │ ├── 09-gentoo-rescue-5.1.19.nonet.conf
│ │ ├── 30-gentoo-6.2.10.conf
│ │ ├── 32-gentoo-6.2.10.nox.conf
│ │ ├── 34-gentoo-6.2.10.nonet.conf
│ │ ├── 40-gentoo-5.15.94.conf
│ │ ├── 42-gentoo-5.15.94.nox.conf
│ │ └── 44-gentoo-5.15.94.nonet.conf
│ ├── entries.srel
│ ├── loader.conf
│ └── random-seed
├── System.map-5.15.88-gentoo-rescue
├── System.map-5.15.94-gentoo
├── System.map-6.1.19-gentoo-rescue
├── System.map-6.2.10-gentoo
├── System.map-6.2.9-gentoo
├── vmlinuz-5.15.88-gentoo-rescue
├── vmlinuz-5.15.94-gentoo
├── vmlinuz-6.1.19-gentoo-rescue
├── vmlinuz-6.2.10-gentoo
└── vmlinuz-6.2.9-gentoo

9 directories, 31 files

The layout above gives me a menu of four images to boot: the main system and a
rescue system, each with an earlier version in case of need. The main system
has a no-network option and a no-X option as well as the standard system. The
rescue system of course doesn't have X.

$ cat /usr/local/bin/kmake
#!/bin/bash
[[ $(/bin/cat /proc/mounts | /bin/grep boot) ]] || /bin/mount /boot
cd /usr/src/linux
time (/usr/bin/make -j24 && /usr/bin/make modules_install && /usr/bin/make install &&\
/bin/rm -f /boot/*old && /bin/echo
) &&\
/bin/echo && /bin/echo "Rebuilding modules..." && /bin/echo &&\
/usr/bin/emerge @module-rebuild @x11-module-rebuild
/bin/echo && /bin/ls -lh --color=auto /boot
/bin/echo

...and that's how I build a new kernel: with kmake. Then I just have to munge
the /boot/loader/entries with an mmv command and a couple of seds, then
'bootctl update'. Simple enough even for me.

You may be able to see from all that why I abandoned grub years ago. Far too
bloated, restrictive and cumbersome.

By the way, I hardly ever have to use efibootmgr; the only common cause is
having to delete the odd spurious entry.

[Arsen Arsenović]

Post by Wol

Post by t***@sys-concept.com

Post by Lee K
Also, learn how to boot a kernel from the grub cli, and keep a printed
version of these instructions in a handy place. This has saved my butt
countless times. :)

Thanks Lee, that is really helpful hint.

Or, seeing as grub is deprecated with EFI, learn how to boot using EFI.

I'm not sure where you got this - GRUB supports and continues to be
supported on UEFI.

[t***@sys-concept.com]

When you emerge grub, Gentoo compiles and "installs" grub (and some grub-related tools) to a directory inside your Gentoo installation, just like other applications. The catch is that grub isn't like other applications... it needs to run outside of Gentoo, before Linux starts. This means that Grub isn't very useful sitting inside your Gentoo installation.
"grub-install" copies Grub from your Gentoo installation to your hard drive / SSD / etc. This has nothing to do with your kernel, it only involves Grub. Rerun this command when you emerge updates to Grub.
"efibootmgr" tells your motherboard's (U)EFI firmware where to find Grub (or any other bootloader or EFI tool). When you emerge an update for Grub (and run grub-install), the path shouldn't change, so there's no need to rerun efibootmgr. This also has nothing to do with your kernel.
"grub-mkconfig" generates a configuration file that Grub reads while the computer is booting, and generally tells Grub what options to include in the menu Grub displays. When you update your kernel, you want to update that menu, so you SHOULD rerun "grub-mkconfig" at this time.
All EFI systems are supposed to have an EFI system partition (ESP). Some people use the ESP as their boot partition, while other people keep them as two separate partitions and mount the boot partition as /boot and the ESP as /boot/EFI. Either way, it's not related to dual-booting.
NOTE: if I remember correctly, there are USE flags that can be enabled to automatically run grub-install and grub-mkconfig when updates are installed for Grub and for kernels, respectively.
-Hypoon

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg
efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Gentoo" -l /boot/grub/x86_64-efi/core.efi
/dev/nvme0n1p1   =  /boot

This is not dual boot system, so I don't know why /boot has EFI directory

Thank you Hypoon and folks for detail explanation. Always learn something new.
So once EFI is installed during grub installation there is no need to touch it, by running:

grub-install --target=x86_64-efi --efi-directory=/boot

And thanks Lee for a hint about booting kernel manually from grub command line.
I'll definitely look it up and make some notes.
Anybody can share more information on it.

And NO, I'll not look check ChatGPT, don't want to end up with unbootable system :-)

[Dr Rainer Woitok]

Mitch,

Post by Mitch D.
...
"grub-install" copies Grub from your Gentoo installation to your hard drive
/ SSD / etc. This has nothing to do with your kernel, it only involves
Grub. Rerun this command when you emerge updates to Grub.

Is this really necessary to be done manually? Shouldn't this be the job
of the Grub ebuild? My gut feeling is that having to look out for Grub
updates and then to manually run "grub-install" every time is not really
Gentoo-like ...

To be honest, I've run this command once during my initial Gentoo in-
stall three and a half years back, but never since. And according to my
logs I've since then upgraded Grub ten times and rebuilt it four times.
Should I worry? Can this be automated?

Post by Mitch D.
...
NOTE: if I remember correctly, there are USE flags that can be enabled to
automatically run grub-install and grub-mkconfig when updates are installed
for Grub and for kernels, respectively.

Checking the USE flags for Grub and Portage I didn't find anything for
automatically running "grub-install". Where else to look?

Sincerely,
Rainer

[Mitch D.]

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

I don't see a USE flag to automate the process after all, so I must have
been misremembering. It might be difficult to automate, and perhaps more
importantly, it's not always reversible. Installing grub to an MBR will
clobber anything else that was previously there. Another challenge is for
portage to reliably identify the target device. For example, using software
RAID, grub-install probably needs to be run multiple times, once targeting
each physical disk. Overall, I think it's possible, but it's not trivial,
and it would probably need a config file.

Should you worry? Probably not. Version 2.04 was stabilized in January
2020, so the version number has only increased once since then, maybe twice
if you originally installed Gentoo in 2019. The rest of the upgrades were
ebuild revisions. Since ebuild revisions can include patches and have other
important corrections, I would rerun grub-install if I were you, but I
wouldn't say it's urgent.

Post by Dr Rainer Woitok
Mitch,

Post by Mitch D.
...
"grub-install" copies Grub from your Gentoo installation to your hard

drive

Post by Mitch D.
/ SSD / etc. This has nothing to do with your kernel, it only involves
Grub. Rerun this command when you emerge updates to Grub.

Is this really necessary to be done manually? Shouldn't this be the job
of the Grub ebuild? My gut feeling is that having to look out for Grub
updates and then to manually run "grub-install" every time is not really
Gentoo-like ...
To be honest, I've run this command once during my initial Gentoo in-
stall three and a half years back, but never since. And according to my
logs I've since then upgraded Grub ten times and rebuilt it four times.
Should I worry? Can this be automated?

Post by Mitch D.
...
NOTE: if I remember correctly, there are USE flags that can be enabled to
automatically run grub-install and grub-mkconfig when updates are

installed

Post by Mitch D.
for Grub and for kernels, respectively.

Checking the USE flags for Grub and Portage I didn't find anything for
automatically running "grub-install". Where else to look?
Sincerely,
Rainer

[Dr Rainer Woitok]

Mitch,

Post by Mitch D.
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

[Mitch D.]

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.

Post by Dr Rainer Woitok
Mitch,

Post by Mitch D.
I just took a quick glance at the ebuild, and it looks like it should

print

Post by Mitch D.
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

[Nikos Chantziaras]

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?

You don't need to. You only need to do that when you want to reinstall
GRUB itself into the EFI partition. The kernel is installed in /boot,
not into the EFI partition.

[Wol]

Post by Nikos Chantziaras

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?

You don't need to. You only need to do that when you want to reinstall
GRUB itself into the EFI partition. The kernel is installed in /boot,
not into the EFI partition.

And if grub isn't installed?

Basically you have a choice. Install grub into EFI, and use grub as your
boot manager. Or ditch grub (the recommended route) and use EFI as your
boot manager.

If you do the latter, whether it's called /boot or /boot/EFI, you have
to update the EFI directory.

Cheers,
Wol

[Nikos Chantziaras]

Post by Wol

Post by Nikos Chantziaras

Post by t***@sys-concept.com
After installing new kernel how to update /boot EFI directory?

You don't need to. You only need to do that when you want to reinstall
GRUB itself into the EFI partition. The kernel is installed in /boot,
not into the EFI partition.

And if grub isn't installed?

It is.

Post by Wol
Basically you have a choice. Install grub into EFI, and use grub as your
boot manager. Or ditch grub (the recommended route) and use EFI as your
boot manager.

EFI can't boot my ISO images (sysrescuecd and memtest86+.)