boot/grub

[Patrick Dupre]

Hello,

On a multi-boot PC, how grub is updated?
In the past /etc/grub2.cfg was updated.

and now?

It seems that there are 2 tools: bootctl, and efibootmgr

What are the files managed by these tools?

How to understand?
BootCurrent: 000F

Which tool is run after an update of the kernel?

Thank.

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================

[George N. White III]

On Sun, 31 May 2020 at 05:41, Patrick Dupre <pdupre(a)gmx.com&gt; wrote:

>  Hello,
>
>  On a multi-boot PC, how grub is updated?
>  In the past /etc/grub2.cfg was updated.
>
>  and now?
>
>  It seems that there are 2 tools: bootctl, and efibootmgr
>
>  What are the files managed by these tools?
>
>  How to understand?
>  BootCurrent: 000F
>  
Is there a problem you need to solve or are you trying to understand how
booting is handled by Fedora on an EFI system?

Where did you see this: error message, log, or ??   On a dual boot system
using EFI,  "efibootmgr" with no arguments should display something like:

 % efibootmgr
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0000
Boot0000* Windows Boot Manager
Boot0003* Fedora

A better name for the "Fedora" entry might be "Grub boot manager".


>  Which tool is run after an update of the kernel?
>  
bootctl -- both those tools have man pages that explain how they are used.


Since you are multi-booting,
https://en.wikipedia.org/wiki/EFI_system_partition might he helpful.

>  
The grub configuration files were recently reorganized into a
grub.d
directory (you can opt out and stick with the old structure). See:
https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators...

-- 
George N. White III

[Sam Varshavchik]

Patrick Dupre writes:

>  Hello,
>
>  On a multi-boot PC, how grub is updated?
>  In the past /etc/grub2.cfg was updated.
>
>  and now?
>
>  It seems that there are 2 tools: bootctl, and efibootmgr
>
>  What are the files managed by these tools?
>
>  How to understand?
>  BootCurrent: 000F
>
>  Which tool is run after an update of the kernel? 
grubby is used to select which kernel to boot by default.

[Jonathan Billings]

On May 31, 2020, at 04:41, Patrick Dupre <pdupre(a)gmx.com&gt; wrote:
>  On a multi-boot PC, how grub is updated?
>  In the past /etc/grub2.cfg was updated. 
Specifically, with the legacy bootloader, it was /boot/grub2/grub.cfg that was updated,
and the file in /etc was a symlink.

>  and now? 
If you use the legacy bootloader, it remains the same, but any modern x86_64 hardware will
use UEFI. So the grub.cfg is in /boot/efi/EFI/fedora/, along with the .efi executable for
grub (and a signed shim EFI executable, for Secure Boot). 

>  It seems that there are 2 tools: bootctl, and efibootmgr 
bootctl is part of systemd-boot, which is a different bootloader than GRUB2.  By default
on Fedora x86, GRUB2 is used. 

The ‘efibootmgr’ tool is used to interact with the computer’s UEFI firmware.  The firmware
is what launches on boot, and it is configured with efibootmgr with what EFI executable to
launch.  You need a fat32-formatted partition with the EFI label, which has an /EFI
directory at its root.  All UEFI-compatible firmwares can read those volumes and look for
EFI executables within.  So you can put a CentOS, Ubuntu, or Microsoft executable (or all
of them!) and configure boot entries for each.  There is a BootOrder EFI firmware variable
that stores the order in which it chooses what to boot, depending on which is available. 
There’s the BootCurrent variable, as you mentioned, which shows what was last used to
boot, and a BootNext which you can use to (temporarily) boot next boot. 

>  What are the files managed by these tools? 
All EFI variables
are stored in the EFI firmware. Linux makes them available as files in /sys/firmware/efi/.
**DO NOT MESS WITH THESE FILES OR DELETE THEM**. You can brick your hardware if you do so.
 Just use the efibootmgr tool to change things.

Once grub is launched, it reads the grub.cfg in the EFI directory.  Modern Fedora doesn’t
change the grub.cfg anymore, it reads data out of /boot/loader/entries/, where a grub.cfg
fragment exists for each kernel.

Remember when I mentioned that the EFI was a fat32 filesystem?  Turns out that it’s a
pretty unreliable filesystem and if the computer makes changes to it and is
unceremoniously powered off, it will have a dirty bit set and the OS can’t even mount it
when you start back up, causing boot errors and dropping you into the rescue shell. By
putting a static grub.cfg into the EFI volume and all the changing entries into
/boot/loader/entries, you’re only writing to a volume that is a journaled ext4 or XFS
volume, which can be easily recovered. I believe that’s why there was the change. 

>  Which tool is run after an update of the kernel? 
/bin/kernel-install is run with a bunch of parameters.  It handles detection of what
bootloader (grub legacy vs grub efi) and adding all the correct entries and may call tools
such as grubby. 

There’s a bit more complexity to this but this is all I can remember off the top of my
head and type on a mobile device.  (It’s too nice outside here to get out of my hammock!)

--
Jonathan Billings <billings(a)negate.org&gt;

[Patrick Dupre]

Thank Jonathan for all these clarifications.

I have just one concern

This is what is in /boot/efi/EFI/fedora/grub.cfg

menuentry 'Fedora 30 (Thirty) (on /dev/sdc3)' --class fedora --class gnu-linux
--class gnu --class os $menuentry_id_option
'osprober-gnulinux-simple-da1fb213-c138-4711-aba2-76a598506283' {
	insmod part_msdos
	insmod ext2
	set root='hd2,msdos2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos2 --hint-efi=hd2,msdos2
--hint-baremetal=ahci2,msdos2  9089ac44-babc-47c3-9fb5-a51a95931a7d
	else
	  search --no-floppy --fs-uuid --set=root 9089ac44-babc-47c3-9fb5-a51a95931a7d
	fi
	linux /vmlinuz-5.0.16-100.fc28.x86_64 root=UUID=da1fb213-c138-4711-aba2-76a598506283 ro
rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=fr-latin9 rd.luks=0 LANG=en_US.UTF-8
	initrd /initramfs-5.0.16-100.fc28.x86_64.img
}

Why there is still some tace of fc28 messed with fc30?
I could not remove kernel-core fc28 (the only kernel fc28 package)



===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Sunday, May 31, 2020 at 8:54 PM
> From: "Jonathan Billings" <billings(a)negate.org&gt;
> To: "Community support for Fedora users"
<users(a)lists.fedoraproject.org&gt;
> Subject: Re: boot/grub
>
> On May 31, 2020, at 04:41, Patrick Dupre <pdupre(a)gmx.com&gt; wrote:
> > On a multi-boot PC, how grub is updated?
> > In the past /etc/grub2.cfg was updated.
> 
> Specifically, with the legacy bootloader, it was /boot/grub2/grub.cfg that was
updated, and the file in /etc was a symlink.
> 
> > and now?
> 
> If you use the legacy bootloader, it remains the same, but any modern x86_64 hardware
will use UEFI. So the grub.cfg is in /boot/efi/EFI/fedora/, along with the .efi executable
for grub (and a signed shim EFI executable, for Secure Boot). 
> 
> > It seems that there are 2 tools: bootctl, and efibootmgr
> 
> bootctl is part of systemd-boot, which is a different bootloader than GRUB2.  By
default on Fedora x86, GRUB2 is used. 
> 
> The ‘efibootmgr’ tool is used to interact with the computer’s UEFI firmware.  The
firmware is what launches on boot, and it is configured with efibootmgr with what EFI
executable to launch.  You need a fat32-formatted partition with the EFI label, which has
an /EFI directory at its root.  All UEFI-compatible firmwares can read those volumes and
look for EFI executables within.  So you can put a CentOS, Ubuntu, or Microsoft executable
(or all of them!) and configure boot entries for each.  There is a BootOrder EFI firmware
variable that stores the order in which it chooses what to boot, depending on which is
available.  There’s the BootCurrent variable, as you mentioned, which shows what was last
used to boot, and a BootNext which you can use to (temporarily) boot next boot. 
> 
> > What are the files managed by these tools?
> All EFI variables are stored in the EFI firmware. Linux makes them available as files
in /sys/firmware/efi/. **DO NOT MESS WITH THESE FILES OR DELETE THEM**. You can brick your
hardware if you do so.  Just use the efibootmgr tool to change things.
> 
> Once grub is launched, it reads the grub.cfg in the EFI directory.  Modern Fedora
doesn’t change the grub.cfg anymore, it reads data out of /boot/loader/entries/, where a
grub.cfg fragment exists for each kernel.
> 
> Remember when I mentioned that the EFI was a fat32 filesystem?  Turns out that it’s a
pretty unreliable filesystem and if the computer makes changes to it and is
unceremoniously powered off, it will have a dirty bit set and the OS can’t even mount it
when you start back up, causing boot errors and dropping you into the rescue shell. By
putting a static grub.cfg into the EFI volume and all the changing entries into
/boot/loader/entries, you’re only writing to a volume that is a journaled ext4 or XFS
volume, which can be easily recovered. I believe that’s why there was the change. 
> 
> > Which tool is run after an update of the kernel?
> 
> /bin/kernel-install is run with a bunch of parameters.  It handles detection of what
bootloader (grub legacy vs grub efi) and adding all the correct entries and may call tools
such as grubby. 
> 
> There’s a bit more complexity to this but this is all I can remember off the top of
my head and type on a mobile device.  (It’s too nice outside here to get out of my
hammock!)
> 
> --
> Jonathan Billings <billings(a)negate.org&gt;
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[linux guy]

This has become so complicated.

So if I want to change some of the kernel boot parameters in the grub
command line, on F32, how do I do it ?

[linux guy]

https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators...

[Samuel Sieb]

On 5/31/20 1:45 PM, Patrick Dupre wrote:
>  Thanks,
>  You are correct.
>  I also have Boot000F* Fedora
>  from this distribution (BootCurrent: 000F)
>  and
>  BootCurrent: 0000
>  Timeout: 1 seconds
>  BootOrder: 0000,0002,0001,0003,0004,0005
>  Boot0000* fedora
>   From another one.
>  I wanted to understand what this means.
>  There is logic in this numbers. 
I assume you're looking at the output of "efibootmgr", use "efibootmgr

-v" for more info.  That gives you the list of configured boot entries 
in the EFI which will be different in each computer.  Fedora will take 
the first available slot it finds.  Those are 4 digit hex numbers.  The 
BootCurrent indicates which entry is currently booted.  The BootOrder 
shows which entries it will try in order until it gets one that works.

[Patrick Dupre]

Thank again,

with the -v option, I have
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001
Boot0000*
fedora	HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
Boot0001* Hard Drive	BBS(HD,,0x0)..GO..NO........o.I.N.T.E.L.
.S.S.D.S.C.2.K.W.1.8.0.H.6....................A...........................>..Gd-.;.A..MQ..L.V.C.T.L.2.6.4.6.4.0.6.Z.8.1.B.0.N.G.
. ........BO..NO........o.W.D.C.
.W.D.1.0.E.Z.E.X.-.2.2.M.F.C.A.0....................A...........................>..Gd-.;.A..MQ..L.
. . . .W. .-.D.C.W.6.C.3.Y.E.Z.2.S.K.P........BO..NO........o.M.a.x.t.o.r.
.6.Y.0.8.0.M.0....................A...........................>..Gd-.;.A..MQ..L.2.Y.C.3.H.3.E.2.
. . . . . . . . . . . ........BO
Boot0002* CD/DVD
Drive	BBS(CDROM,,0x0)..GO..NO........o.D.R.W.-.2.4.D.5.M.T....................A...........................>..Gd-.;.A..MQ..L.3.K.G.F.Q.6.2.G.2.8.
.7. . . . . . . . ........BO

If I understand correctly,
I boot on Boot0000  which is on partition 3 (hd0) using /boot/efi/EFI/fedora/grubx64.efi

However, I do not understand how does this work with multi disks.
We have
/boot/efi/EFI/fedora/grubx64.efi
on each disk ?
Which does not seem to be the case.

If I run
grubby --info=ALL

I get only the boot system available on the mounted system

What bothers me also is the date of /boot/efi/EFI/fedora/grub.cfg
-rwx------. 1 root root 15119 Jun  9  2019

I can regenerate it and I have
set default_kernelopts="root=/dev/mapper/VolSys_1-root ro rd.lvm.lv=VolSys_1/root
"
I guess from
cat /etc/default/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=VolSys_1/root"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

But the rest of /boot/efi/EFI/fedora/grub.cfg is not coherent:
There is no menuentry matching the kernels which are on this disk.
There are mixing which old kernels (fc28) from other disks.

Now,
I boot on another disk (fc30)
There is no
/boot/efi/EFI/fedora/grub.cfg
It means that after update of the kernel, 
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
has not been run.

Thus, I am confuse.

In case of multidisks, what does what?


===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================

>
> On 5/31/20 1:45 PM, Patrick Dupre wrote:
> > Thanks,
> > You are correct.
> > I also have Boot000F* Fedora
> > from this distribution (BootCurrent: 000F)
> > and
> > BootCurrent: 0000
> > Timeout: 1 seconds
> > BootOrder: 0000,0002,0001,0003,0004,0005
> > Boot0000* fedora
> >  From another one.
> > I wanted to understand what this means.
> > There is logic in this numbers.
> 
> I assume you're looking at the output of "efibootmgr", use
"efibootmgr 
> -v" for more info.  That gives you the list of configured boot entries 
> in the EFI which will be different in each computer.  Fedora will take 
> the first available slot it finds.  Those are 4 digit hex numbers.  The 
> BootCurrent indicates which entry is currently booted.  The BootOrder 
> shows which entries it will try in order until it gets one that works.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[stan]

On Mon, 1 Jun 2020 11:20:31 +0200
"Patrick Dupre" <pdupre(a)gmx.com&gt; wrote:

>  If I run
>  grubby --info=ALL
>  
>  I get only the boot system available on the mounted system
>  
>  What bothers me also is the date of /boot/efi/EFI/fedora/grub.cfg
>  -rwx------. 1 root root 15119 Jun  9  2019
>  
>  I can regenerate it and I have
>  set default_kernelopts="root=/dev/mapper/VolSys_1-root ro
>  rd.lvm.lv=VolSys_1/root " I guess from
>  cat /etc/default/grub 
>  GRUB_TIMEOUT=5
>  GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
>  GRUB_DEFAULT=saved
>  GRUB_DISABLE_SUBMENU=true
>  GRUB_TERMINAL_OUTPUT="console"
>  GRUB_CMDLINE_LINUX="rd.lvm.lv=VolSys_1/root"
>  GRUB_DISABLE_RECOVERY="true"
>  GRUB_ENABLE_BLSCFG=true
>  
>  But the rest of /boot/efi/EFI/fedora/grub.cfg is not coherent:
>  There is no menuentry matching the kernels which are on this disk.
>  There are mixing which old kernels (fc28) from other disks.
>  
>  Now,
>  I boot on another disk (fc30)
>  There is no
>  /boot/efi/EFI/fedora/grub.cfg
>  It means that after update of the kernel, 
>  grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
>  has not been run.
>  
>  Thus, I am confuse.
>  
>  In case of multidisks, what does what? 
I do not fully understand this, but Chris Murphy explained that there
is only the *one* /boot/efi/ per system and only *one* entry for fedora
in /boot/efi/EFI/. As I understand it, this is because of the efi
standard.  So, if booting more than one version of fedora using efi,
the grub.cfg in /boot/efi/EFI/fedora has to be changed to point to the
correct /boot/loader/entries for that fedora. You could have several
versions of the grub.cfg and just swap them to boot other versions.
Messy. Apparently, this can be solved by using systemd bootctl, an
alternative to grub2, but fedora does not use that and I haven't
investigated further.

[Patrick Dupre]

Thanks,

Actually, I am lost.
I am upgrading one of the systems on a multi-disks system.
1) I realized that one system is not efi, while the other ones are.
2) After I upgraded this system. I can boot it, but it is weird.
a) There was no update of the grub menu (I boot fc32, while the invitation
is still fc30)
b) grub2-mkconfig has not been run
c) grub2-mkconfig (manually) did not recognized by the booted system except through
set root='hd2,msdos3', but no menuentry for this system.


===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Monday, June 01, 2020 at 2:55 PM
> From: "stan via users" <users(a)lists.fedoraproject.org&gt;
> To: users(a)lists.fedoraproject.org
> Cc: "stan" <upaitag(a)zoho.com&gt;
> Subject: Re: boot/grub
>
> On Mon, 1 Jun 2020 11:20:31 +0200
> "Patrick Dupre" <pdupre(a)gmx.com&gt; wrote:
> 
> > If I run
> > grubby --info=ALL
> > 
> > I get only the boot system available on the mounted system
> > 
> > What bothers me also is the date of /boot/efi/EFI/fedora/grub.cfg
> > -rwx------. 1 root root 15119 Jun  9  2019
> > 
> > I can regenerate it and I have
> > set default_kernelopts="root=/dev/mapper/VolSys_1-root ro
> > rd.lvm.lv=VolSys_1/root " I guess from
> > cat /etc/default/grub 
> > GRUB_TIMEOUT=5
> > GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g'
/etc/system-release)"
> > GRUB_DEFAULT=saved
> > GRUB_DISABLE_SUBMENU=true
> > GRUB_TERMINAL_OUTPUT="console"
> > GRUB_CMDLINE_LINUX="rd.lvm.lv=VolSys_1/root"
> > GRUB_DISABLE_RECOVERY="true"
> > GRUB_ENABLE_BLSCFG=true
> > 
> > But the rest of /boot/efi/EFI/fedora/grub.cfg is not coherent:
> > There is no menuentry matching the kernels which are on this disk.
> > There are mixing which old kernels (fc28) from other disks.
> > 
> > Now,
> > I boot on another disk (fc30)
> > There is no
> > /boot/efi/EFI/fedora/grub.cfg
> > It means that after update of the kernel, 
> > grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
> > has not been run.
> > 
> > Thus, I am confuse.
> > 
> > In case of multidisks, what does what?
> 
> I do not fully understand this, but Chris Murphy explained that there
> is only the *one* /boot/efi/ per system and only *one* entry for fedora
> in /boot/efi/EFI/. As I understand it, this is because of the efi
> standard.  So, if booting more than one version of fedora using efi,
> the grub.cfg in /boot/efi/EFI/fedora has to be changed to point to the
> correct /boot/loader/entries for that fedora. You could have several
> versions of the grub.cfg and just swap them to boot other versions.
> Messy. Apparently, this can be solved by using systemd bootctl, an
> alternative to grub2, but fedora does not use that and I haven't
> investigated further.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Jonathan Billings]

On Mon, Jun 01, 2020 at 11:20:31AM +0200, Patrick Dupre wrote:
>  with the -v option, I have
>  BootCurrent: 0000
>  Timeout: 1 seconds
>  BootOrder: 0000,0002,0001
>  Boot0000*
> fedora	HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
>  [...]
>  However, I do not understand how does this work with multi disks.
>  We have
>  /boot/efi/EFI/fedora/grubx64.efi
>  on each disk ?
>  Which does not seem to be the case. 
If you see in the Fedora entry, it has:
HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800\
,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)

That means to look for a volume with the 3rd GPT partition, with the
UUID of a5c3bc11-e83b-48d0-be96-783af37228f1 (and some other data).
On that disk, look for the /EFI/FEDORA/GRUBX64.EFI executable
(remember, this is a DOS filesystem so it's case-insensitive).

Run 'blkid' on a running system, and you'll see that the PARTUUID of
the EFI volume matches the UUID in the above EFI entry.

You can have an EFI volume on multiple disks.  EFI also supports
things like network boot, which has a different syntax EFI entry.  The
efibootmgr command does a lot of the hard work of figuring that out
for you, so you don't need to manually enter that information.

-- 
Jonathan Billings <billings(a)negate.org&gt;

[stan]

On Mon, 1 Jun 2020 15:23:26 +0200
"Patrick Dupre" <pdupre(a)gmx.com&gt; wrote:

>  Thanks,
>  
>  Actually, I am lost.
>  I am upgrading one of the systems on a multi-disks system.
>  1) I realized that one system is not efi, while the other ones are.
>  2) After I upgraded this system. I can boot it, but it is weird.
>  a) There was no update of the grub menu (I boot fc32, while the
>  invitation is still fc30)
>  b) grub2-mkconfig has not been run
>  c) grub2-mkconfig (manually) did not recognized by the booted system
>  except through set root='hd2,msdos3', but no menuentry for this
>  system. 
I've exhausted my knowledge.  I'll make some suggestions, but no
guarantees.

Check /etc/default/grub on the F32 system, and make sure that all the
entries are correct for the F32 system.  It needs to have
GRUB_ENABLE_BLSCFG=true
somewhere in there so that boot loader snippets will work.

Look in /boot/loader/entries/ on the F32 system, and make sure that
there is an entry for each of the F32 kernels that you have installed.

Go into /boot/efi/EFI/fedora/ and run
grub2-mkconfig -o grub.cfg

A reboot should now show F32 as a viable boot option, and as the
default.

[stan]

On Mon, 1 Jun 2020 10:10:41 -0400
Jonathan Billings <billings(a)negate.org&gt; wrote:

>  If you see in the Fedora entry, it has:
>  HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800\
>  ,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
>  
>  That means to look for a volume with the 3rd GPT partition, with the
>  UUID of a5c3bc11-e83b-48d0-be96-783af37228f1 (and some other data).
>  On that disk, look for the /EFI/FEDORA/GRUBX64.EFI executable
>  (remember, this is a DOS filesystem so it's case-insensitive).
>  
>  Run 'blkid' on a running system, and you'll see that the PARTUUID of
>  the EFI volume matches the UUID in the above EFI entry.
>  
>  You can have an EFI volume on multiple disks.  EFI also supports
>  things like network boot, which has a different syntax EFI entry.  The
>  efibootmgr command does a lot of the hard work of figuring that out
>  for you, so you don't need to manually enter that information.
>   
You seem knowledgeable, so I'll ask you.  How does the efi firmware
decide which /boot/efi to use as the source when the computer is
started?  Does it have to be selected from the efi firmware menu at
each boot?

[Patrick Dupre]

Hello,

I guess that very think is more or less, OK, I have just some difficulties
to understand the logic.
>  How does the efi firmware decide which /boot/efi to use as the source
> when the computer is started 
I realized that I have only one EFI System Partition on sda
By default, the system goes to grub, where I can choose the OS.
I do not use the efi options to go there (at least intentionally).

>  Does it have to be selected from the efi firmware menu at each boot?
I do not think so. As I said, I go directly to the grub menu (by default).
I guess that if I active the efi menu, I could choose other options to boot.


===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


>
> On Mon, 1 Jun 2020 10:10:41 -0400
> Jonathan Billings <billings(a)negate.org&gt; wrote:
> 
> > If you see in the Fedora entry, it has:
> > HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800\
> > ,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
> > 
> > That means to look for a volume with the 3rd GPT partition, with the
> > UUID of a5c3bc11-e83b-48d0-be96-783af37228f1 (and some other data).
> > On that disk, look for the /EFI/FEDORA/GRUBX64.EFI executable
> > (remember, this is a DOS filesystem so it's case-insensitive).
> > 
> > Run 'blkid' on a running system, and you'll see that the PARTUUID
of
> > the EFI volume matches the UUID in the above EFI entry.
> > 
> > You can have an EFI volume on multiple disks.  EFI also supports
> > things like network boot, which has a different syntax EFI entry.  The
> > efibootmgr command does a lot of the hard work of figuring that out
> > for you, so you don't need to manually enter that information.
> > 
> You seem knowledgeable, so I'll ask you.  How does the efi firmware
> decide which /boot/efi to use as the source when the computer is
> started?  Does it have to be selected from the efi firmware menu at
> each boot?
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Kevin Becker]

My system has two efi boot partitions on separate drives.  I rarely
boot to Windows and I wanted it on its own completely separate
drive.  I configured a default in the firmware settings and then for a
while I would choose an alternate when I needed to by hitting a key to
bring up the efi boot menu.  Eventually I got around to adding a boot
entry for my second (WIndows) drive to grub on the main drive and now I
can just select Windows from grub if I need to boot into it.

On Mon, 2020-06-01 at 20:13 +0200, Patrick Dupre wrote:
>  Hello,
>  I guess that very think is more or less, OK, I have just some
>  difficultiesto understand the logic.
>  > How does the efi firmware decide which /boot/efi to use as the
>  > source when the computer is started
>  
>  I realized that I have only one EFI System Partition on sdaBy
>  default, the system goes to grub, where I can choose the OS.I do not
>  use the efi options to go there (at least intentionally).
>  > Does it have to be selected from the efi firmware menu at each
>  > boot?
>  I do not think so. As I said, I go directly to the grub menu (by
>  default).I guess that if I active the efi menu, I could choose other
>  options to boot.
>  
>  =====================================================================
>  ====== Patrick DUPRÉ                                 | | email: 
>  pdupre(a)gmx.com
>   Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain
>  Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33
>  (0)380395988=========================================================
>  ==================
>  
>  > On Mon, 1 Jun 2020 10:10:41 -0400Jonathan Billings <
>  > billings(a)negate.org&gt; wrote:
>  > > If you see in the Fedora entry, it has:HD(3,GPT,a5c3bc11-e83b-
>  > > 48d0-be96-
>  > > 783af37228f1,0x2001800\,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
>  > > That means to look for a volume with the 3rd GPT partition, with
>  > > theUUID of a5c3bc11-e83b-48d0-be96-783af37228f1 (and some other
>  > > data).On that disk, look for the /EFI/FEDORA/GRUBX64.EFI
>  > > executable(remember, this is a DOS filesystem so it's case-
>  > > insensitive).
>  > > Run 'blkid' on a running system, and you'll see that the PARTUUID
>  > > ofthe EFI volume matches the UUID in the above EFI entry.
>  > > You can have an EFI volume on multiple disks.  EFI also
>  > > supportsthings like network boot, which has a different syntax
>  > > EFI entry.  Theefibootmgr command does a lot of the hard work of
>  > > figuring that outfor you, so you don't need to manually enter
>  > > that information.
>  > You seem knowledgeable, so I'll ask you.  How does the efi
>  > firmwaredecide which /boot/efi to use as the source when the
>  > computer isstarted?  Does it have to be selected from the efi
>  > firmware menu ateach
>  > boot?_______________________________________________users mailing
>  > list -- users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct: 
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: 
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives: 
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > 
>  _______________________________________________users mailing list -- 
>  users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]

[stan]

On Mon, 01 Jun 2020 14:28:46 -0400
Kevin Becker <kevin(a)kevinbecker.org&gt; wrote:

>  My system has two efi boot partitions on separate drives.  I rarely
>  boot to Windows and I wanted it on its own completely separate
>  drive.  I configured a default in the firmware settings and then for a
>  while I would choose an alternate when I needed to by hitting a key to
>  bring up the efi boot menu.  Eventually I got around to adding a boot
>  entry for my second (WIndows) drive to grub on the main drive and now
>  I can just select Windows from grub if I need to boot into it. 
Thanks, that's how I thought it would work.

[Stephen Morris]

On 2/6/20 3:44 am, stan via users wrote:
>  On Mon, 1 Jun 2020 15:23:26 +0200
>  "Patrick Dupre" <pdupre(a)gmx.com&gt; wrote:
>
> > Thanks,
> >
> > Actually, I am lost.
> > I am upgrading one of the systems on a multi-disks system.
> > 1) I realized that one system is not efi, while the other ones are.
> > 2) After I upgraded this system. I can boot it, but it is weird.
> > a) There was no update of the grub menu (I boot fc32, while the
> > invitation is still fc30)
> > b) grub2-mkconfig has not been run
> > c) grub2-mkconfig (manually) did not recognized by the booted system
> > except through set root='hd2,msdos3', but no menuentry for this
> > system.
>  I've exhausted my knowledge.  I'll make some suggestions, but no
>  guarantees.
>
>  Check /etc/default/grub on the F32 system, and make sure that all the
>  entries are correct for the F32 system.  It needs to have
>  GRUB_ENABLE_BLSCFG=true
>  somewhere in there so that boot loader snippets will work. 
GRUB_ENABLE_BLSCFG=true
is in /etc/default/grub by default to use the 
new BLS boot loader standard, which as I understand it if this is active 
then grub menus are not used, hence /boot/efi/EFI/fedora/grub.cfg would 
never be updated on new kernel installs, as again as I understand it BLS 
writes the boot loader rather than it being written by grub. I don't 
like the menu display created by BLS as it is the same as the menus 
created by grubby, which I also hated. Consequently I have 
GRUB_ENABLE_BLSCFG=false in /etc/default/grub and I manually issue the 
command grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg so that I get 
the boot menu structure that I want.

regards,
Steve
>  Look in /boot/loader/entries/ on the F32 system, and make sure that
>  there is an entry for each of the F32 kernels that you have installed.
>
>  Go into /boot/efi/EFI/fedora/ and run
>  grub2-mkconfig -o grub.cfg
>
>  A reboot should now show F32 as a viable boot option, and as the
>  default.
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Stephen Morris]

On 2/6/20 12:10 am, Jonathan Billings wrote:
>  On Mon, Jun 01, 2020 at 11:20:31AM +0200, Patrick Dupre wrote:
> > with the -v option, I have
> > BootCurrent: 0000
> > Timeout: 1 seconds
> > BootOrder: 0000,0002,0001
> > Boot0000*
> fedora	HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI)
> > [...]
> > However, I do not understand how does this work with multi disks.
> > We have
> > /boot/efi/EFI/fedora/grubx64.efi
> > on each disk ?
> > Which does not seem to be the case.
>  If you see in the Fedora entry, it has:
>  HD(3,GPT,a5c3bc11-e83b-48d0-be96-783af37228f1,0x2001800\
>  ,0xfa000)/File(\EFI\FEDORA\GRUBX64.EFI) 
I am confused by this process as well. If I
issue the command efibootmgr 
-v I get the following output, and, I don't understand how that 
information relates to the segmented disk image that is being used when 
Fedora is run from a virtualbox vm running under windows, and in 
particular when I am booting Fedora via grub.

efibootmgr -v
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0000,0001,0003,0004
Boot0000* UiApp 
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB0-01f003f6 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,0,0)N.....YM....R,Y.
Boot0003* UEFI VBOX HARDDISK VB86498f1a-4c6a0da4 
PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0004* EFI Internal Shell 
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0005* Fedora 
HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)

regards,
Steve
>  That means to look for a volume with the 3rd GPT partition, with the
>  UUID of a5c3bc11-e83b-48d0-be96-783af37228f1 (and some other data).
>  On that disk, look for the /EFI/FEDORA/GRUBX64.EFI executable
>  (remember, this is a DOS filesystem so it's case-insensitive).
>
>  Run 'blkid' on a running system, and you'll see that the PARTUUID of
>  the EFI volume matches the UUID in the above EFI entry.
>
>  You can have an EFI volume on multiple disks.  EFI also supports
>  things like network boot, which has a different syntax EFI entry.  The
>  efibootmgr command does a lot of the hard work of figuring that out
>  for you, so you don't need to manually enter that information.
>

[Samuel Sieb]

On 6/1/20 4:05 PM, Stephen Morris wrote:
>  On 2/6/20 3:44 am, stan via users wrote:
> > Check /etc/default/grub on the F32 system, and make sure that all the
> > entries are correct for the F32 system.  It needs to have
> > GRUB_ENABLE_BLSCFG=true
> > somewhere in there so that boot loader snippets will work. 
>  GRUB_ENABLE_BLSCFG=true is in /etc/default/grub by default to use the
>
>  new BLS boot loader standard, which as I understand it if this is active 
>  then grub menus are not used, hence /boot/efi/EFI/fedora/grub.cfg would 
>  never be updated on new kernel installs, as again as I understand it BLS 
>  writes the boot loader rather than it being written by grub. I don't 
>  like the menu display created by BLS as it is the same as the menus 
>  created by grubby, which I also hated. Consequently I have 
>  GRUB_ENABLE_BLSCFG=false in /etc/default/grub and I manually issue the 
>  command grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg so that I get 
>  the boot menu structure that I want. 
That's not quite correct.  The base grub.cfg file isn't updated because 
it is configured to load the boot loader snippets and use those.  The 
grub menu shows the entries from those files.  A kernel update only adds 
and removes snippet files.  I don't know what template is used to 
generate the titles in those files or maybe it's hardcoded somewhere.

[Samuel Sieb]

On 6/1/20 4:10 PM, Stephen Morris wrote:
>  I am confused by this process as well. If I issue the command
> efibootmgr 
>  -v I get the following output, and, I don't understand how that 
>  information relates to the segmented disk image that is being used when 
>  Fedora is run from a virtualbox vm running under windows, and in 
>  particular when I am booting Fedora via grub. 
What part of it do you not understand?

>  efibootmgr -v
>  BootCurrent: 0005 
This is the entry you're currently running.

>  Timeout: 0 seconds
>  BootOrder: 0005,0000,0001,0003,0004 
This is the order that the entries will be tried in.

>  Boot0005* Fedora 
>
> HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)
>  
I don't know the all the specific details, but this entry describes how 
to load the grub bootloader to start Fedora:
"HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)" 
identifies the hard drive and EFI partition to use.
"File(\EFI\fedora\shimx64.efi)" gives the path to the executable file on 
that partition to load and run.

[Stephen Morris]

On 2/6/20 10:38 am, Samuel Sieb wrote:
>  On 6/1/20 4:10 PM, Stephen Morris wrote:
> > I am confused by this process as well. If I issue the command 
> > efibootmgr -v I get the following output, and, I don't understand how 
> > that information relates to the segmented disk image that is being 
> > used when Fedora is run from a virtualbox vm running under windows, 
> > and in particular when I am booting Fedora via grub.
>
>  What part of it do you not understand?
>
> > efibootmgr -v
> > BootCurrent: 0005
>
>  This is the entry you're currently running.
>
> > Timeout: 0 seconds
> > BootOrder: 0005,0000,0001,0003,0004
>
>  This is the order that the entries will be tried in.
>
> > Boot0005* Fedora 
> >
> HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)
>
>
>
>  I don't know the all the specific details, but this entry describes 
>  how to load the grub bootloader to start Fedora:
>  "HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)" 
>  identifies the hard drive and EFI partition to use.
>  "File(\EFI\fedora\shimx64.efi)" gives the path to the executable file 
>  on that partition to load and run. 
I understand this is the entry that is being
booted from, but I don't 
understand why it is that entry rather than boot0003, which looks to be 
the vm disk partition, when I am running fedora within a vm. I don't 
understand how this relates to the segmented disk image that virtualbox 
is using for fedora, as it is not a physical partition as far as I am 
aware. Virtualbox may make it look like a partition but I'm not up on 
the internal workings of virtualbox.

regards,
Steve

>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]

[Jonathan Billings]

On Tue, Jun 02, 2020 at 07:31:33PM +1000, Stephen Morris wrote:
>  I understand this is the entry that is being booted from, but I
> don't
>  understand why it is that entry rather than boot0003, which looks to be the
>  vm disk partition, when I am running fedora within a vm. I don't understand
>  how this relates to the segmented disk image that virtualbox is using for
>  fedora, as it is not a physical partition as far as I am aware. Virtualbox
>  may make it look like a partition but I'm not up on the internal workings of
>  virtualbox. 

From the earlier message:

On Mon, Jun 01, 2020 at 05:38:00PM -0700, Samuel Sieb wrote:
>  On 6/1/20 4:10 PM, Stephen Morris wrote:
>  > Timeout: 0 seconds
>  > BootOrder: 0005,0000,0001,0003,0004
>  
>  This is the order that the entries will be tried in. 
That's why it uses the Boot0005 before Boot0003 boot entry.  The order
is already defined.

The UEFI VBOX HARDDISK entries are most likely the VBox UEFI
implementation's entries to boot via the Compatibility Support Module
(CSM), which is the legacy BIOS boot method.

-- 
Jonathan Billings <billings(a)negate.org&gt;

[Samuel Sieb]

On 6/2/20 2:31 AM, Stephen Morris wrote:
>  On 2/6/20 10:38 am, Samuel Sieb wrote:
> > I don't know the all the specific details, but this entry describes 
> > how to load the grub bootloader to start Fedora:
> > "HD(1,GPT,5a166b43-c099-429b-9587-4cc29389e1cf,0x800,0x12c000)" 
> > identifies the hard drive and EFI partition to use.
> > "File(\EFI\fedora\shimx64.efi)" gives the path to the executable file 
> > on that partition to load and run.
>  I understand this is the entry that is being booted from, but I don't 
>  understand why it is that entry rather than boot0003, which looks to be 
>  the vm disk partition, when I am running fedora within a vm. I don't 
>  understand how this relates to the segmented disk image that virtualbox 
>  is using for fedora, as it is not a physical partition as far as I am 
>  aware. Virtualbox may make it look like a partition but I'm not up on 
>  the internal workings of virtualbox. 
Boot0003* UEFI VBOX HARDDISK VB86498f1a-4c6a0da4 
PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.

That is the usual UEFI fallback entry to look for an EFI partition on 
the disk and try to load the default boot loader file which I believe is 
"/EFI/BOOT/BOOTX64.EFI".  On a Fedora install, it will create that file 
as well, but if you boot it you will see a message about fixing the boot 
entry because it assumes the Fedora entry didn't work.