[gentoo-user] updating /boot directory EFI

[gentoo-user] updating /boot directory EFI

[thelma]

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

-- 
Thelma

Re: [gentoo-user] updating /boot directory EFI

[thelma]

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
  

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3063 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Peter Humphrey]

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.

[gentoo-user] Re: updating /boot directory EFI

[Nikos Chantziaras]

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.

Re: [gentoo-user] updating /boot directory EFI

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

-- 
Lee

Re: [gentoo-user] updating /boot directory EFI

[Dale]

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

:-)  :-) 

Re: [gentoo-user] updating /boot directory EFI

[thelma]

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

Re: [gentoo-user] updating /boot directory EFI

[thelma]

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.
  

Re: [gentoo-user] updating /boot directory EFI

[Wol]

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

Re: [gentoo-user] Re: updating /boot directory EFI

[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

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2090 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[hitachi303]

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

Re: [gentoo-user] updating /boot directory EFI

[Anna]

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.

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 999 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Peter Humphrey]

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.

Re: [gentoo-user] updating /boot directory EFI

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]


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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Wol]

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
> 

Re: [gentoo-user] updating /boot directory EFI

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]


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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Dr Rainer Woitok]

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

Re: [gentoo-user] updating /boot directory EFI

[Michael]

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.

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3333 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 4491 bytes --]

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:~$

[-- Attachment #2: Type: text/html, Size: 5381 bytes --]

[gentoo-user] Re: updating /boot directory EFI

[Nikos Chantziaras]

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

Re: [gentoo-user] updating /boot directory EFI

[Michael]

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.

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 5342 bytes --]

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:~$
>

[-- Attachment #2: Type: text/html, Size: 6365 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4736 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Michael]

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.

Re: [gentoo-user] updating /boot directory EFI

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2564 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Dr Rainer Woitok]

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

Re: [gentoo-user] updating /boot directory EFI

[Wols Lists]

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

Re: [gentoo-user] updating /boot directory EFI

[Mitch D.]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2808 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Lee]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1208 bytes --]

Re: [gentoo-user] updating /boot directory EFI

[Peter Humphrey]

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.

Re: [gentoo-user] updating /boot directory EFI

[Wols Lists]

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