Bug 2264419

Summary: webui: non-root btrfs subvolumes are not mounted correctly
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: anaconda-webuiAssignee: Katerina Koukiou <kkoukiou>
Status: ON_QA --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 42CC: anaconda-maint, awilliam, gmarr, jkonecny, k.koukiou, kkoukiou, mkolman, robatino, rvykydal, slavik.vladimir, w
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-webui-11-1.fc41 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2231339    
Attachments:
Description Flags
screenshot of cockpit storage configuration
none
screenshot of anaconda mounts configuration
none
anaconda.log
none
journal.log
none
packaging.log
none
program.log
none
storage.log none

Description Kamil Páral 2024-02-15 14:17:18 UTC
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/  
$

Comment 1 Kamil Páral 2024-02-15 14:18:17 UTC
Created attachment 2016911 [details]
screenshot of cockpit storage configuration

Comment 2 Kamil Páral 2024-02-15 14:18:36 UTC
Created attachment 2016912 [details]
screenshot of anaconda mounts configuration

Comment 3 Kamil Páral 2024-02-15 14:19:15 UTC
Created attachment 2016913 [details]
anaconda.log

Comment 4 Kamil Páral 2024-02-15 14:19:19 UTC
Created attachment 2016914 [details]
journal.log

Comment 5 Kamil Páral 2024-02-15 14:19:23 UTC
Created attachment 2016915 [details]
packaging.log

Comment 6 Kamil Páral 2024-02-15 14:19:26 UTC
Created attachment 2016916 [details]
program.log

Comment 7 Kamil Páral 2024-02-15 14:19:30 UTC
Created attachment 2016917 [details]
storage.log

Comment 8 Kamil Páral 2024-02-15 14:21:26 UTC
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

Comment 9 Radek Vykydal 2024-02-16 09:35:37 UTC
I wonder if it can be related to the home subvolume not being checked to be formatted in the mpa screen, will check.

Comment 10 Radek Vykydal 2024-02-16 10:13:38 UTC
(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.

Comment 11 Katerina Koukiou 2024-02-16 12:05:31 UTC
Upstream fix: https://github.com/rhinstaller/anaconda-webui/pull/183

Comment 12 Geoffrey Marr 2024-02-20 05:30:34 UTC
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

Comment 13 Adam Williamson 2024-03-01 16:53:40 UTC
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.

Comment 14 Adam Williamson 2024-03-01 16:56:40 UTC
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.

Comment 15 Kamil Páral 2024-03-04 11:31:46 UTC
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.

Comment 16 Katerina Koukiou 2024-08-06 12:46:57 UTC
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

Comment 17 Aoife Moloney 2025-02-26 12:58:14 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Comment 18 Katerina Koukiou 2025-03-11 07:42:16 UTC
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.