Description of problem: When I ask anaconda to mount multiple btrfs subvolumes during installation, only the subvolume connected as / is mounted correctly. All the other subvolumes are ignored, and the btrfs fsroot (the top level filesystem root) is mounted to the target places instead. For example, instead of mounting "subvol=home" into /home, "subvol=/" is mounted into /home instead. Version-Release number of selected component (if applicable): anaconda-40.21-2.fc40.x86_64 anaconda-webui-5.2-1.fc40.noarch Fedora-Workstation-Live-x86_64-40-20240213.n.1.iso How reproducible: always Steps to Reproduce: 1. in anaconda webUI (Workstation Live), go to custom (cockpit) storage 2. create biosboot (if needed) and /boot partitions 3. create a btrfs partition 4. in order to create a subvolume, the btrfs fsroot needs to be mounted, and you need to do it manually (for some reason). So click on three dots next to the "/ subvolume" (which is a bit confusing, it's not a subvolume, it's the fsroot), click Mount, and mount it (I picked "/" as the value, because I had no idea what to pick, this is all weird). 5. click on three dots next to the "/ subvolume" and create a "root" subvolume with "/" mountpoint 6. click on three dots next to the "/ subvolume" and create a "home" subvolume with "/home" mountpoint 7. see the attached screenshot and compare whether your layout looks the same 8. click "return to installation" 9. select the option to assign custom mount points 10. for "/" select the "root" device 11. for "/boot" select your boot partition, reformat it 12. add a new mount, set "/home" as the mount point, and pick the "home" device, do not format it 13. proceed with installation 14. during the installation or when it's done, look at `findmnt /mnt/sysroot` to see whether "subvol=root" is mounted there as it should be 15. also look at `findmnt /mnt/sysroot/home` whether "subvol=home" is mounted there as it should be. In my case, not it's not, instead "subvol=/" (the fsroot) is mounted there. 16. when the installation is complete, look at /mnt/sysroot/etc/fstab. /home should have "subvol=home" mount option. In my case, it doesn't have any except "defaults". Actual results: btrfs subvolume mounts are not mounted correctly, the fsroot is mounted there instead Expected results: btrfs subvolume mounts should match the selected values in the installer Additional info: During/after installation, I see this: $ findmnt /mnt/sysroot TARGET SOURCE FSTYPE OPTIONS /mnt/sysroot /dev/vda3[/root] btrfs rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=258,subvol=/root $ findmnt /mnt/sysroot/home TARGET SOURCE FSTYPE OPTIONS /mnt/sysroot/home /dev/vda3 btrfs rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=5,subvol=/ Notice "subvol=/" instead of "subvol=home" ^^ $ cat /mnt/sysroot/etc/fstab <snip> UUID=2247a71f-3504-4342-99ba-d5db7e7503ef / btrfs subvol=root,compress=zstd:1 0 0 UUID=55ae4d71-a5a6-469d-bb2c-624235b36ccf /boot ext4 defaults 1 2 UUID=2247a71f-3504-4342-99ba-d5db7e7503ef /home btrfs defaults 0 0 Notice missing "subvol=home" (and "compress") for /home. When you have more subvolumes (e.g. "data" for /data), it behaves the same as in "home" case. When you boot into the installed system, you can see that it uses the btrfs fsroot for /home. It creates user home directories in the top fstree, next to all the subvolumes present: $ findmnt /home TARGET SOURCE FSTYPE OPTIONS /home /dev/vda3 btrfs rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=5,subvol=/ $ ls /home home kparal root # list the contents of the actually intended location for /home $ ls -A /home/home/ $
Created attachment 2016911 [details] screenshot of cockpit storage configuration
Created attachment 2016912 [details] screenshot of anaconda mounts configuration
Created attachment 2016913 [details] anaconda.log
Created attachment 2016914 [details] journal.log
Created attachment 2016915 [details] packaging.log
Created attachment 2016916 [details] program.log
Created attachment 2016917 [details] storage.log
Proposing as a Beta blocker: """ When using both the installer-native and the blivet-gui-based custom partitioning flow on the GTK-based installer, and the Cockpit-based custom partitioning flow on the webui-based installer, the installer must be able to: 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 """ https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria#Custom_partitioning
I wonder if it can be related to the home subvolume not being checked to be formatted in the mpa screen, will check.
(In reply to Radek Vykydal from comment #9) > I wonder if it can be related to the home subvolume not being checked to be > formatted in the mpa screen, will check. Yes reformatting home subvolume helps to fix the issue with fstab.
Upstream fix: https://github.com/rhinstaller/anaconda-webui/pull/183
Discussed during the 2024-02-19 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as it violates the following criterion: "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" [0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-19/f40-blocker-review.2024-02-19-17.00.log.txt
Since this is specific to the web UI, and web UI was deferred to F41, this can clearly no longer block F40 Beta. I'll take the liberty of bumping it to Rawhide and clearing blocker metadata.
Also, looking at git logs, it looks like this was in anaconda-webui-8-1.fc41 , so it should actually be fixed already. kparal, can you confirm? Thanks.
Tested with Fedora-Workstation-Live-x86_64-Rawhide-20240303.n.1.iso including: anaconda-41.2-1.fc41.x86_64 anaconda-webui-8-1.fc41.noarch cockpit-storaged-312-1.fc41.noarch This is broken and fixed at the same time. If I use manual mount point assignment, the subvolumes are mounted correctly. However, there's a new feature in anaconda now which detects mount points configured in cockpit storage and you don't need to assign them manually. If you use that, it's still broken, and even worse, now no subvolume including root is mounted correctly, all point to the fsroot: $ cat /mnt/sysroot/etc/fstab UUID=e32fc3ac-6c96-4b07-be28-4f8794a47f2d / btrfs defaults 0 0 UUID=266fbd66-b95a-493f-a682-67c2f49a63b4 /boot ext4 defaults 1 2 UUID=e32fc3ac-6c96-4b07-be28-4f8794a47f2d /home btrfs defaults 0 0 So, still broken.
This was fixed by: commit 0f1829a84c2d1bebe89ec2958f65357410d6a08b Author: Katerina Koukiou <kkoukiou> Date: Thu Apr 4 14:33:21 2024 +0200 storage: cockpit-integration: do not overwrite request object structure - only extend it Resolves: rhbz#2264419
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
This is covered upstream by testing the fstab. https://github.com/rhinstaller/anaconda-webui/blob/45e5777fbeea8b320341f27d4a93d36b0960d994/test/check-storage-cockpit#L314 Feel free to move it to done assuming coverage by the upstream tests.