Description of problem:
I have an existing partition in the middle of the disk:
$ sudo parted /dev/sda p
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 16.1GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
2 10.1GB 11.1GB 1072MB primary ext4
If I try to use blivet-gui inside anaconda to install Fedora, the BIOS boot partition can't be created at the beginning of the disk, because blivet places it *after* sda2. Please see the attached video.
This is a no-go for system installation, because BIOS boot partition needs to be at the very beginning (to contain MBR).
The same problem affects any other partitions (not just BIOS boot), unless you make them larger than the remaining space after sda2, but smaller than the initial space before sda2. In that case, they are placed correctly. But the point is, you should be able to specify the exact location using blivet-gui, and it doesn't work, only sometimes it does what you needed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create MBR disk with sda1 sda2 sda3
2. delete sda1 sda3 (you're left with sda2 in the middle)
3. in anaconda go to blivet partitioning and try to create bios boot partition at the beginning of the disk while keeping sda2 intact
Created attachment 1619436 [details]
bug video demonstration
Created attachment 1619437 [details]
Created attachment 1619438 [details]
Proposing as a blocker:
"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
just to be clear, this only affects 'advanced custom' (blivet-gui), not 'regular custom'?
Yes, only blivet-gui. I tested custom partitioning, and it creates biosboot partition correctly at the beginning of the disk.
It looks like a "weight" problem,a simpler reproducer is:
create a none-boot partition(like /) first,then create biosboot.
I have sent a pull request to remove the weight-related code,and it wfm
Please correct me if I'm wrong,thanks.
(In reply to lnie from comment #7)
> It looks like a "weight" problem,a simpler reproducer is:
> create a none-boot partition(like /) first,then create biosboot.
> I have sent a pull request to remove the weight-related code,and it wfm
> Please correct me if I'm wrong,thanks.
This pull request also fixs 1756288
Discussed during the 2019-09-30 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:
"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" for installs done via 'advanced custom' partitioning.
I think the bug is that BIOS Boot partition type is even permitted on "Partition Table: msdos" per the description. This partition type is only defined for GPT. And in the case of GPT, it has a unique and unambiguous partition type GUID for the bootloader installer to locate it no matter where it is, i.e. it's location can be arbitrary and grub2-install does find it. If some other bootloaders use BIOS Boot (?) and can only use it when BIOS Boot is the first partition, that's a bootloader installer bug.
I think this is not a blocker bug.
I also agree this is a bug: "But the point is, you should be able to specify the exact location using blivet-gui, and it doesn't work, only sometimes it does what you needed." but I still don't think it constitutes a blocker as long as a workable layout can be created.
(In reply to Chris Murphy from comment #10)
> I think this is not a blocker bug.
When we discussed this during the meeting, I tried to be very clear that this problem doesn't affect just biosboot partitions, but any partitions. Once you have a partition in the middle, it always uses the space behind it (or perhaps the larger space available, either way, you can use only one of the areas). That was also considered to be violating the criterion. If you think this hasn't been discussed properly, please remove the AcceptedBlocker tag and we'll discuss it again today.
upstream PR: https://github.com/storaged-project/blivet-gui/pull/133
updates image: https://vtrefny.fedorapeople.org/img/rhbz1755813.img
(In reply to Vojtech Trefny from comment #13)
> updates image: https://vtrefny.fedorapeople.org/img/rhbz1755813.img
This updates.img fixes the problem.
FEDORA-2019-9fa73b4b6c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9fa73b4b6c
blivet-gui-2.1.11-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9fa73b4b6c
(In reply to Fedora Update System from comment #16)
> blivet-gui-2.1.11-2.fc31 has been pushed to the Fedora 31 testing
Fixes the problem, thanks.
Sorry for my late feedback,I was busy with my father's funeral events.
https://github.com/storaged-project/blivet-gui/pull/133 fixes kamil's bug,because weight-related code is removed, boot is set to True.
When boot is False and grow is False,blivet will pick a smaller free region,and you will see symptom in kamil's description.
Vojtech's pull request dose not only remove "weight" code but also add "start" code,which will then produce the bug in #comment7.
Should I open a new bug for that one? It looks like also a blocker bug,since it violates"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration".Please correct me if I'm wrong,thanks.
(In reply to lnie from comment #18)
> Vojtech's pull request dose not only remove "weight" code but also add
> "start" code,which will then produce the bug in #comment7.
On a clean disk, I created / partition and a biosboot partition and they correctly ended up as vda1 and vda2 (in the order I specified, / first and biosboot second). Please note that biosboot doesn't need to be first, I was wrong in comment 0 and Chris corrected me. Either way, blivet-gui now seems to do exactly what you request of it. If you see some use case broken, please specify exactly the steps to take, and explain why do you consider the end result incorrect and how you think it should be changed instead.
I thought /boot should always be the first partition no matter you create it before or after /,that's the reason why I considered #comment7 is a blocker bug,
but Vojtech explained that the goal of blivet-gui is not reorder partitions,and sounds reasonable to me,so sorry for the noise.
lili, if you're now happy with the update, can you +1 it? it needs more karma to go stable. thanks!
(In reply to Adam Williamson from comment #21)
> lili, if you're now happy with the update, can you +1 it? it needs more
> karma to go stable. thanks!