Bug 28428 - Mageia requires ESP Partition on it's install Disk instead of using existing ESP Partition on other Disk
Summary: Mageia requires ESP Partition on it's install Disk instead of using existing ...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: 7
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-24 12:28 CET by Mike Burgener
Modified: 2021-04-06 20:18 CEST (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
report.bug.xz as requested (195.37 KB, application/x-xz)
2021-02-24 20:38 CET, Mike Burgener
Details

Description Mike Burgener 2021-02-24 12:28:30 CET
Dear Mageia Team,

I have many disks in my Machine and i discovered the following issue in Mageia installer.

First in Mageia Installation Mageia requires you to create a ESP Partition on it's own installation disk when partitioning.

Second Mageia Installer does only allow you to select it's own ESP as a target for Grub installation.

As my EFI discovers all ESP Partition, i am still able to Boot Windows and Mageia by selecting the correct EFI Boot device.
Comment 1 Aurelien Oudelet 2021-02-24 17:41:04 CET
Thanks for the bug report.
Could you provide the file /root/drakx/report.bug.xz as an attachment from the latest Mageia installed system.

Keywords: (none) => NEEDINFO
CC: (none) => ouaurelien

Comment 2 Mike Burgener 2021-02-24 20:38:17 CET
Created attachment 12384 [details]
report.bug.xz as requested
Comment 3 Lewis Smith 2021-02-24 21:26:04 CET
More than one ESP - not seen that before! And surprised the EFI firmware copes. Were you hoping that the Mageia installer would use the existing ESP on a different disc? It should, that would be best. Could the bug title be changed to "Mageia EFI installer does not use an existing ESP on a different disc from the installed system" (or similar) ?
Or do you *want* to have >1 ESP?

In any case, can you also supply the output of:
 # gdisk -l /dev/sd...     for both discs with an ESP.
And:
 # efibootmgr -v

CC: (none) => lewyssmith

Comment 4 Martin Whitaker 2021-02-25 01:31:47 CET
The reason the installer is not using your existing ESP is that it has the wrong partition type in the partition table. From the installer log we see

------------------
* fdisk before:
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1CH1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 69430895-20FD-4447-AB6E-1D50EC5AAF2B

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 1423355903 1423353856 678.7G Windows recovery environment
/dev/sda2  1423355904 1424080895     724992   354M Microsoft basic data
/dev/sda3  1911750656 1953523711   41773056  19.9G Microsoft basic data
------------------

Earlier in the log we see that /dev/sda2 has a vfat filesystem labelled "ESP". But the type in the partition table should be "EFI System", not "Microsoft basic data". If you correct that, the installer should find the existing ESP and use it as the default location for the bootloader.

The other partition types on that disk look wrong too. The partitions contain ext4 filesystems, so should have a partition type of "Linux filesystem".

CC: (none) => mageia

Comment 5 Mike Burgener 2021-02-25 10:31:42 CET
(In reply to Martin Whitaker from comment #4)
> The reason the installer is not using your existing ESP is that it has the
> wrong partition type in the partition table. From the installer log we see
> 
> ------------------
> * fdisk before:
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Disk model: ST1000DM003-1CH1
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> Disk identifier: 69430895-20FD-4447-AB6E-1D50EC5AAF2B
> 
> Device          Start        End    Sectors   Size Type
> /dev/sda1        2048 1423355903 1423353856 678.7G Windows recovery
> environment
> /dev/sda2  1423355904 1424080895     724992   354M Microsoft basic data
> /dev/sda3  1911750656 1953523711   41773056  19.9G Microsoft basic data
> ------------------
> 
> Earlier in the log we see that /dev/sda2 has a vfat filesystem labelled
> "ESP". But the type in the partition table should be "EFI System", not
> "Microsoft basic data". If you correct that, the installer should find the
> existing ESP and use it as the default location for the bootloader.

ok thx will try that.

> 
> The other partition types on that disk look wrong too. The partitions
> contain ext4 filesystems, so should have a partition type of "Linux
> filesystem".

Well i am quite an advanced Linux System Engineer and all my Partition-Tools even on Windows show the types correctly hmm maybe we mix something?

Let me create a good overview of all my disks if my time allows in the next days.
Comment 6 Mike Burgener 2021-02-25 11:27:08 CET
(In reply to Lewis Smith from comment #3)
> More than one ESP - not seen that before! And surprised the EFI firmware
> copes. Were you hoping that the Mageia installer would use the existing ESP
> on a different disc? It should, that would be best. Could the bug title be
> changed to "Mageia EFI installer does not use an existing ESP on a different
> disc from the installed system" (or similar) ?
> Or do you *want* to have >1 ESP?

well one feature of EFI is being able to have multiple ESP's :D so both should be supported.

actually imagine you have a Removable Harddrive, EFI makes bootable removable Harddrives really easy for example. You Bios detects the new ESP Partition and provides it as a Boot option and you Bootloader on that ESP should just work (if it uses UUID's etc)

actually i am a fan on best practice/standard conforming implementations ;-) and "our question" is answered in UEFI specs see https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf Section 13.3.3 mostyle the second part.

kind regards

Mike


> 
> In any case, can you also supply the output of:
>  # gdisk -l /dev/sd...     for both discs with an ESP.
> And:
>  # efibootmgr -v
Comment 7 Mike Burgener 2021-02-25 15:01:25 CET
I Fixed /dev/sda partition types, really can't understand how i missed that. however still in "Controlcenter" only 1 EFI Systempartition entry is there and it's still the one on mageia's root disk
Comment 8 Martin Whitaker 2021-02-25 15:17:59 CET
Both the installer and MCC/diskdrake will let you create as many EFI system partitions as you like. The one that is used for installing the bootloader is the one you have chosen to mount at /boot/EFI.

If the installer thinks your target disk is a removable device, it will default to adding/using an ESP on that device. If not, it will default to using the first ESP it finds, or the target disk if no existing ESP is found. If you want to override that choice, select custom partitioning at the partitioning step and set the /boot/EFI mount point to the ESP you want it to use.
Comment 9 Lewis Smith 2021-02-25 20:53:00 CET
Thank you Martin for your intervention. What you describe above is really thorough behaviour by the installer.

(In reply to Mike Burgener from comment #7)
> I Fixed /dev/sda partition types, really can't understand how i missed that.
> however still in "Controlcenter" only 1 EFI Systempartition entry is there
> and it's still the one on mageia's root disk
The 'gdisk' outputs might clarify that. In any case, the partition type for an ESP is EF; the GUID is apparently supposed to be:
 C12A7328-F81F-11D2-BA4B-00A0C93EC93B
though having more than one of those in a system ?

(In reply to Mike Burgener from comment #5)
> Let me create a good overview of all my disks if my time allows in the
> next days
 $ inxi -Dlop
is neat (but does not show partition type codes).
Comment 10 Aurelien Oudelet 2021-03-19 15:25:11 CET
Reporter, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you.

Status: NEW => NEEDINFO
Keywords: NEEDINFO => (none)

Comment 11 Aurelien Oudelet 2021-04-06 20:18:56 CEST
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Resolution: (none) => OLD
Status: NEEDINFO => RESOLVED


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