Bug 2326361

Summary:	Storage editor: on reboot, it does not respect the subvolume mounts
Product:	[Fedora] Fedora	Reporter:	Emanuele <emanu.d3b>
Component:	anaconda-webui	Assignee:	Katerina Koukiou <kkoukiou>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	42	CC:	jkonecny, kkoukiou, mkolman, rvykydal
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-12-05 15:00:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.