Bug 18770 - [6sta1] grub2-install fails on GPT HDD when OS & BIOS boot part are another GPT disk (!UEFI case)
Summary: [6sta1] grub2-install fails on GPT HDD when OS & BIOS boot part are another G...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: release_blocker normal
Target Milestone: Mageia 6
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: 6sta1, NEEDINFO, PATCH
Depends on:
Blocks: 416
  Show dependency treegraph
 
Reported: 2016-06-23 10:14 CEST by Ben McMonagle
Modified: 2016-12-22 15:08 CET (History)
6 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
"Use Existing Partitions" install report (172.51 KB, application/x-xz)
2016-06-23 10:15 CEST, Ben McMonagle
Details
"custom disk partitioning" install report (166.98 KB, application/x-xz)
2016-06-23 10:24 CEST, Ben McMonagle
Details
filter GPT disks w/o a BIOS boot part (mga#18770) (1.35 KB, patch)
2016-06-23 19:04 CEST, Thierry Vignaud
Details | Diff

Description Ben McMonagle 2016-06-23 10:14:22 CEST
Description of problem:Installing i586 grub2 bootloader  to UEFI GPT HDD that has /boot/EFI partition fails with: 
Error: 
An error occurred.
grub2-install failed: installing for 1386-pc platform.
grub2 install: warning: this GPT Partition label contains no BIOS Boot Partition:
embedding won't be possible.
grub2 install: error: embedding not possible, but this is required for cross-disk install.
.... propagated.

(Installation of system was to GPT HDD (not-UEFI booted) and bootloader attempt was to UEFI GPT with /boot/EFI partition
Attempts, "Custom disk partitioning", and "use exiting Partitions") 


Version-Release number of selected component (if applicable):
Mageia-6-sta1-i586-DVD.iso
DATE.txt: Mon Jun 20 23:38:16 CEST 2016


How reproducible:every time


Steps to Reproduce:
1.
2.
3.
Ben McMonagle 2016-06-23 10:14:42 CEST

Keywords: (none) => 6sta1

Comment 1 Ben McMonagle 2016-06-23 10:15:42 CEST
Created attachment 8054 [details]
"Use Existing Partitions" install report
Comment 2 Ben McMonagle 2016-06-23 10:24:24 CEST
Created attachment 8055 [details]
"custom disk partitioning" install report
Comment 3 Thierry Vignaud 2016-06-23 11:48:59 CEST
Humm, you installed a 32bit EFI system but we didn't selected grub2-efi...

CC: (none) => thierry.vignaud
Blocks: (none) => 416

Comment 4 Thierry Vignaud 2016-06-23 11:53:23 CEST
Are you sure you didn't boot in !UEFI mode?
b/c it should be visible in dmesg else...

Keywords: (none) => NEEDINFO

Comment 5 Thierry Vignaud 2016-06-23 15:19:36 CEST
Indeed you did as logs show "defaulting to grub" which is shown when not under UEFI.
See http://gitweb.mageia.org/software/drakx/tree/perl-install/install/any.pm?id=2f3a58e4d6f0cc9b7dd23e4f6af3973389c5d3b4#n797

Thus in custom mode, you must add a "BIOS boot partition" (which is different from an ESP)

But we shouldn't have let you go out of partitioning step without one
Comment 6 Thierry Vignaud 2016-06-23 16:10:55 CEST
Indeed you did as logs show "defaulting to grub" which is shown when not under UEFI.
See http://gitweb.mageia.org/software/drakx/tree/perl-install/install/any.pm?id=2f3a58e4d6f0cc9b7dd23e4f6af3973389c5d3b4#n797

So you have:
- sd[acf]: mbr
- sdb: gpt with ESP
- sde: gpt with BIOS boot partition & the OS you were installing
  (it holds the / fs, including /boot)

So we let you go out of partitioning step as you've a BIOS boot partition on the GPT disk holding the OS.

The thing is, on a multi-disk system, we don't know at partitioning step which disk will hold the boot-loader.

You eventually choose to install grub2 on /dev/sda, which doesn't hold the neither / nor /boot content.
As it's MBR partitioned, grub2 didn't complained.

However you tried another disk before, which failed.
I guess you tried /dev/sdb b/c of that:
"* fs::get::device2part: unknown device <</dev/sdb>>"

As /dev/sdb is GPT but doesn't have a BIOS boot partition, grub2-install rightly complained as there's no room.
See: https://en.wikipedia.org/wiki/BIOS_boot_partition

@Ben: Can you confirm that you tried first to install grub2 on /dev/sdb (because it has a EFI System Partition but grub2 does't care about it as you were not running in UEFI mode)?

I guess that we should filter out the disk list where to install the bootloader when using grub2:
- UEFI: all disks are OK
  note to myself: actually we should grey/disable the list in UEFI case
  as we don't actually pass the device to grub2-install who just look
  for the ESP
- !UEFI:
  o all MBR disk are OK
  o only GPT diskq with a BIOS boot partition are OK (ESP are ignored)
    => here we should have filter out /dev/sdb.

So that we forbid to install grub2 on GPT disks w/o a BIOS boot part
@Barry: do you agree?

Status: NEW => ASSIGNED
CC: (none) => zen25000
Assignee: bugsquad => thierry.vignaud
Summary: [6sta1] Installing i586 grub2 bootloader to UEFI GPT HDD that has /boot/EFI partition fails => [6sta1] Installing i586 grub2 bootloader to UEFI GPT HDD that has /boot/EFI partition fails

Thierry Vignaud 2016-06-23 16:17:51 CEST

Priority: Normal => release_blocker

Thierry Vignaud 2016-06-23 16:28:27 CEST

Summary: [6sta1] Installing i586 grub2 bootloader to UEFI GPT HDD that has /boot/EFI partition fails => [6sta1] grub2-install fails on GPT HDD when OS & BIOS boot part are another GPT disk (!UEFI case)

Thierry Vignaud 2016-06-23 16:28:44 CEST

Target Milestone: --- => Mageia 6

Comment 7 Barry Jackson 2016-06-23 17:58:28 CEST
Yes that looks good to me.
An excellent diagnosis on your part :)
Comment 8 Thierry Vignaud 2016-06-23 18:28:13 CEST
Yeah the only remaining detail is to actually write the corresponding patch.
I got one.
Do we agree that we only filter the whole disks, not the partitions?
We continue to list all partitions?
That's quite a lot easier to do :-)
Comment 9 Thierry Vignaud 2016-06-23 19:00:01 CEST
BTW I'll simplify my WIP patch as we don't care about usable disks in UEFI mode
Comment 10 Thierry Vignaud 2016-06-23 19:04:01 CEST
Created attachment 8060 [details]
filter GPT disks w/o a BIOS boot part (mga#18770)
Thierry Vignaud 2016-06-23 19:04:15 CEST

Keywords: (none) => PATCH

Comment 11 Barry Jackson 2016-06-23 19:11:17 CEST
(In reply to Thierry Vignaud from comment #6)

> I guess that we should filter out the disk list where to install the
> bootloader when using grub2:
> - UEFI: all disks are OK
>   note to myself: actually we should grey/disable the list in UEFI case
>   as we don't actually pass the device to grub2-install who just look
>   for the ESP

Except for the \ case where we DO currently want to pass something to grub2-install. (BTW I hit no problems with this in the installer on two net-installs)
Although I think this should really be changed to a separate check box "Do not write into MBR/ESP" (for chainloading core.img/efi)

> Do we agree that we only filter the whole disks, not the partitions?
> We continue to list all partitions?
> That's quite a lot easier to do :-)

I don't (other than the above) see a case where a partition should be selected (as it could be with grub legacy). So if a check box for "Don't touch MBR/ESP" was added then we only need devices not partitions to be shown for the PC-BIOS case.
Unless the heat is getting to my brain :\

If it's easier to list all, then as long as it errors out on an invalid selection then it would be OK IMHO.
Comment 12 Thierry Vignaud 2016-06-23 19:18:50 CEST
Listing all disks but GPT w/o a BBP in !UEFI mode and no partitions would be easy (but /boot one)
It could then be replaced by a checkbox but that's a generic screen, so I could not even list the /boot partition and add the checkbox to 2nd screen.
WDYT?
Comment 13 Charles Edwards 2016-06-23 20:24:39 CEST
For Barry in Comment 11

another case

Doing a straight MBR install to a GPT drive.
Contrary to current practice that drive Does Not Require a bios_grub partition.
It needs only be flagged 'legacy_boot'.
grub2 is installed to /dev/sdb1 and systems boots from MBR without issue.
This raises a host of other issue as Mga6 tools think that a chainloader is being used when it is only grub2 being used.

Model: ATA HGST HTS721010A9 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  70.0GB  70.0GB  ext4                  legacy_boot
 2      70.0GB  75.6GB  5582MB  linux-swap(v1)
 3      75.6GB  1000GB  925GB   xfs

CC: (none) => cae

Comment 14 Thierry Vignaud 2016-06-23 21:38:52 CEST
"Doing a straight MBR install to a GPT drive" doesn't mean anything.
Either the disk is has MBR partition table or its GUID partition table (GPT).
What did you do exactly?
Comment 15 Charles Edwards 2016-06-23 22:00:13 CEST
(In reply to Thierry Vignaud from comment #14)
> "Doing a straight MBR install to a GPT drive" doesn't mean anything.
> Either the disk is has MBR partition table or its GUID partition table (GPT).
> What did you do exactly?

MBR Is Not a partition table
The default partition table would be msdos 

On my drive
Partition Table: gpt
The install Was Not run as UEFI but as MBR or if you prefer it was done in legacy-mode.
Grub2 was installed to /dev/sdb1 and boots MBR from /dev/sdb
Comment 16 Barry Jackson 2016-06-23 22:17:29 CEST
I notice that partition 1 starts at 1049kB which probably obviates the need for a BBP as there is enough embedding space. Just guessing.
claire robinson 2016-06-23 22:25:14 CEST

CC: (none) => eeeemail, tmb

Comment 17 Charles Edwards 2016-06-23 22:34:42 CEST
(In reply to Barry Jackson from comment #16)
> I notice that partition 1 starts at 1049kB which probably obviates the need
> for a BBP as there is enough embedding space. Just guessing.


That is correct.
The BBP is only needed if that drive, or the drive to which the bootloader is to be installed is also GPT and boots EFI.
Comment 18 Thierry Vignaud 2016-06-23 22:36:54 CEST
> (In reply to Thierry Vignaud from comment #14)
MBR is not legacy mode.
The MBR contains the partition table.
You can connect a MBR disk to a UEFI machine and you cannect a GPT disk to a BIOS machine. The partitionning scheme is orthogonal to the used firmware.

Anyway we eventually understood each other

(In reply to Barry Jackson from comment #16)
Yeah but that doesn't work for all users.
It only worked here by chance.
We got several reports where it failed on GPT partition table b/c there wasn't enought table.(In reply to Charles Edwards from comment #15)
Comment 19 claire robinson 2016-06-23 23:23:09 CEST
Is this something we should expect to fix for sta1 or just for final?
Comment 20 Charles Edwards 2016-06-23 23:44:07 CEST
(In reply to Thierry Vignaud from comment #18)
> > (In reply to Thierry Vignaud from comment #14)
> MBR is not legacy mode.
> The MBR contains the partition table.
> You can connect a MBR disk to a UEFI machine and you cannect a GPT disk to a
> BIOS machine. The partitionning scheme is orthogonal to the used firmware.
 
I agree to the firmware it is irrelevant but to the installation it is not.
On a UFEI system it can boot both EFI and MBR 
On a BIOS system it can only boot MBR

If you have access to a BIOS system, check the drives on that system and I can guarantee you that at least 1 partition is flagged as boot or 0x80, if not it would be set 0x00 and the system would not bootable.
Comment 21 Mageia Robot 2016-06-24 00:56:51 CEST
commit a13cd7e81288d76d0c6dc8264cae8b76e1f0ff5b
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu Jun 23 16:40:43 2016 +0200

    filter GPT disks w/o a BIOS boot part (mga#18770)
    
    else grub2-install failed with:r
    "this GPT Partition label contains no BIOS Boot Partition:
    embedding won't be possible."
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=a13cd7e81288d76d0c6dc8264cae8b76e1f0ff5b
Comment 22 Thierry Vignaud 2016-06-24 01:09:20 CEST
Base issue fixed

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 23 Mageia Robot 2016-06-24 02:15:43 CEST
commit 5299be0d043982d2e8180d7b56c26331ae57b8e9
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Fri Jun 24 01:38:52 2016 +0200

    add a "Do not touch ESP or MBR" option (mga#18770)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=5299be0d043982d2e8180d7b56c26331ae57b8e9
Comment 24 Barry Jackson 2016-06-24 13:09:09 CEST
Nice!
I tested install to GPT (UEFI) x86_64 using the "Do not touch MBR/ESP" option and all went well with no issues.

My only comment would be that the summary says "Bootloader - None".
Hitting NEXT the dialog then says "Installing Bootloader" which looks a bit odd.

Maybe something like "Local" rather than "None" would be more appropriate?

Also the "Probe Foreign OS" is still there which should be in more plain language IMHO.
Comment 25 Maurice Batey 2016-12-13 14:16:13 CET
> ... add a "Do not touch ESP or MBR" option

In  the excellent https://wiki.mageia.org/en/Grub2-efi_and_Mageia the following statement is made that the installer:

> ... created an entry in the non-volatile RAM on the mother board, this
>  entry is placed first in the boot order and points to:
>            /boot/EFI/EFI/mageia/grubx64.efi. 

  If one does not wish that to be done (e.g. because the boot order has already been set to boot rEFInd) does the 'Do not touch ESP or MBR' option implicitly also inhibit the installer from touching the NVRAM on the mother board, or is a further option to do that then shown?

CC: (none) => maurice

Comment 26 Barry Jackson 2016-12-13 16:18:37 CET
(In reply to Maurice Batey from comment #25)
> > ... add a "Do not touch ESP or MBR" option
> 
> In  the excellent https://wiki.mageia.org/en/Grub2-efi_and_Mageia the
> following statement is made that the installer:
> 
> > ... created an entry in the non-volatile RAM on the mother board, this
> >  entry is placed first in the boot order and points to:
> >            /boot/EFI/EFI/mageia/grubx64.efi. 
> 
>   If one does not wish that to be done (e.g. because the boot order has
> already been set to boot rEFInd) does the 'Do not touch ESP or MBR' option
> implicitly also inhibit the installer from touching the NVRAM on the mother
> board, 

Yes - that option stops the installer from modifying nvram, specifically for the case when you already have a 'master' bootloader like a dedicated grub2 partition that boots into many different OS.

>, or is a
> further option to do that then shown?
>

No, nothing more is needed.

Barry
Comment 27 Maurice Batey 2016-12-13 18:03:57 CET
> ... that option stops the installer from modifying nvram

Many thanks, Barry! 

I needed to ask because it did not seem intuitive to me that "Do not touch MBR/ESP" also infers "Do not touch boot options in NVRAM".

 Also, I found it a  confusing idea to request "Do not touch ESP" when the UEFI installer needs to set /mageia/grub64.efi into the ESP (as "The EFI system partition (ESP) contains the boot loaders or kernel images for all installed operating systems.")
  (As I understand it, NVRAM is not contained in the ESP.)
Comment 28 Barry Jackson 2016-12-14 01:51:01 CET
(In reply to Maurice Batey from comment #27)
> > ... that option stops the installer from modifying nvram
> 
> Many thanks, Barry! 
> 
> I needed to ask because it did not seem intuitive to me that "Do not touch
> MBR/ESP" also infers "Do not touch boot options in NVRAM".
> 

I think it was a case of having to make the option title brief. Maybe it should say "Do not touch MBR, ESP or UEFI NVRAM" (if there is room).

WDYT Thierry?

>  Also, I found it a  confusing idea to request "Do not touch ESP" when the
> UEFI installer needs to set /mageia/grub64.efi into the ESP (as "The EFI
> system partition (ESP) contains the boot loaders or kernel images for all
> installed operating systems.")

Yes normally it would, but this option stops that being set. (It actually sends it to a tmp file rather than a mageia entry as there is no option (yet) in grub2 to not create it.) 

>   (As I understand it, NVRAM is not contained in the ESP.)

Yes it's in hardware on the motherboard.
Comment 29 Maurice Batey 2016-12-14 12:43:14 CET
> Yes normally it would [set /mageia/grub64.efi into the ESP] , but this option > stops that being set. 

Then one can't use the "Do not touch MBR/ESP" option to protect the NVRAM, if also want the /mageia/grub64.efi put into the ESP...

This is what I was afraid off; it means I may not install Mageia-6 at all...

  What is needed is an option to 'Do not touch NVRAM', without the 'Do not touch ESP'.  (No concern about MBR - not used.)

> (It actually sends it to a tmp file rather than a mageia entry as there is no > option (yet) in grub2 to not create it.) 

  Where is the /mageia/grub64.efi 'tmp file' put? (How temporary?)
Comment 30 Barry Jackson 2016-12-14 15:44:46 CET
(In reply to Maurice Batey from comment #29)
> > Yes normally it would [set /mageia/grub64.efi into the ESP] , but this option > stops that being set. 
> 
> Then one can't use the "Do not touch MBR/ESP" option to protect the NVRAM,
> if also want the /mageia/grub64.efi put into the ESP...
> 
> This is what I was afraid off; it means I may not install Mageia-6 at all...
> 
>   What is needed is an option to 'Do not touch NVRAM', without the 'Do not
> touch ESP'.  (No concern about MBR - not used.)
> 
> > (It actually sends it to a tmp file rather than a mageia entry as there is no > option (yet) in grub2 to not create it.) 
> 
>   Where is the /mageia/grub64.efi 'tmp file' put? (How temporary?)

/boot/EFI/EFI/tmp/grubx64.efi

If you want to use it just re-name tmp to mageia6 and then you can do with it as you wish. :)
Comment 31 Maurice Batey 2016-12-14 16:41:03 CET
>  /boot/EFI/EFI/tmp//boot/EFI/EFI/tmp/grubx64.efi

OIC. 
In that case rEFInd should find it and include it in its boot menu, but -yes - it would be better in a /mageia-x directory to aid later identification.

But using the ESP/MBR thing seems a bit hokey, just to obtain a normal install but without disturbing the NVRAM boot array 
  I would guess there will eventually be many who are happy with their NVRAM setup and do not want it disturbed, without the Mageia documentation having to describe how grubx64.efi gets hidden away etc.
Comment 32 Maurice Batey 2016-12-14 17:04:59 CET
E.g. radio buttons?:

   Do not touch:

           o MBR
           o ESP
           o NVRAM
Comment 33 Maurice Batey 2016-12-14 17:24:29 CET
Otherwise, how is someone installing Mageia-6 (and having already set up NVRAM to his/her liking) going to find out how to protect the NVRAM boot array?
Comment 34 Barry Jackson 2016-12-14 19:23:28 CET
Currently we use:
grub2-install --bootloader-id=tmp --no-nvram
when "Do not touch MBR/ESP" is checked.

The background to this is here:
https://bugs.mageia.org/show_bug.cgi?id=15583

If you feel that we should give finer granularity to users by splitting this down to either option or both as you suggest in #32 then maybe it would be better to open another bug report, and assign it to Thierry.

I agree that for cases such as yours it would be a better solution.

Please cc me in the new bug.

Thanks,
Barry
Comment 35 Maurice Batey 2016-12-14 19:41:48 CET
> Currently we use:
> grub2-install --bootloader-id=tmp --no-nvram
> when "Do not touch MBR/ESP" is checked.

For the case of simply 'Do not touch NVRAM', could that instead be e.g.

   grub2-install --bootloader-id=mageia --no-nvram

- assuming "mageia" is the correct replacement for "tmp"?

If so, will raise new bug report along those lines, assuming this one could not
be re-opened.
Comment 36 Maurice Batey 2016-12-14 19:44:21 CET
> assuming this one (or 15583) could not be re-opened.
Comment 37 Barry Jackson 2016-12-14 20:00:23 CET
(In reply to Maurice Batey from comment #35)
> > Currently we use:
> > grub2-install --bootloader-id=tmp --no-nvram
> > when "Do not touch MBR/ESP" is checked.
> 
> For the case of simply 'Do not touch NVRAM', could that instead be e.g.
> 
>    grub2-install --bootloader-id=mageia --no-nvram
> 
> - assuming "mageia" is the correct replacement for "tmp"?

mageia is the default which was the problem in the other bug that I cited above.
This overwrites any existing "mageia" folder, which is why I suggested you rename tmp to "mageia6".

For your case you need an option to only add --no-nvram to the default parameters and by having individual checkboxes your approach should acheive that, with only that checked you would get a default mageia folder in the ESP.

We still would need a "Do not touch ESP" option for other cases though which would use tmp.

> 
> If so, will raise new bug report along those lines, assuming this one could
> not
> be re-opened.

Well it could but it's getting too long and Thierry does not like reading long bugs - a new one that gets straight to the point is best :)

Barry
Comment 38 Maurice Batey 2016-12-14 22:42:31 CET
> Well it could but it's getting too long and Thierry does not like reading long > bugs - a new one that gets straight to the point is best.

  Done: https://bugs.mageia.org/show_bug.cgi?id=19949
Comment 39 Maurice Batey 2016-12-15 12:09:26 CET
>>   Where is the /mageia/grub64.efi 'tmp file' put? (How temporary?)

> /boot/EFI/EFI/tmp/grubx64.efi

Well, that is still in the ESP, which is not what 'Do not touch ESP or MBR' seems to be saying - all very confusing!
   Wnat does the installer do if there is already a EFI/tmp/grubx64,efi?

What it really seems to be saying is: 'Do not touch EFI/mageia or MBR', which would provide clarity.

Another possible confusion is that the user could finish up with a Mageia grubx64.efi in 2 places (EFI /tmp and EFI/mageia), with no outward sign of which version of Mageia the latter is (Mageia-5, 5.1, 6?). 
   Normally the one in EFI/mageia is the latest.
And if e.g. rEFInd is being used, it would find both files - though the user could instruct rEFInd to ignore one or the other via refind.conf.
Comment 40 Barry Jackson 2016-12-15 14:09:20 CET
(In reply to Maurice Batey from comment #39)
> >>   Where is the /mageia/grub64.efi 'tmp file' put? (How temporary?)
> 
> > /boot/EFI/EFI/tmp/grubx64.efi
> 
> Well, that is still in the ESP, which is not what 'Do not touch ESP or MBR'
> seems to be saying - all very confusing!
>    Wnat does the installer do if there is already a EFI/tmp/grubx64,efi?

It would be overwritten

> What it really seems to be saying is: 'Do not touch EFI/mageia or MBR',
> which would provide clarity.

Exactly.

> 
> Another possible confusion is that the user could finish up with a Mageia
> grubx64.efi in 2 places (EFI /tmp and EFI/mageia), with no outward sign of
> which version of Mageia the latter is (Mageia-5, 5.1, 6?).

Who cares? Why would anyone pick tmp.

>    Normally the one in EFI/mageia is the latest.

Exactly - it overwrites the current entry which is why we need the option to avoid that.

> And if e.g. rEFInd is being used, it would find both files - though the user
> could instruct rEFInd to ignore one or the other via refind.conf.

I know nothing about rEFInd as we don't package or support it AFAIK.
Comment 41 Maurice Batey 2016-12-22 14:29:37 CET
>Currently we use:
>grub2-install --bootloader-id=tmp --no-nvram
> when "Do not touch MBR/ESP" is checked.

I've seen  somewhere a report that the MBR/ESP option does not appear, and also that the "grub2-install --bootloader-id=tmp --no-nvram" didn't work.

Is that all working now, please?
Comment 42 Barry Jackson 2016-12-22 15:00:01 CET
I have not seen that.
It does not just "appear", you must enter the bootloader options at the summary and then click on "advanced" to find it.
You will then be warned (twice iirc) that the new system will not be available on reboot until it is added to your own bootloader.
Comment 43 Maurice Batey 2016-12-22 15:08:51 CET
Yes, I know it is under 'Advanced.

I need to avoid trying a Mageia-6.stax install if - in the end - that option does not appear or the "grub2-install --bootloader-id=tmp --no-nvram" is ineffective!

Regards, and a Merry Xmas to you and yours...

Note You need to log in before you can comment on or make changes to this bug.