Fedora Account System
Red Hat Associate
Red Hat Customer
+++ This bug was initially created as a clone of Bug #972906 +++ Description of problem: My attempt to install Fedora 18 failed with the following error messages. /usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: warning: Embedding is not possible, GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discourage.. /usr/bin/grub2-bios-setup: error: will not proceed with blocklists. I am installing on a system with 6 seagate hardrives which are 3TB in size. However, I am only installing to the /dev/sda hardrive for this case. My installation hardrive was pre-partitioned with gparted from Knoppix 7.0.4 live bootable DVD. It has a gpt partition table with the following partitions: /dev/sda1 2 MiB ext4 /dev/sda2 2048 MiB ext4 /dev/sda3 40960 MiB ext4 /dev/sda4 1778000 MiB ext4 /dev/sda5 256000 MiB ext4 /dev/sda6 768000 MiB ext4 /dev/sda7 16577 MiB linux-swap I then choose to use the customize partitions option of the F18 installer and configure the above existing partitions as follows with each partition being formatted during the install. /dev/sda1 2 MiB BIOS Boot /dev/sda2 2048 MiB ext4 /boot /dev/sda3 40960 MiB ext4 / /dev/sda4 1778000 MiB ext4 /home /dev/sda5 256000 MiB ext4 /data1 /dev/sda6 768000 MiB ext4 /data2 /dev/sda7 16577 MiB swap The installation process does indicate that /dev/sda1 is being reformatted to the BIOS Boot type. But the F18 installer indicates that it can't find a BIOS Boot partition. In the installer, /dev/sda was selected for installation of the boot loader and there was only one of the 6 drives selected for the installation process, that one being /dev/sda. Version-Release number of selected component (if applicable): Not sure what the version number was for anaconda but it was from the x86_g4 full installation DVD iso. How reproducible: I have reproduced it twice. Steps to Reproduce: 1. Boot the F18 installation DVD 2. Configure installation options 3. Start install Actual results: Install fails with error and warning messages cited above. Expected results: A successful install. Additional info: --- Additional comment from Dave Nystrom on 2013-06-10 15:10:16 EDT --- BTW, I was able to successfully install Fedora 17 on my machine with the initial partitioning scheme mentioned above. This problem is specific to my attempts to install Fedora 18. --- Additional comment from Dave Nystrom on 2013-06-15 10:07:03 EDT --- I'm stuck and need a path forward. Is it possible that someone could review my install procedure above and let me know if I am doing something fundamentally wrong? --- Additional comment from Steve Tyler on 2013-08-13 07:00:38 EDT --- Have you tried again with F19? If you have F17 installed, you can use the "fedup" command to upgrade to F18 or F19. $ sudo repoquery fedup --releasever=17 fedup-0:0.7.3-5.fc17.noarch $ sudo repoquery fedup --list --releasever=17 | grep man8 /usr/share/man/man8/fedup-cli.8.gz /usr/share/man/man8/fedup.8.gz --- Additional comment from Fedora End Of Life on 2013-12-21 08:56:47 EST --- This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Fedora End Of Life on 2014-02-05 16:45:16 EST --- Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This problem is still occurring while installing Fedora 19 or 20.
Please rerun it with f20 and attach the log files from /tmp/*log to this bug as individual text/plain attachments.
Created attachment 899759 [details] ks.cfg
Created attachment 899760 [details] anaconda.log
Created attachment 899761 [details] program.log
Created attachment 899762 [details] storage.log
Created attachment 899763 [details] ifcfg.log
Created attachment 899764 [details] packaging.log
Created attachment 899765 [details] sensitive-info.log
I have 4 HDDs, 2x500GB and 2x3TB. The pairs are identical. Here is info collected via sshd started in %pre (see ks.cfg) after installation faled: # parted -s /dev/sda -- print Model: ATA ST3500630AS (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 2149MB 2147MB primary raid 2 2149MB 4296MB 2147MB primary raid 3 4296MB 4833MB 537MB primary ext4 boot, raid 4 4833MB 500GB 495GB extended 5 4834MB 500GB 495GB logical raid # parted -s /dev/sdb -- print Model: ATA ST3000DM001-1CH1 (scsi) Disk /dev/sdb: 3001GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 1049kB 2149MB 2147MB raid 2 2149MB 4296MB 2147MB raid 3 4296MB 4833MB 537MB ext4 raid 4 4833MB 3001GB 2996GB raid as you can see, smaller disks have msdos partition table, but bigger drives have gpt partition table. From program.log it looks that grub2-install runs successfully on small, msdos drive, but fails on big, gpt drive.
# chroot /mnt/sysimage/ # grub2-install --no-floppy /dev/sda Installation finished. No error reported. # grub2-install --no-floppy /dev/sdb /usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for RAID and LVM install. # grub2-install --no-floppy /dev/sdc Installation finished. No error reported. # grub2-install --no-floppy /dev/sdd /usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for RAID and LVM install.
You should add a biosboot partition to the large disks: part biosboot --fstype=biosboot --size=1 --ondisk=sdb Also, you shouldn't use --size=1 with --grow, you should set a reasonable minimal size for the partition as a minimum (not really related, but it will cause problems).
@bcl, can you elaborate what kind of problems I can expect with --size=1 --grow? Can I just skip --size altogether when using --grow? Thanks, I will test biosboot part on sdb and sdd.
Yeah, biosboot partition did the trick. Machine installed properly with: part biosboot --fstype biosboot --size 1 --ondisk sdb --asprimary part biosboot --fstype biosboot --size 1 --ondisk sdd --asprimary # parted -s /dev/sdb -- unit s print Model: ATA ST3000DM001-1CH1 (scsi) Disk /dev/sdb: 5860533168s Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 2048s 4095s 2048s bios_grub 2 4096s 4198399s 4194304s raid 3 4198400s 8392703s 4194304s raid 4 8392704s 9441279s 1048576s ext4 raid 5 9441280s 5860532223s 5851090944s raid Thank you bcl@redhat for advice. If you could also elaborate more on --grow and --size, I would appreciated it. I cannot see any explanation in documentation what could be wrong with --size 1 and --grow.
Blivet uses the initial size in it's calculations for the partition placement so it needs to be a reasonable size before being grown to fit where it is placed. And if it is the / partition is will fail the check to see if there is enough space to install the packages.