GPT errors during install

I am trying to install Fedora 40 on my computer, but am getting the message that a 1M bios_grub partition needs to be created using GPT.

I have checked my current environment (I have several versions of Linux already installed, including Fedora 39); parted shows that there already is a 1M bios_grub partition in place, and that the partition table type is GPT.

Here is the output from parted:

root@jini:~# parted /dev/sdc print
Model: ATA ST4000NM0033-9ZM (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 15.0GB 15.0GB ext4
3 15.0GB 19.0GB 4000MB ext4
4 19.0GB 43.0GB 24.0GB linux-swap(v1) swap
5 43.0GB 283GB 240GB ext4
6 283GB 313GB 30.0GB ext4
7 313GB 343GB 30.0GB ext4
8 343GB 358GB 15.0GB ext4
9 358GB 478GB 120GB ext4
10 478GB 3478GB 3000GB ext4
11 3478GB 3739GB 261GB ext4
12 3739GB 4001GB 261GB ext4

What needs to be done so that Fedora 40 can be installed?

Added bios, f40, gpt, grub

From the live install usb can you get the output of lsblk -f abd post here, as that should be easier to understand than the raw partition data.

I ran ‘lsblk -f /dev/sdc’, ‘fdisk -l /dev/sdc’ and ‘parted /dev/sdc print’. The output is shown below. As can be seen, lsblk -f returned nothing for /dev/sdc1, but both fdisk and parted did.

lsblk -f output
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdc
├─sdc1
├─sdc2 ext4 1.0 0810d321-95d0-402c-9b03-c08e0163cfc8
├─sdc3 ext4 1.0 c594a4a8-9949-4d5e-bd27-771b19762f99
├─sdc4 swap 1 3ad22652-0095-49bd-969f-54f0a0cbd274
├─sdc5 ext4 1.0 6c79e558-0bf6-4e90-96a5-4eba0165bf69
├─sdc6 ext4 1.0 7c503b13-b387-4ec4-8e51-b5ea007a7127
├─sdc7 ext4 1.0 0f0962ef-76f9-4b10-be95-08c149c38ef7
├─sdc8 ext4 1.0 1268adf3-6ad0-45a5-8ba9-b11c864c1d15
├─sdc9 ext4 1.0 f0774c7f-e03c-424a-9ed1-5af901013316
├─sdc10 ext4 1.0 624aaa2a-04ed-4dc9-9ed8-d6ed84bb358b
├─sdc11 ext4 1.0 8aa5e39c-9adc-4fff-a165-96f09e89503f
└─sdc12 ext4 1.0 26bda055-9ff2-4e81-b3c9-21dbdf764416

fdisk -l output
Disk /dev/sdc: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A6127104-5631-C641-8605-A20E0F7B8F21

Device Start End Sectors Size Type
/dev/sdc1 2048 4095 2048 1M BIOS boot
/dev/sdc2 4096 29300735 29296640 14G Linux filesystem
/dev/sdc3 29300736 37113855 7813120 3.7G Linux filesystem
/dev/sdc4 37113856 83988479 46874624 22.4G Linux swap
/dev/sdc5 83988480 552738815 468750336 223.5G Linux filesystem
/dev/sdc6 552738816 611332095 58593280 27.9G Linux filesystem
/dev/sdc7 611332096 669925375 58593280 27.9G Linux filesystem
/dev/sdc8 669925376 699222015 29296640 14G Linux filesystem
/dev/sdc9 699222016 933597183 234375168 111.8G Linux filesystem
/dev/sdc10 933597184 6792972287 5859375104 2.7T Linux filesystem
/dev/sdc11 6792972288 7303503871 510531584 243.4G Linux filesystem
/dev/sdc12 7303503872 7814035455 510531584 243.4G Linux filesystem

parted /dev/sdc print
Model: ATA ST4000NM0033-9ZM (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 15.0GB 15.0GB ext4
3 15.0GB 19.0GB 4000MB ext4
4 19.0GB 43.0GB 24.0GB linux-swap(v1) swap
5 43.0GB 283GB 240GB ext4
6 283GB 313GB 30.0GB ext4
7 313GB 343GB 30.0GB ext4
8 343GB 358GB 15.0GB ext4
9 358GB 478GB 120GB ext4
10 478GB 3478GB 3000GB ext4
11 3478GB 3739GB 261GB ext4
12 3739GB 4001GB 261GB ext4

I should have said, please post as preformatted text with the </> button.

The lsblk -f is missing the disk usage info.

Can you list all dosk and nit just sdc?
Where is the /boot and EFI partitions?

1 Like

I’ve done a little more investigating; the actual error message I’m seeing indicates that the installation is specifically requesting that a 1M partition be created on /dev/sda (which happens to be part of an LVM at present).

I’ve been working on rearranging the order in which the disks are being seen by the boot process, but it’s not been an easy task as the order changes randomly during boot.

I haven’t exactly solved my problem, but at least I have a better idea about what is occurring during the initial disk partitioning process.

FYI, I’ve been installing previous Fedora releases on slice 11 for quite some time now with no problem. It’s only with Fedora 40 with which I’ve been having issues.

Let me know if this clears up at least part of the issue, or whether you still want more information.

Thanks

I’m guessing that /dev/sda is the disk that has the EFI partition on it?

You are right the order that hardware is detected and assigned names is not deterministic on modern hardware. Use of UUID for disks and MAC for ethernet cards it used to find specific items.

1 Like

Actually, I don’t have any EFI partition; my configuration is strictly non-UEFI.

One would think that, given the move to using UUIDs for disk identification, Fedora would use that method, instead of /dev/sdX, for installing their operating systems (they do, once the OS has been installed).

They cannot do that before the installation. The UUIDs used are file system UUIDs and that requires the partition be created and the file system formatted before the UUID is available. Partitions and file systems are created during installation.

It is up to the user to be careful and properly identify the drive (sda, sdb, etc.) they intend to install on before actually beginning the installation.

This is not important, and the order changes, so the effort is wasted.

Even with legacy boot, the drive the user selects to boot from must be selected for installation. The Bios Boot partition is expected to be the first thing on the drive selected so whichever drive you select must already have a gpt partition table and must have the first 1M free so the system can create that partition if not already there. If the space is not available then the system can create it in one of 2 ways.

  1. Wipe the disk, create a new partition table and allocate the boot partition.
    or
  2. The user must free the first 1M of the drive so the install can continue.

Since the system will not do a legacy installation without that boot partition (which is used to enlarge the MBR already reserved on all drives) and the partition must be at the beginning of the drive, then it is up to the user to manage how it is created. It also is up to the user to select which drive to install on (the default is normally the first drive which has available unallocated space.)