Created attachment 7947 [details]
install report.bug.xz

Thisis a duplicate of bug 18646, see 

https://bugs.mageia.org/show_bug.cgi?id=18646#c8

"...installer installs grub2 instead of grub2-efi on UEFI hardware."

*** This bug has been marked as a duplicate of bug 18646 ***

Status: NEW => RESOLVED
CC: (none) => marja11
Resolution: (none) => DUPLICATE

(In reply to Marja van Waes from comment #2)
> Thisis a duplicate of bug 18646, see 
> 
> https://bugs.mageia.org/show_bug.cgi?id=18646#c8
> 
> "...installer installs grub2 instead of grub2-efi on UEFI hardware."
> 
> *** This bug has been marked as a duplicate of bug 18646 ***

This is not the same bug.
This bug concerns the bootloader for an MBR drive on system that also has an EFI drive.
Grub2 installation fails if it is done to the MBR section of the EFI drive.

Status: RESOLVED => REOPENED
CC: (none) => cae
Resolution: DUPLICATE => (none)

IIANM this should be closed as invalid as we do not support mixed modes (i.e. UEFI and PC_BIOS systems on the same hardware).

@Ben,
Could you not just unplug the 'other mode' drives while testing, or maybe disable the controllers in BIOS?

You should not use both on the same drive but on separate drives there is no issue.

If it were true no one would have ever have been able to dual boot linux on a system pre-installed with Win newer than 2012 and in some case even earlier as Win 7 also supported UEFI.

Mageia did not support UEFI until Mga5 and I'm know people were dual booting Mga4.

(In reply to Charles Edwards from comment #5)
> 
> Mageia did not support UEFI until Mga5 and I'm know people were dual booting
> Mga4.

Yes I did it and eventually ran into issues. I had my first UEFI instal on an external drive.

I can't recall just what the issues were, but I remember the bug was invalid as I was mixing modes.

I think marja is right BTW, this does also look like a duplicate as bootloader install would fail with that .iso on UEFI and not on PC_BIOS for the reason mentioned.

I have a test system running EFI Mga6 on sda and MBR Mga6 on sdb.
For the MBR install I specifically chose to install grub2 on /dev/sdb and I am having absolutely no issue with either.
The grub2 menu on each contains a working menu entry for the other.

Back to the specifics of this bug.
This grub2 issue is documented by Fedora

https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-installation-gui-manual-partitioning-recommended.html

"You need to create a BIOS Boot partition with a size of 1 MB to install on a system with BIOS firmware if the disk containing the boot loader uses GPT. If the disk uses a MBR, no special partition is necessary on a BIOS system."

I'll make drakx create such a partition if !UEFI + GPT

(In reply to Thierry Vignaud from comment #8)
> I'll make drakx create such a partition if !UEFI + GPT

Will the ability to do this manually be available if Custom partitioning is chosen.

Now drakx is creating those partitions On The Wrong drive.

/dev/sda gpt boots EFI OS already installed.

/dev/sdb msdos will boot MBR when install is done.

During the MBR install used "erase and use entire disk' at partitioning.
It created in order as listed on /dev/sdb
/ 
unknown 1.57MiB
swap
unknown 1.88MiB
/home
unknown 2.49MiB

Those "unknown" partitions are of absolutely no use.
The bios_grub partition HAS to be on the gpt drive /dev/sda

That has nothing to do (no change has been made yet)
Those are not partitions, but gaps (== free space) between partitions

(In reply to Charles Edwards from comment #7)

> 
> https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-
> installation-gui-manual-partitioning-recommended.html
> 
> "You need to create a BIOS Boot partition with a size of 1 MB to install on
> a system with BIOS firmware if the disk containing the boot loader uses GPT.
> If the disk uses a MBR, no special partition is necessary on a BIOS system."

(In reply to Thierry Vignaud from comment #8)
> I'll make drakx create such a partition if !UEFI + GPT

Leaving this bug report open for that, then

Assignee: bugsquad => thierry.vignaud
Summary: [6sta1] i586 Grub2 installation does not like dual boot with UEFI GPT partitioned HDD => [6sta1] In non-EFI mode: Let installer create a BIOS boot partition if the bootloader needs to be written to a GPT disk
Source RPM: grub2 => drakx-installer-stage2

Some patches are in progress

Priority: Normal => release_blocker
Status: REOPENED => ASSIGNED
Hardware: i586 => All
Severity: normal => major

I ran a couple of test yesterday and was successfull when EFI had
already been installed.

/dev/sda  contains EFI installed Mga6
/dev/sdb  contains MBR Mga6 (1 test with already installed, 2nd test
new MBR install)

Boot a live OS that includes gparted.
Using gparted shrink swap partition on sda 2MiB
Use that space to create a 2Mib partition with File System type
"cleared"
Apply the changes.
Use "Manage Flag" heading to set that partition as "grub_bios"
Reboot.

Grub2 from MBR install on sdb can now be installed to sda.


I am not suggesting or recommending that anyone else try this, just
advising that it can be done.

(In reply to Charles Edwards from comment #14)
> I ran a couple of test yesterday and was successfull when EFI had
> already been installed.
> 
> /dev/sda  contains EFI installed Mga6
> /dev/sdb  contains MBR Mga6 (1 test with already installed, 2nd test
> new MBR install)
> 
> Boot a live OS that includes gparted.
> Using gparted shrink swap partition on sda 2MiB
> Use that space to create a 2Mib partition with File System type
> "cleared"
> Apply the changes.
> Use "Manage Flag" heading to set that partition as "grub_bios"
> Reboot.
> 
> Grub2 from MBR install on sdb can now be installed to sda.
> 
> 
> I am not suggesting or recommending that anyone else try this, just
> advising that it can be done.

Is it possible to do the above, using the installer partitioning tool?

commit 83565d0739e5746ea02c210106a2d1f1d1477eda
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed Jun 8 22:48:20 2016 +0200

    detect GRUB_BIOS partitions (mga#18656)
    
    let's abuse ->{pt_type} for tracking such partitions
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=83565d0739e5746ea02c210106a2d1f1d1477eda

commit 1b96be96d399303bcfa8d0f6c4920880848dac77
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu Jun 9 11:57:55 2016 +0200

    add a GRUB_BIOS partitions if needed (mga#18656)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=1b96be96d399303bcfa8d0f6c4920880848dac77

commit 6d63b86ea5942fe3450f6fe4d1e6ae5287fe9e5c
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Sat Jun 11 07:57:16 2016 +0200

    update suggestions if needed after erasing disk
    
    this is incomplete: we need to reread $all_hds else we won't add a Boot
    BIOS partition to suggestions if there was already one _prior_ to erase
    the full disk (mga#18656) ...
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=6d63b86ea5942fe3450f6fe4d1e6ae5287fe9e5c

OK basic support is here but for the bug where we won't create a Boot BIOS partition when erasing the disk and there was already one.
It should be fixed in next release

URL: (none) => https://en.wikipedia.org/wiki/BIOS_boot_partition

Just now attempted a network install.
Custom partitioning kept complaining about no BIOS_GRUB partition and I could not format it. Partition is there before attempting install. Used gparted to create it format 'cleared' with Flags bios_grub before attempting install.
Bios configured as legacy boot. No *EFI anything.


Could someone tell me what is being tested to prove I have one?


Ignore my partition label spelling.


# gdisk -l /dev/sda 
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB

Number  Start (sector)    End (sector)  Size       Code  Name
              <snip>
  10      1309157376      1319467007   4.9 GiB     EF02  grub_bios

$  blkid | grep sda10
/dev/sda10: PARTLABEL="grub_bios" PARTUUID="7a9489b7-4e7a-49e2-b304-cc5bd9fb66e8"

CC: (none) => bittwister2

(In reply to Bit Twister from comment #20)
> Just now attempted a network install.
> Custom partitioning kept complaining about no BIOS_GRUB partition and I
> could not format it. Partition is there before attempting install. Used
> gparted to create it format 'cleared' with Flags bios_grub before attempting
> install.
> Bios configured as legacy boot. No *EFI anything.
> 
> 
> Could someone tell me what is being tested to prove I have one?
> 
> 
> Ignore my partition label spelling.
> 
> 
> # gdisk -l /dev/sda 
> GPT fdisk (gdisk) version 1.0.1
> 
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: present
> 
> Found valid GPT with protective MBR; using GPT.
> Disk /dev/sda: 1953525168 sectors, 931.5 GiB
> 
> Number  Start (sector)    End (sector)  Size       Code  Name
>               <snip>
>   10      1309157376      1319467007   4.9 GiB     EF02  grub_bios
> 
> $  blkid | grep sda10
> /dev/sda10: PARTLABEL="grub_bios"
> PARTUUID="7a9489b7-4e7a-49e2-b304-cc5bd9fb66e8"


No grub_bios partition is needed for your case.
You should be able to do a standard MBR install, needing only / swap and /home partitions which boots MBR from /dev/sda

grub_bios in only needed on multi drive systems where is EFI is also used.

Example:

Existing /dev/sda boots EFI
New /dev/sdb wants to MBR from /dev/sda
This can only be done if there is a grub_bios partition on present on /dev/sda
otherwise MBR bootloader for sdb install can only be installed to /dev/sdb.

(In reply to Charles Edwards from comment #21)

> 
> No grub_bios partition is needed for your case.
> You should be able to do a standard MBR install, needing only / swap and
> /home partitions which boots MBR from /dev/sda
> 
> grub_bios in only needed on multi drive systems where is EFI is also used.

What can I say. I am in a "install" mode, not update, in the custom partition screen, went through and set labels for my usual partitions, click Done and I get the require BIOS_GRUB error message window. Clicking my bios_grub partition, can not format it, it also complained it was mandatory to create a mount point for it.

Only way I could install/use grub2 on my current cauldron install was to create the bios_grub partition.

So, legacy bios users doing a clean install are not going to get very far with the current logic.

(In reply to Bit Twister from comment #22)
 
> Only way I could install/use grub2 on my current cauldron install was to
> create the bios_grub partition.
> 
> So, legacy bios users doing a clean install are not going to get very far
> with the current logic.

You are not doing a legacy bios install, that implies MBR install to a msdos drive.
You are doing an MBR install to a gpt disk.
But that is beside the point.


There are several open bugs that Thierry is trying resolve by making changes in
the installer.
These changes Have to be tested to ensure they work as entended, that they do not cause regressions, and that they do got cause New bugs.
That's why there are idiots like me doing numerous installs every day.
Part of the time the drive has not even cooled down before I'm starting the next
install.

You did your install most likely using stage2-17.36.
I can guarantee you that the installer will be updated several more times before
Mga6 ever becomes final.

(In reply to Charles Edwards from comment #23)
 
> You are not doing a legacy bios install, that implies MBR install to a msdos
> drive.

What I am saying is bios is set to Legacy boot and the install is on a GPT disk and those users will have a problem.

> You are doing an MBR install to a gpt disk.
> But that is beside the point.
> 
> 
> There are several open bugs that Thierry is trying resolve by making changes
> in
> the installer.

Yes I know and my install was using drakx-installer-stage2-17.36-1.mga6

My guess for my install is the custom partition logic should look for a bios_grub partition and if it is 'cleared' then there is no requirement for a mount point. If formatted, then a mount point is required.

If not Custom install the code might need to ask if it will be a efi or legacy boot.

I did go back and formatted it vfat23 and still could not get through the custom setup. Partition was not large enough for vfat.

BIOS boot partition must never be formatted: it'll never contains a fs!!!
This is just a space place holder for bootloaders so store their stage1

(In reply to Bit Twister from comment #24)
> 
> My guess for my install is the custom partition logic should look for a
> bios_grub partition and if it is 'cleared' then there is no requirement for
> a mount point. If formatted, then a mount point is required.

Ah, after a little more research Code of EF02 identifies partition is bios_grub and logic should skip mount point requirement. If Code is EF00 then the mount point is required.

gparted sets  PARTUUID="7a9489b7-4e7a-49e2-b304-cc5bd9fb66e8" when bios_grub flag is selected/set.

commit bba05ad41f791e93a8bd588e91dca68748c4ee81
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Sun Jun 12 10:22:28 2016 +0200

    fix partition type test
    
    thus guessing better if we need a GRUB_BIOS partition (mga#18656)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=bba05ad41f791e93a8bd588e91dca68748c4ee81

commit 0f01aefe04cef0d8efe8728d3b3b87484ddf3075
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Sun Jun 12 11:10:25 2016 +0200

    fix offering to create a GRUB_BIOS partition
    
    ...in custom mode (mga#18656)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=0f01aefe04cef0d8efe8728d3b3b87484ddf3075

Elegant work being done here.  Thanks Thierry and all contributing.
Tony

CC: (none) => tablackwell

commit 3eba5ff412ca1b693dfa4cef5cf63d5a775a35c8
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu Jun 16 15:27:34 2016 +0200

    fix inverted test (mga#18656, mga#18704)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=3eba5ff412ca1b693dfa4cef5cf63d5a775a35c8

 Bug links:
   Mageia
      https://bugs.mageia.org/18656
      https://bugs.mageia.org/18704

Fixed

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

I am fine with this fix for now but the actual bug is still present as the installer neither creates nor does it provide a means for the user to create the needed bios_grub partition.

That partition needs to be manually created, as I outlined in Comment 14, and then the Mga6 install run for it to complete.

Will leave the bug as resolved until after Mga6 goes live and cauldron reopens.

comment #14 was about a drakx version that didn't known about such partitions.
Current installer creates such a partition (_if_ *needed*)

I just did a test install and it DID NOT create the partiton!

During the partitioning stage there was only a pop-up that a Grub Bios partition was needed.
No offer to make one was made nor is that option available using advanced partitioning. 

I manually created the partition using gparted, ran the Mga6 install again and it sailed through to completion.

Please do not comment over multiple bug reports.
Open a _new_ one and attach your /root/drakx/report.bug.xz or use a usb key and the "bug" command in the installer

*** Bug 16849 has been marked as a duplicate of this bug. ***

CC: (none) => grio

*** Bug 21354 has been marked as a duplicate of this bug. ***

CC: (none) => rod

Marja, do I take it that there is no fix, or work-around, for installs of Mga5? Apart from, as I did, add an old HDD to boot from. I tried adding a boot partition, to a GPT disk, but the failure to boot still persists. I think that the get-around I shall use this time, is to leave the install disk in the DVD drive, and use the option "boot from hard drive" to start the boot!

(In reply to Rod Goslin from comment #38)
> Marja, do I take it that there is no fix, or work-around, for installs of
> Mga5? 

There's no fix, but there is Charles Edwards' work-around in comment #14 above.

If that doesn't work for you, then please attach your installer logs to bug #21354
(see the links in bug #21354, comment #9 for instructions on how to get the logs) and change the status of that bug report from RESOLVED - DUPLICATE to REOPENED.

Marja, my apologies for the tardy nature of replying to your note. Charleles's work-around is rather out of my range of expertise, I'm afraid. Particularly as it's a try-this only. I reasonably elegant solution did occur to me, as a work round. Since the install disk can successfully boot the system, it should be possible, particularly since the appropriate menu is right at the start of the build, to take out the appropriate software, amend the opening menu to present only the one option, to boot from the hard drive, and copy this to a usb thumb drive, parked somewhere on the machine. It should act as the installer disk, but carry out the single option, to boot from the machines hard drive. A quick look at the disk's file structure, so far, has led my nowhere.

Rod

(In reply to Rod Goslin from comment #40)
> Marja, my apologies for the tardy nature of replying to your note.
> Charleles's work-around is rather out of my range of expertise, I'm afraid.
> Particularly as it's a try-this only. I reasonably elegant solution did
> occur to me, as a work round. Since the install disk can successfully boot
> the system, it should be possible, particularly since the appropriate menu
> is right at the start of the build, to take out the appropriate software,
> amend the opening menu to present only the one option, to boot from the hard
> drive, and copy this to a usb thumb drive, parked somewhere on the machine.
> It should act as the installer disk, but carry out the single option, to
> boot from the machines hard drive. A quick look at the disk's file
> structure, so far, has led my nowhere.
> 
> Rod

Rod, if you would like to contact me directly (off list) I would be happy to walk you through the steps needed to manually create the BIOS_GRUB partition.

   Charles