Mailing List Archive

On 4/15/23 22:01, thelma@sys-concept.com wrote:
> 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

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

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

On Sun, Apr 16, 2023, 00:19 <thelma@sys-concept.com> wrote:

> On 4/15/23 22:01, thelma@sys-concept.com wrote:
> > 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
>
> This is not dual boot system, so I don't know why /boot has EFI directory
>
>
>

On Sunday, 16 April 2023 12:16:09 BST Mitch D. wrote:

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

--
Regards,
Peter.

On 16/04/2023 07:01, thelma@sys-concept.com wrote:
> 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.

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

--
Lee

Lee K wrote:
> 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

:-)  :-) 

On 4/16/23 05:16, Mitch D. wrote:
> 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
>
> On Sun, Apr 16, 2023, 00:19 <thelma@sys-concept.com <mailto:thelma@sys-concept.com>> wrote:
>
> On 4/15/23 22:01, thelma@sys-concept.com <mailto:thelma@sys-concept.com> wrote:
> > 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
>
> 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 :-)

On 4/16/23 08:49, Lee K wrote:
> 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.

On 16/04/2023 18:43, thelma@sys-concept.com wrote:
>
> On 4/16/23 08:49, Lee K wrote:
>> 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

On 16/04/2023 15:22, Nikos Chantziaras wrote:
> On 16/04/2023 07:01, thelma@sys-concept.com wrote:
>> 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

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.

On Sun, Apr 16, 2023, 14:31 Wol <antlists@youngman.org.uk> wrote:

> On 16/04/2023 18:43, thelma@sys-concept.com wrote:
> >
> > On 4/16/23 08:49, Lee K wrote:
> >> 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
>
>

Am 16.04.23 um 21:11 schrieb 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

Default: GRUB

On Mon, Apr 17, 2023 at 12:13:18AM +0100, Wol wrote:
> 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? 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.

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

On Sun, Apr 16, 2023, 15:17 hitachi303 <gentoo-user@konstantinhansen.de>
wrote:

> Am 16.04.23 um 21:11 schrieb 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
>
> Default: GRUB
>
>

On Sunday, 16 April 2023 19:31:23 BST Wol wrote:

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

--
Regards,
Peter.

Wol <antlists@youngman.org.uk> writes:

> On 16/04/2023 18:43, thelma@sys-concept.com wrote:
>> On 4/16/23 08:49, Lee K wrote:
>>> 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.
--
Arsen Arsenovi?

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? Why chain-load boot managers?

Cheers,
Wol
>
> On Sun, Apr 16, 2023, 15:17 hitachi303 <gentoo-user@konstantinhansen.de
> <mailto:gentoo-user@konstantinhansen.de>> wrote:
>
> Am 16.04.23 um 21:11 schrieb 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
>

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.

> 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/

> Cheers,
> Wol
>> On Sun, Apr 16, 2023, 15:17 hitachi303 <gentoo-user@konstantinhansen.de
>> <mailto:gentoo-user@konstantinhansen.de>> wrote:
>> Am 16.04.23 um 21:11 schrieb 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
>>


--
Arsen Arsenovi?

Mitch,

On Sunday, 2023-04-16 07:16:09 -0400, you wrote:

> ...
> "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?

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

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.

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.

On Mon, Apr 17, 2023, 05:55 Dr Rainer Woitok <rainer.woitok@gmail.com>
wrote:

> Mitch,
>
> On Sunday, 2023-04-16 07:16:09 -0400, you wrote:
>
> > ...
> > "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?
>
> > ...
> > 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
>

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 16/04/2023 21:44, Wol wrote:
> On 16/04/2023 15:22, Nikos Chantziaras wrote:
>> On 16/04/2023 07:01, thelma@sys-concept.com wrote:
>>> 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.


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

On Monday, 17 April 2023 14:31:08 BST Mark Knecht wrote:

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


> 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

Are you sure?


> 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

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/

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