Rescanning of the disks failed. org.fedoraproject.Anaconda.Error: failed to temporarily mount /dev/vda3 for btrfs operation ---[ System & Environment Information ]--- OS: Fedora Linux 44 (Workstation Edition) Anaconda version: 44.30 Anaconda UI version: 68
Created attachment 2137256 [details] Log file: /tmp/journal.log
Created attachment 2137257 [details] Log file: /tmp/anaconda.log
Created attachment 2137258 [details] Log file: /tmp/storage.log
Created attachment 2137259 [details] Log file: /tmp/program.log
Created attachment 2137260 [details] Log file: /tmp/packaging.log
Created attachment 2137261 [details] Log file: /tmp/anaconda-webui.log
Anaconda doesn't see a disk that contains an incomplete spanned btrfs filesystem (i.e. a btrfs filesystem that spans multiple disks, but one or more disks are missing). Such a disk doesn't show up in the Destination field, i.e. no disks are available for installation. If I use the Rescan Devices button, Anaconda crashes with the error from comment 0. Reproducer: 1. Prepare a machine (UEFI VM in my case) with two disks 2. Perform a default F44 Workstation installation onto both disks. That means you select both disks in Destination, and select "Use entire disk". The resulting installation has btrfs spanned across both drives, which you can confirm by running `sudo btrfs filesystem show /`. 3. Remove the second drive from your system. The drive that remains contains ESP, /boot, and a / partition that contains the incompletely btrfs filesystem. 4. Boot F44 Workstation install media again, start Anaconda. 5. In Anaconda, the Destination shows "No disks available" 6. Hit Rescan Devices, Anaconda then crashes Always reproducible.
Created attachment 2137262 [details] screenshot: no disks visible even if one is present
Created attachment 2137263 [details] screenshot: a crash after rescanning disks
Proposing for a blocker discussion: "The user must be able to select which of the disks connected to the system will be affected by the installation process. " https://fedoraproject.org/wiki/Basic_Release_Criteria#Disk_selection "The installer must be able to complete an installation to a single disk using automatic partitioning. " https://fedoraproject.org/wiki/Basic_Release_Criteria#Disk_layouts "When using the guided partitioning flow from the GTK-based installer or using the webui-based installer without entering the "Modify storage" page, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." and "Remove existing storage volumes to free up space, at the user's direction." https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria#Guided_partitioning "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. " https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Disk_layouts
Is the bug that installing to the incomplete set should *work*? Or that it should be cleanly rejected rather than crashing?
(In reply to Adam Williamson from comment #11) > Is the bug that installing to the incomplete set should *work*? Or that it > should be cleanly rejected rather than crashing? No, the bug is that I want to erase the whole drive with a fresh new default installation, and I can't. Because the drive is invisible to anaconda webui. I'm not saying that anaconda needs to be able to operate with a partial btrfs filesystem, that's unreasonable. I just want to be able to erase it.
Oh, right, so like wanting to wipe a single disk from a RAID set. We've had proposed blockers like that before, I think, don't recall what we decided.
(In reply to Kamil Páral from comment #12) > (In reply to Adam Williamson from comment #11) > > Is the bug that installing to the incomplete set should *work*? Or that it > > should be cleanly rejected rather than crashing? > > No, the bug is that I want to erase the whole drive with a fresh new default > installation, and I can't. Because the drive is invisible to anaconda webui. > > I'm not saying that anaconda needs to be able to operate with a partial > btrfs filesystem, that's unreasonable. I just want to be able to erase it. Note, this is how this works with older versions of Fedora -- the disk is visible, it has a btrfs partition which can be removed, you just can't reuse the existing subvolumes (because you don't see these at all, because we can't get the information). I've found the blivet change that broke this and I'm working on a fix.
Discussed at 2026-04-16 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-04-16/f44-final-go-no-go-meeting.2026-04-16-18.00.html . Accepted as a blocker as a violation of the criteria cited in comment #10 . Vojtech, if you could finish the fix and get a build done as soon as possible it'd be awesome, thanks.
FEDORA-2026-985539cc51 (python-blivet-3.13.2-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-985539cc51
I tested the new python-blivet-3.13.2-2.fc44 build on a VM used before to confirm the bug, and now the anaconda webui identified the device right at the first try. I tryed to rescan devices too to see if the crash happens but it found the device correctly. so, as long as I can tell, this build fix the issue.
FEDORA-2026-985539cc51 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-985539cc51` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-985539cc51 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Works fine in RC1.4. The drive is visible, I can erase the whole drive, or I can remove just the btrfs partition. When removing the btrfs partition, there's a broken message, which is a bit ugly, but it doesn't prevent the removal.
Created attachment 2137682 [details] broken message during partition removal This is how partition removal looks like in this case.
FEDORA-2026-985539cc51 (python-blivet-3.13.2-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.