On Modify Storage page,creat btrfs volume and then raid,make partitions,click into mount point assignment page,you will see the following two symptoms 1）the single btrfs volume is listed twice(screenshot1) 2）if you create one sub btrfs volume on Modify Storage page,which is no need in normal situation,00(btrfs) and blivet(btrfs) are listed(screenshot2). On 1) if you ignore the ugly look,and set mount point accordingly(no raid is shown,so you are not able to set mount point for it),click next,Error message pops up,saying device blivet is not formatted,so you are not able to continue the installation On 2),you need set mount point for 00 if you want to continue the installation. FYI,raid then btrfs, lvm then btrfs, lvm then raid, raid then lvm, btrfs then lvm ,all work because the names of devices are different. There are at least two bugs here,1) the first btrfs volume will be listed the-total-number-of-same-name-devices times. 2)With new webui,the default name for btrfs,lvm and raid are all blivet,anaconda should pick up a different device name if the default blivet is already used.Actually,it will pick a different one on btrfs-Not-first situations,so the situations,on btrfs then lvm situation,you are supposed to create lv to use the lvm volume,which means the name of device you are gonna to set mount point is different from the default: blivet,so it works. I'm gonna to report the two bugs separately. The work around is obviously,set different names on btrfs-first situation. Reproducible: Always
Created attachment 1987010 [details] anaconda.log
Created attachment 1987011 [details] storage.log
Created attachment 1987012 [details] screenshot1
Created attachment 1987013 [details] screenshot2
Proposed as a Blocker for 39-beta by Fedora user lnie using the blocker tracking app because: This bug violates: https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning
Lili, would it possibly to capture your screenshots/screencasts (and also logs, partially) in English instead of Chinese? That would make our work in understanding and reproducing the bug much easier, thanks :-)
> would it possibly would it be possible
(In reply to Kamil Páral from comment #6) > Lili, would it possibly to capture your screenshots/screencasts (and also > logs, partially) in English instead of Chinese? That would make our work in > understanding and reproducing the bug much easier, thanks :-) Nope,or,let's say,I don't know how to capture English ones, and that's one reason why I propose #2236034 to a FE:). That being said,I checked the logs attached,they are all English,for the two screenshots,you only need to check the device list,which are also all English.
Created attachment 1987049 [details] screencast
I have attached the reproducer video for those who are interested in,and here is a more detailed steps than in description: 1)Boot f39 on a virt-manager created VM which containing two or three disks 2) create btrfs volume,then software-raid volume,then two partitions,one is for /boot, one is for /boot/efi 3) Rescan 4)Click into the Mount point assignment page,find btrfs volume is listed twice 5)Set / for btrfs volume,then set /boot, /boot/efi,click Next,Error message "blivet device is not formatted" pops up. If you create a sub volume of btrfs volume on step2),and set / for 00(the sub volume name) on step5), No Error message will pop up,so you will be able to finish the installation.
*** Bug 2237379 has been marked as a duplicate of this bug. ***
*** Bug 2237377 has been marked as a duplicate of this bug. ***
From bug 2237377 comment 3: "This is the same issue with different reproducer: device names are internally used as unique identifiers by both Anaconda and Blivet and we shouldn't allow creating two devices with the same name." If I understand it properly, any time you create a "volume" in blivet-gui, be it btfs or lvm or software raid, it names it the same - "blivet". Then when you return to anaconda and assign point points, the UI is confused by having several volumes with the same name, and the installation can't proceed. I have reproduced this using two disks and creating btrfs volume and lvm volume. But, I also tested this with just a single disk, and creating two different btrfs volumes (both named blivet). It behaved differently, crashed during installation, see bug 2237878. But I think the core problem is the same - blivet-gui creates volumes with the same name, which then confuses tools operating on those volumes. The workaround is to name the volumes yourself (and give them different names).
> If I understand it properly, any time you create a "volume" in blivet-gui, be it btfs or lvm or software raid, it names it the same - "blivet". Then when you return to anaconda and assign point points, the UI is >confused by having several volumes with the same name, and the installation can't proceed. Maybe I didn't describe it clearly in the description:the same name problem only happens after you create a btrfs volume,ie,if you only create lvm and raid,you won't see this problem(That's the reason why I put btrfs then raid in the subject) I guess the screenshot I'm gonna to attach will help you. > It behaved differently, crashed during installation, see bug 2237878 It behaved differently because you use a different reproducer,mine is specific to... btrfs then raid:) I believe if you 1)boot your installer(Fedora-Workstation-Live-x86_64-39-20230906.n.0.iso,I got the information from your webui.log) with two,three or even more disks but create the second btrfs volume whose size is not big enough,you will still see the crash,2)but if you boot the installer with only one disk create two big enough btrfs volumes you won't see the crash.I have confirmed 1) and 2) with Fedora-Workstation-Live-x86_64-39-20230906.n.0.is,please tell me if it *really* behave differently on your side. So I guess your bug is yet another duplicate,your bug will be fixed as long as the same name bug is fixed.
Created attachment 1987700 [details] screenshot
Vojtech, can you please comment on whether bug 2237878 is just another duplicate of this, or different? If different, we would then vote on blocker proposals for them separately.
(In reply to Kamil Páral from comment #16) > Vojtech, can you please comment on whether bug 2237878 is just another > duplicate of this, or different? If different, we would then vote on blocker > proposals for them separately. I take this back. After writing 2237878 comment 4, I think these are two separate issues, one in blivet and one in anaconda. So I'll propose both. Let's use ticket just for the blivet-gui naming problem. Thanks, Lili, for helpful feedback. After playing with this some more, I can confirm your findings, and perhaps expand on them. Blivet has a naming system for new volumes (btrfs, lvm and swraid). It's "blivet" -> "blivet00" -> "blivet01" -> "blivet02" -> etc. The "next" name is set after each created volume. But this only works properly for lvm and swraid. Btrfs volumes don't increment the naming scheme. So these are examples how blivet-gui fails to create unique labels: 1. create btrfs -> "blivet" 2. create btrfs/lvm/swraid -> "blivet" (FAIL) 1. create lvm -> "blivet" 2. create btrfs -> "blivet00" 3. create btrfs/lvm/swraid -> "blivet00" (FAIL) 1. create lvm -> "blivet" 2. create swraid -> "blivet00" 3. create btrfs -> "blivet01" 3. create btrfs/lvm/swraid -> "blivet01" (FAIL) While this is not technically incorrect (filesystems/partitions/volumes can have the same LABEL), anaconda webui then gets confused and picks the volumes either randomly or just plain wrong, which then results in either not being able to start the installation, or writing to a different volume than expected, which is covered in bug 2237878.
Moving this to blivet. Thanks for investigating the issue Kamil. Few notes: for btrfs, blivet uses the label as device name for the btrfs volume device we internally create. So even with btrfs it is necessary for it to be unique -- device names are (internally in blivet) considered to be unique identifiers. Having two devices with the same name can cause multiple issues even with just blivet, without Anaconda and their usage of name as a unique identifier in the UI so we definitely need to fix this.
(In reply to Vojtech Trefny from comment #18) > Having two devices with the same name can cause multiple issues > even with just blivet, without Anaconda and their usage of name as a unique > identifier in the UI so we definitely need to fix this. Thanks for info, Vojtech. So it's not just a cosmetic issue as I assumed in https://pagure.io/fedora-qa/blocker-review/issue/1260#comment-873279 ? Can you please update that voting ticket whether you think this should be a Beta blocker, when considering what this bug can cause while performing disk management? Thanks!
> Thanks, Lili, for helpful feedback. My pleasure,tbo,I felt a little surprised that you bug detector failed to find the simple truth by yourself:) I'm certainly know your crash is caused by somehow wrongly mounted,but my anaconda bug #2237377 is duplicated by the logic "we don't allow two devices with the same name,so it's a duplicate of same-name bug" ,I thought your bug is just another mess caused by the same-name problem, because I failed to realize the label stuff.Btw,I checked,anaconda do list different-name devices correctly even if they have the same label,and I found your bug seems just specific to btrfs-btrfs volumes,will put more information there.
Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/1260 The decision to classify this bug as an AcceptedFreezeException was made: "This problem affects the installation process and so it's impossible to fix post release."
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
webUI was deferred to F40, so let's defer the FE status here too. I don't *think* it makes sense to pull this in for F39 as an FE any more, even if it *is* still a thing that happens in F39.
This is fixed upstream with https://github.com/storaged-project/blivet/pull/1153