Red Hat Bugzilla – Bug 1021258
requires user manually create biosboot when using guided partitioning
Last modified: 2013-11-06 13:09:57 EST
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
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.
Error, requires user to use Manual Partitioning to create a biosboot partition.
To create the required partition for me.
Created attachment 814305 [details]
Created attachment 814306 [details]
Created attachment 814307 [details]
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]
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 . 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." 
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)?
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)?
Fixes this bug.
anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20.
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.