#1260 [python-blivet] blivet-gui creates different volumes with the same name, confusing anaconda webUI | rhbz#2237375
Closed 7 months ago by blockerbot. Opened 9 months ago by blockerbot.

Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2237375
Information from BlockerBugs App:
2237375

Current vote summary

Commented but haven't voted yet: nixuser, vtrefny, coremodule

The votes have been last counted at 2023-09-11 18:14 UTC and the last processed comment was #comment-873635

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


See my comment here: https://bugzilla.redhat.com/show_bug.cgi?id=2237375#c13

First I thought this is just a niche problem, which arises if you e.g. create both btrfs and lvm or mdraid volume by anaconda (how many people use several volumes together?). But then I discovered a similar problem happens (with the same root cause, I believe), if you create two btrfs volumes - they are again given the same name "blivet", and the installation crashes. And so now I think we should block on this in Beta. Violates:
"Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
"Assign mount points to existing storage volumes"
"Reject or disallow invalid disk and volume configurations without crashing"
https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning

BetaBlocker +1

@kparal but if this have a workaround like you said on the ticket, that doesn't seem difficult: "The workaround is to name the volumes yourself (and give them different names)" can it be just documented as a know issue?

Of course it can. And we should probably do it, if the fix is not present in Beta, for any reason. But I still think it should be also a blocker, because of the installation crash which might happen in an easy-to-happen scenario, and which I believe has the same root cause (if a developer says those causes are different, we can vote on them separately. But atm I think they are the same).

So, sigh, sorry for yet another complication, but I think we need to separate this bug from https://bugzilla.redhat.com/show_bug.cgi?id=2237878 (#1295). I believe there are two issues - blivet-gui creates (when btrfs is involved) volumes with the same LABEL. And anaconda then, in such a case, can easily write to a different volume than requested. Let's use this bug just for the blivet-gui issue.

Let's reset the vote.
REVOTE BetaBlocker

While certainly not ideal, I think that a duplicate LABEL is actually allowed. That's why distributions now use UUID instead of LABEL for everything. So I think the blivet-gui part of the problem is probably not a blocker, unless the developers convince me otherwise. The part that definitely fixing is the anaconda bug, covered in #1295. For the moment, I see it as:
BetaBlocker -1 (let's see after we get feedback from the developer)
BetaFE +1

In blivet we generally don't allow creating devices with same names (if there is a conflict, we should always add the 00, 01... suffix when creating a new device), this is indeed broken with btrfs where we use the volume as a name for the btrfs volume name we use internally. Name is generally used as a unique identifier inside blivet, but is usually not an issue, because unique names are either forced by the technology (LVM won't allow you to have two VGs with the same name) or the devices are not really exposed to the user (for example when having an MD array and VG with the same name, you are not assigning mount points to both of these). This is now a problem with btrfs volumes, I am not sure how big problem it is -- I'd expect people will usually use subvolumes with btrfs, not two volumes.

I am not sure if this is a blocker worthy, the issue always existed in blivet (and blivet-gui), the new WebUI and mount point assignment just made it more visible and easier to trigger. Definitely something we need to fix in blivet, but I think it might wait for final.

I'd expect people will usually use subvolumes with btrfs, not two volumes

Generally, yes. But I can imagine creating several volumes either on different disks, or perhaps for a certain other use case (but I don't anything at hand atm).

I am not sure if this is a blocker worthy, the issue always existed in blivet (and blivet-gui)

OK, in that case I don't think we need to block Beta with this.
BetaBlocker -1

But I'm assuming we'll block on #1295. If we blocked on neither this nor that one, that would be a very bad combination for our users.

But I'm assuming we'll block on #1295. If we blocked on neither this nor that one, that would be a very bad combination for our users.

If we want to block on something, I'd prefer to block on this one, it will probably be easier to fix.

I'm at least:

BetaFE +1

to this one. On principle, blocking on #1295 rather than this feels right to me. Even if we fix this, people may have disks previously formatted with versions of blivet-gui that had this issue, or some other tool may do the same. anaconda really has to do the right thing.

So I think the blivet-gui part of the problem is probably not a blocker, unless the developers
convince me otherwise.

Dear lovely Kamil,the label stuff is just one of the messes caused by this bug,#2237377 is another,and it's ugly.

BetaBlocker +1

I see this one is gonna be the material for allot of fun at the next blocker review meeting 😊

BetaBlocker -1
BetaFE +1

AGREED AcceptedBetaFE

This problem affects the installation process and so it's impossible to fix post release.

The following votes have been closed:

AGREED RejectedBetaBlocker
AGREED AcceptedBetaFE

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

The decision to classify this bug as a "RejectedBlocker (Beta)" and an "AcceptedFreezeException (Beta)" was made as it makes more sense to block on 2237878 than on this (i.e. make the installer handle multiple volumes with the same label). Creating them is still a bad idea and should be fixed if possible, so we grant this an FE.

[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:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

7 months ago

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

Log in to comment on this ticket.

Metadata