Bug 2264419 - webui: non-root btrfs subvolumes are not mounted correctly
Summary: webui: non-root btrfs subvolumes are not mounted correctly
Keywords:
Status: ON_QA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda-webui
Version: 42
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Katerina Koukiou
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: AnacondaWebUITracker
TreeView+ depends on / blocked
 
Reported: 2024-02-15 14:17 UTC by Kamil Páral
Modified: 2025-03-11 07:42 UTC (History)
11 users (show)

Fixed In Version: anaconda-webui-11-1.fc41
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot of cockpit storage configuration (78.99 KB, image/png)
2024-02-15 14:18 UTC, Kamil Páral
no flags Details
screenshot of anaconda mounts configuration (57.84 KB, image/png)
2024-02-15 14:18 UTC, Kamil Páral
no flags Details
anaconda.log (6.29 KB, text/plain)
2024-02-15 14:19 UTC, Kamil Páral
no flags Details
journal.log (2.64 MB, text/plain)
2024-02-15 14:19 UTC, Kamil Páral
no flags Details
packaging.log (13.10 KB, text/plain)
2024-02-15 14:19 UTC, Kamil Páral
no flags Details
program.log (979 bytes, text/plain)
2024-02-15 14:19 UTC, Kamil Páral
no flags Details
storage.log (241.16 KB, text/plain)
2024-02-15 14:19 UTC, Kamil Páral
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.