Bug 2326361 - Storage editor: on reboot, it does not respect the subvolume mounts
Summary: Storage editor: on reboot, it does not respect the subvolume mounts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda-webui
Version: 42
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Katerina Koukiou
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-11-14 21:06 UTC by Emanuele
Modified: 2025-12-05 15:00 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-12-05 15:00:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Emanuele 2024-11-14 21:06:46 UTC
During testing of the new installer, I also tried advanced partitioning using the "Storage editor". I deleted and recreated the partitions with their respective mount points.

Steps to reproduce:

1. Download the Workstation Rawhide ISO with the new installer
2. On the installer's initial screen, click in the top right corner and select "Launch storage editor"
3. Delete the ext4 partition for boot and the Btrfs partition
4. Create a Btrfs partition
5. Create custom subvolumes with their respective mount points: subvolume @ > /; subvolume @home > /home; subvolume @var > /var
6. EFI partition: /boot/efi
7. Click "Return to installation" at the bottom
8. Click install and reboot

On reboot, only the subvolume @ > / is mounted.
The rest of the subvolumes are created but not mounted.

Initially reported in the "feedback collection" discussion: https://discussion.fedoraproject.org/t/feedback-collection-of-test-week-for-the-anaconda-web-ui-installer-for-fedora-workstation/135846/22

Thank you.

Reproducible: Always

Comment 1 Aoife Moloney 2025-02-26 13:16:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Comment 2 Katerina Koukiou 2025-12-05 15:00:18 UTC
I just tested this on rawhide and the issue is not longer present. I was not able to quickly identify the commit that fixed it, it must have been a while ago.


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