See some background here and here. I think this is a big problem. This is not just about volumes created by blivet-gui. If a user has two volumes (maybe even standard partitions, I'd need to check) with the same LABEL (perhaps because of some disk cloning, or another tool with the same problem as blivet-gui), anaconda can say that it'll write to volume A and then write to volume B. This is a very easy way to lose data. I believe this violates
"Assign mount points to existing storage volumes"
https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria#Custom_partitioning
because the mount points are clearly not assigned correctly.

BetaBlocker +1

I've gotta say this feels:

BetaBlocker +1

to me. installing to the wrong thing is No Bueno. I am not sure whether I'd consider this sufficiently addressed if the blivet bug is fixed, it seems like a difficult call to make.

BetaBlocker +1

BetaBlocker +1

Yeah, Beta OS shouldn't eat your data...

1)This bug only happens when you create two bfrfs volumes(ie, lvm,raid,standard partition are not affected).
2) bug #2237375 is easier to fix,and we are already late.
3) it dose will cause data lose if #2237375 isn't fixed ,though on an unlikely-happen- in-real- world situation.
So...,
BetaBlocker -1
BetaFE +1

perhaps because of some disk cloning, or another tool with the same problem as blivet-gui

There turns out to be a much simpler use case - two Fedora installations (on different drives). Of course they have the same btrfs label. And that triggers this bug just fine: https://bugzilla.redhat.com/show_bug.cgi?id=2237878#c11

though on an unlikely-happen- in-real- world situation

As shown above, I'm afraid it's not that unlikely. It's just hard to think of all the possible use cases.

BetaBlocker +1

I've tried to reproduce the same problem with F38 GTK installer, for comparison. The results are mixed:

• With blivet-gui, because of this bug, I can't reuse an existing root subvolume and reformat it. I have to create a new one. In my attemps, it created it under the right btrfs volume as instructed, and the installation of the new OS was performed correctly. So I've found no issue there.
• With custom partitioning, because if this bug, I again can't reuse an existing root subvolume and reformat it. I can delete that subvolume and then create a new one. The problem is, I don't really have a precise control over where the new subvolume gets created. And it seems it always gets created on the first drive, vda (I can tell by seeing the subvolume size, and I can confirm it installs in there if no changes are made). There's a "Volume:" drop-down which I should be able to use to pick a different volume (on vdb), but it doesn't seem to be working. Whatever I choose, the target size is not updated, and the drop-down resets on each re-focus. So we can definitely say this is confusing and not working correctly, and it might trip people up and cause them to install somewhere else than they wanted, but it's not on the same level as with the new webUI (in webUI, I can see that's I'm selecting the larger disk, vdb, and it still installs to vda).

So the problem is probably also present in F38 and earlier (in custom part), it's just easier to get confused/mislead in F39 webUI.

AGREED AcceptedBetaBlocker

Discussed during the 2023-09-11 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as it violates the following criterion:

"the installer must be able to: ... Assign mount points to existing storage volumes" on webUI.

While the triggering condition is not super common, the potential consequences are catastrophic enough that we believe it should block release.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-11/f39-blocker-review.2023-09-11-16.00.txt

The following votes have been closed:

• Accepted BetaBlocker (+5, 0, -1)
  • +1 by kparal, adamwill, geraldosimiao, frantisekz, lruzicka
  • -1 by lnie

Release F39 is no longer tracked by BlockerBugs, closing this ticket.