1 Perform an installation with Fedora-Workstation-Live-43-20250917.n.0.x86_64.iso on a VM with two disks, set /boot /boot/efi and / on disk1, format and encrypt disk2 and set the mount point as /home. 2. reboot the VM with Fedora-Workstation-Live-43-20250917.n.0.x86_64.iso,after the installation finished, click into "Mount point assignment", set /home to disk2, and set /boot, /boot/efi, / mount point, finish the installation, you will find /home is not re-used. If users don't encrypt disk2 on step1, it will work well. webui should ask users to unlock /home, just as it does when /home is on an encrypted partition( instead of disk). At least it should let users know, their configuration will NOT be accepted.Otherwise, users may think the /home is re-used, while they end-up get a system without the /home Reproducible: Always
Created attachment 2106989 [details] storage.log
Created attachment 2106990 [details] anaconda-webui.log
Created attachment 2106991 [details] journal
Proposed as a Blocker for 43-final by Fedora user lnie using the blocker tracking app because: seems affects the criteria: https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria#Custom_partitioning it should "Reject or disallow invalid disk and volume configurations without crashing"
Upstream fix: https://github.com/rhinstaller/anaconda-webui/pull/1008
Just a clarification for the reproducer - in order to trigger the bug, /home has to be on an encrypted drive, without any partitions. So basically the whole drive is used as a device, not individual partitions. Also, there seem to be two issues in anaconda: 1. It doesn't ask for unlocking the luks device (that should be fixed by the PR above) 2. It allows to use the unlocked luks device as a target for a mount point, but then ignores the mount point (it's not even visible in summary before installation). It should be clearer to the user that the mount point is invalid, or it shouldn't be possible to set it (unless I'm missing some use case for this). Fortunately, no data is lost when this bug occurs. The encrypted device is simply not used, so all data stay intact.
I do not understand if I understand correctly, but I have always though that you cannot use a disk without a partition on it. Did you mean, there is just one partition over the entire disk and it is mounted as /home, kparal?
No. You *can* use whole disks as devices, and create filesystems on them. Instead of creating vdb1, vdb2, vdb3, you can use the whole vdb, don't create any partition table (erase it if present), and format it as e.g. ext4 (on in this case, luks, and then e.g. ext4 on top of it). That's what Lili used, and the Cockpit installer allows to do this quite easily. But I guess it's not a very common use case, partitions are more flexible than using the whole drive. So the reproducer layout is this: vda |- vda1 as biosboot or ESP |- vda2 as /boot |- vda3 as / vdb as luks with /home on top of it
does gtkui handle this state correctly? i.e. if you keep step 1 but replace step 2 with the same thing but using a gtkui image, what happens?
(In reply to Adam Williamson from comment #9) > does gtkui handle this state correctly? i.e. if you keep step 1 but replace > step 2 with the same thing but using a gtkui image, what happens? Out of curiosity, I tried this, and both Custom and Blivet-gui partitioners handle it properly. The device can be unlocked, configured as a mount point, and the OS is installed properly with the mount points as requested.
AGREED AcceptedFinalBlocker Discussed at the 2025-09-22 (blocker / freeze exception) review meeting: This is accepted as a violation of "the installer must be able to: ... Assign mount points to existing storage volumes", noting the "Re-using /home" footnote below, in the specific case that the /home to be reused is both encrypted and a direct-on-disk filesystem (not a partition). This is a fairly uncommon case but we decided it was potentially common enough (given the webui's ability to create such a layout) that we should block on it. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-22/f43-blocker-review.2025-09-22-16.01.txt
FEDORA-2025-581707ba53 (anaconda-43.41-1.fc43 and anaconda-webui-51-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-581707ba53
(In reply to Fedora Update System from comment #12) > FEDORA-2025-581707ba53 (anaconda-43.41-1.fc43 and anaconda-webui-51-1.fc43) > has been submitted as an update to Fedora 43. > https://bodhi.fedoraproject.org/updates/FEDORA-2025-581707ba53 This fixes both issues mentioned in comment 6. Great job.
FEDORA-2025-581707ba53 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-581707ba53` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-581707ba53 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-581707ba53 (anaconda-43.41-1.fc43 and anaconda-webui-52-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.