Description of problem: When installing using Guided partitioning path to a GPT disk containing 2 or more partitions, and at least one of them will be preserved, the installer refuses to proceed telling the user a biosboot partition is required. Version-Release number of selected component (if applicable): F20 beta TC5 anaconda-20.25.1-1 python-blivet-0.23.1-1 How reproducible: Always Steps to Reproduce: 1. Existing GPT disk with 2+ partitions that are not a BIOS boot partition. 2. Guided partitioning, Installation Options: "I want more space"; continue 3. In Reclaim Disk Space, delete one or more partitions, preserving at least one; click Reclaim Space button. Actual results: Error, requires user to use Manual Partitioning to create a biosboot partition. Expected results: To create the required partition for me. Additional info:
Created attachment 814305 [details] anaconda.log
Created attachment 814306 [details] program.log
Created attachment 814307 [details] storage.log
Regression: Easier way to reproduce is with a GPT disk with 1 partition, and enough free space for Fedora, and using the default "Automatically configure" option, then clicking continue. Proposing as a beta blocker: "When using the guided partitioning flow, the installer must be able to cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation." Work around requires that I use manual partitioning.
Created attachment 814308 [details] c4 storage.log storage.log with simpler reproduce steps. Why does blivet initially think it's unneeded? Seems similar to bug 1010495. 15:04:26,094 INFO blivet: skipping unneeded stage1 biosboot request
This is reproducible in qemu/kvm using SeaBIOS.
Discussed this in 2013-10-21 Blocker Review Meeting [1]. Accepted as a blocker per Beta criterion "When using the guided partitioning flow, the installer must be able to cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation." [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/ [2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning
This is caused by anaconda commit 1bcfb368b75f2d. The bootloader stage1 disk must be set before doAutoPartition is called.
Could you give this a try (against TC5)? http://bcl.fedorapeople.org/updates/1021258.img It moves the bootloader execute back the way it was. It also fixes reusing an existing /boot/efi in autopart.
(In reply to Brian C. Lane from comment #9) > Could you give this a try (against TC5)? > http://bcl.fedorapeople.org/updates/1021258.img Fixes this bug.
anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.4-1.fc20
Bug no longer occurs with Fedora-20-Beta-TC6-x86_64-DVD.iso
20.25.4-1 went stable as part of FEDORA-2013-20033, and the fix was verified, so this can be closed.