Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2186158 ** Information from BlockerBugs App:
Commented but haven't voted yet: kparal
The votes have been last counted at 2023-04-12 15:38 UTC and the last processed comment was #comment-851289
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)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
FinalBlocker -1
Edit to reverse my vote based on the expected nature of this bug.
This is the same behavior we have since f33, if we wanna reformat an old btrfs we must delete that partition and create a new one. I thought this was the intended behavior since the start of btrfs by default.
I won't give this +1 for F38, because (feel free to correct me):
there is a trivial workaround (just... recreate the part?)
Actually if I had to do it on my production machine, this part would worry me most. It is much safer to say "installer, use this partition" than "installer, create me a partition (somewhere)". In the Custom part, you don't even see where the partition gets created. In BIOS mode, this gets further complicated with primary/extended partitions. And, of course, it's much harder to create a proper layout manually then to reinstall to existing partitions.
this feels more in the "rfe" than a bug territory to me
Only Anaconda devs can confirm this. I pinged them in #anaconda. My assumption is that this is a bug, because other filesystems can be reformatted just fine.
FinalBlocker -1 I won't give this +1 for F38, because (feel free to correct me): there is a trivial workaround (just... recreate the part?) it was "broken" (the same way) in the past releases (as noted in the bug, didn't test myself) this feels more in the "rfe" than a bug territory to me
this behave like this since btrfs turned as default filesystem (f33), I just checked that on VM.
Reading Vojtech Trefny's comment at the ticket, it seems this is expected behavior.
Per the discussion on the bug: FinalBlocker -1 AGREED RejectedFinalBlocker
The following votes have been closed:
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F38 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.