/EFI/mageia/grubx64.efi: Where does it look for grub.cfg?

[Maurice]

Having installed Mageia-5 on an EFI GPT HP Probook earlier this year,
I would now like to understand how the /EFI/mageia/grubx64.efi it
installed
works (e.g. in the event of an installation that is aborted before the
new installation's /boot directory is completed).

My $64 question is:
Does grubx64.efi depend on finding grub.cfg in /boot/grub2 in the
most recently-installed Mageia's Root directory, or does it directly show
the Grub2 menu and start whichever install is chosen from that menu?

I looked for an answer but found confusion. For example:

"If you're using the grubx64.efi file from Ubuntu, in theory it should be
looking on your Ubuntu /boot/grub directory for its support files."

"grub2-install shouldn't be used on EFI systems. The grub2-efi package
installs a prebaked grubx64.efi on the EFI System partition, which looks
for
grub.cfg on the ESP in /EFI/fedora/
- whereas the grub2-install command creates a custom grubx64.efi,
deletes
the original installed one, and looks for grub.cfg in /boot/grub2/".

Looking in the Probook's /EFI/mageia directory, the only file there is
grubx64.efi (117KiB), implying it will look for grub.cfg in the
most recently-installed /boot/grub2, as there is no grub.cfg in the
/EFI/mageia directory.

[grubx64.efi contains much coded information, but also much clear-text
'error
situation' information. I was unable to detect any Grub2 menu text.]

Could someone throw light on how the Mageia-5 grubx64.efi works, please?

[Maurice]

implying it will look for grub.cfg in the most
recently-installed /boot/grub2

Illumination from:
http://www.rodsbooks.com/efi-bootloaders/grub2.html

"GRUB 2 can be installed in either of two ways, depending on the way in
which the program was compiled:

(1) The GRUB 2 EFI binary (grubx64.efi, typically) can be installed
alone
in its subdirectory of the ESP. This binary will then access additional
support and configuration files on your Linux root (/) or /boot
partition.
This is the method that Ubuntu and OpenSUSE use. [ + Mageia-5...]

(2) The GRUB 2 EFI binary can be installed along with its support
modules
and configuration files on the ESP. Fedora 18 uses this method, and most
manual installation instructions I've found on the Web describe this
method
of configuration.

The first method has been less reliable for me. Splitting the files
required
for basic boot loader operation across two partitions means that the boot
loader will stop working if either partition is damaged or deleted. If
this
happens, the user will be greeted by a grub> prompt — a useful tool for
experts, but a sure way to cause panic among less technically-savvy
users,
including many of those drawn to Ubuntu!
Keeping all files required for boot-time operation on the ESP, by
contrast,
means that the boot loader will continue operating even if you delete
Linux or
suffer serious filesystem damage on Linux. In sum, configuring GRUB 2 as
Ubuntu and OpenSUSE do is shortsighted, in my opinion.

Seems Mageia-5 as well...

I shall have a backup of /EFI/mageia/grubx64.efi before doing any new
install, so can restore with Linux SystemRestoreDisk in case of foul up.

[Bit Twister]

Post by Maurice

implying it will look for grub.cfg in the most
recently-installed /boot/grub2

http://www.rodsbooks.com/efi-bootloaders/grub2.html
"GRUB 2 can be installed in either of two ways, depending on the way in
(1) The GRUB 2 EFI binary (grubx64.efi, typically) can be installed
alone
in its subdirectory of the ESP. This binary will then access additional
support and configuration files on your Linux root (/) or /boot
partition.
This is the method that Ubuntu and OpenSUSE use. [ + Mageia-5...]
(2) The GRUB 2 EFI binary can be installed along with its support
modules
and configuration files on the ESP. Fedora 18 uses this method, and most
manual installation instructions I've found on the Web describe this
method
of configuration.
I shall have a backup of /EFI/mageia/grubx64.efi before doing any new
install, so can restore with Linux SystemRestoreDisk in case of foul up.

Well, if I had to chose between writes to bios hardware over
writes to disk partition, I would go with wearing out the drive
over bios hardware. ~$80 terabyte drive is cheaper than a new
motherboard. :)

It will also depend on usage and your boot design methodology
for mananging what you are doing.

If method 2 is selected I would suggest a mult-Linux/DOZE
has a greater chance of clobbering the boot loader.

More so when use in testing new releases and provides
a poor boot loader testing environment for the typical boot
loader install.

Going with method one allows me to use that particular installs
rescue medium to restore the boot loader.

I have no idea if a distribution kernel update is going to
update your method 2 grub.cfg. :(

[Maurice]

It will also depend on usage and your boot design methodology for
mananging what you are doing.

BT, you seem to have misunderstood 'where I am coming from'!

The EFI directories and files I mentioned were as handled by the Mageia-5
installer entirely (apart from my having to find a way of stopping the
Probook ALWAYS booting Windows 10 regardless of boot settings).
I am not attempting any amateur 'boot design methodology' - just
trying to
understand how /EFI/mageia/grubx64.efi works.

The reason for that is that - having been bitten last year by an
abandoned
install (on MBR non-EFI non-GPT 'real h/w') that scuppered booting
anything -
I was wondering whether the EFI booting would avoid that,. and it appears
that the 2nd option shown in:
http://www.rodsbooks.com/efi-bootloaders/grub2.html
- as with Fedora 18 - would prevent that situation.

But it's clear from all the evidence that the Mageia approach (at least
in
Mageia-5) is the 1st of the two methods shown, and will not shield the
user from the potential booting problem.

So I need to backup /EFI/magiea/grubx64.efi before I attempt a 2nd
install on
the Probook (as I know it starts a Mageia whose /boot directory is in
good
shape).

[Bit Twister]

Post by Maurice

It will also depend on usage and your boot design methodology for
mananging what you are doing.

BT, you seem to have misunderstood 'where I am coming from'!
The EFI directories and files I mentioned were as handled by the Mageia-5
installer entirely (apart from my having to find a way of stopping the
Probook ALWAYS booting Windows 10 regardless of boot settings).
I am not attempting any amateur 'boot design methodology' - just
trying to
understand how /EFI/mageia/grubx64.efi works.

And I was not talking about "any amateur boot design methodology"

You stated the two methodologies and had seemed to declared
you were going with method 2. I just pointed out some of the
drawbacks with number 2.

Post by Maurice
The reason for that is that - having been bitten last year by an
abandoned
install (on MBR non-EFI non-GPT 'real h/w') that scuppered booting
anything -

Heheh, I managed to find more than one way to create that event
since I started playing with grub2.

Post by Maurice
I was wondering whether the EFI booting would avoid that,. and it appears
http://www.rodsbooks.com/efi-bootloaders/grub2.html
- as with Fedora 18 - would prevent that situation.
But it's clear from all the evidence that the Mageia approach (at least
in
Mageia-5) is the 1st of the two methods shown, and will not shield the
user from the potential booting problem.

And again, all you have with method two is a single point of
failure and the maintenance headache of keeping it current
on each new install and/or kernel update on any install.

Post by Maurice
So I need to backup /EFI/magiea/grubx64.efi before I attempt a 2nd
install on
the Probook (as I know it starts a Mageia whose /boot directory is in
good
shape).

I would have thought that was a given regardless of method
chosen.

In my stupid opinion, everyone should have a backup/restore
procedure that has been tested.

Everyone needs to ask themselves, What do I do if the disk drive
fails?

Single system single drive users should get an external usb
drive that matches their system and perform a "Restore" onto
it and verify that the restored drive works.


My methodology is a partition on a second drive used as a hot
backup of the "Production" install. "Produciton" is also the
location of the bootloader configuration files.

All my customization and automated install/changes scripts
are in a /local partition and is copied to three other
systems besides residing in a backup.iso which is also
burned to a dvd.

The install iso is on a usb drive.

[Maurice]

You stated the two methodologies and had seemed to declared you were
going with method 2.

No - I said it seems that Mageia-5 uses Method 1 (access additional
support and configuration files on your Linux root (/) or /boot
partition),
and that http://www.rodsbooks.com/efi-bootloaders/grub2.html argues that
Method 2 was much the better of the two.

I shall be 'going' wherever Mageia takes us (seemingly Method 1),
but I share Rod Smith's conclusion that Method 2 is far superior
(though other aspects - as you point out - should be taken into
consideration).

[Maurice]

Post by Maurice
I said it seems that Mageia-5 uses Method 1

P.S.
I had kidded myself* that /EFI/mageia/grubx64.efi was going to be a much
safer booting mechanism than the old Legacy MBR system - as it should be
for
e.g. Fedora 18's users - so am disappointed to find that it isn't.

(* Yes, it's still possible to be optimistic at 83, but one tends to lose
more
often... ;-)

[dlbendigo]

Post by Maurice

Post by Maurice
I said it seems that Mageia-5 uses Method 1

P.S.
I had kidded myself* that /EFI/mageia/grubx64.efi was going to be a much
safer booting mechanism than the old Legacy MBR system - as it should be
for
e.g. Fedora 18's users - so am disappointed to find that it isn't.
(* Yes, it's still possible to be optimistic at 83, but one tends to lose
more
often... ;-)
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)

Grub.cfg for the current distro is in /boot/grub2.

That points to /boot/EFI which should show up with the
"df" command. If you want to delete a particular setup,
for example, a distro you don't need anymore, you delete
it in /boot/EFI. You could do that with the command line
tool, or with one of the resources Rob mentions.

HTH,

Doug.

[Maurice]

Post by dlbendigo
Grub.cfg for the current distro is in /boot/grub2.
That points to /boot/EFI

My understandung is that it's the other way round, i.e.

/EFI/distro/grubx64.efi points to the Grub.cfg for the most
recently installed distro in the distro's /boot/grub2 ?

[dlbendigo]

Post by Maurice
The reason for that is that - having been bitten last year by an
abandoned
install (on MBR non-EFI non-GPT 'real h/w') that scuppered booting
anything -
I was wondering whether the EFI booting would avoid that,. and it appears
http://www.rodsbooks.com/efi-bootloaders/grub2.html
- as with Fedora 18 - would prevent that situation.

You select the Mageia setup from the alternatives in your "BIOS."
Mine lets me set the sequence that BIOS follows until it finds a
stanza to boot. For example, you can tell the computer to boot
first from
the CD-ROM, then from Mageia. Then Mageia's own boot menu comes up.
If you got an old menu, you must have set the priority incorrectly.

Another trick Grub2 can play: if I try to boot a CD which doesn't
match the
EFI/notEFI choice, I get shunted to the bootloader created by Mint.
--

[dlbendigo]

Post by dlbendigo

Post by Maurice
The reason for that is that - having been bitten last year by an
abandoned
install (on MBR non-EFI non-GPT 'real h/w') that scuppered booting
anything -
I was wondering whether the EFI booting would avoid that,. and it appears
http://www.rodsbooks.com/efi-bootloaders/grub2.html
- as with Fedora 18 - would prevent that situation.

You select the Mageia setup from the alternatives in your "BIOS."
Mine lets me set the sequence that BIOS follows until it finds a
stanza to boot. For example, you can tell the computer to boot
first from
the CD-ROM, then from Mageia. Then Mageia's own boot menu comes up.
If you got an old menu, you must have set the priority incorrectly.
Another trick Grub2 can play: if I try to boot a CD which doesn't
match the
EFI/notEFI choice, I get shunted to the bootloader created by Mint.
--

An afterthought: your unwanted Mageia system may correspond
to my Mint bootloader. Even though it isn't being used, it is still
there. Many distros seem to have ncluded a /boot/efi folder,
even if they can't use EFI. It makes it easier for them to boot
on an EFI computer. If you try to boot anEFI system from a
non-EFI setup, the BIOSmay ignore your choice and go to the
first non-EFI bootloader it finds.

Doug.
--

[Maurice]

You select the Mageia setup from the alternatives in your "BIOS." Mine
lets me set the sequence that BIOS follows until it finds a stanza to
boot.

On my EFI/GPT HP Probook the BIOS ignored any such setting and ALWAYS
booted
Windows(10)!

(Later I found a way of avoiding that.)

[William Unruh]

Post by dlbendigo

Post by Maurice
The reason for that is that - having been bitten last year by an
abandoned
install (on MBR non-EFI non-GPT 'real h/w') that scuppered booting
anything -
I was wondering whether the EFI booting would avoid that,. and it appears
http://www.rodsbooks.com/efi-bootloaders/grub2.html
- as with Fedora 18 - would prevent that situation.

You select the Mageia setup from the alternatives in your "BIOS."
Mine lets me set the sequence that BIOS follows until it finds a
stanza to boot. For example, you can tell the computer to boot
first from
the CD-ROM, then from Mageia. Then Mageia's own boot menu comes up.

I think that is all done in the EFI bios. Ie, first the machine itself
has a "menu" to search for bootable things-- usb, cd, network, hard
disk. At that point grub has absolutely nothing to do with the boot
process. If you choose hard disk, it then goes to the EFI partition on
the hard disk and looks at the various possibilities there, amongst
which is the grub boot for Linux.

Post by dlbendigo
If you got an old menu, you must have set the priority incorrectly.
Another trick Grub2 can play: if I try to boot a CD which doesn't
match the
EFI/notEFI choice, I get shunted to the bootloader created by Mint.

[Maurice]

it then goes to the EFI partition on the hard disk and
looks at the various possibilities there, amongst which is the grub boot
for Linux.

Except that in the case of my HP Probook, it always chose the
default .efi
Windows boot - regardless of any requested boot order - until I found a
way
out of that impasse.