steps to reproduce:
webUI installation

1. section installation method
2. Reinstall fedora
3. its denied as I have 1gb /boot
4. click Mount point assignement
5. setting of disks:
Mount_point  ..... Device .... Reformat
/ (required) ..... home .......yes
/boot/efi (required) vda1 .....yes
/boot(recommended) ..vda2 .....yes
/home (custom) .....home ......now

6. next / review / click to 'I understand'
7. installation, wait
8. End of proccess, initramfs generation ... after a while ERROR/ traceback / Installation fail

Created attachment 2110702 [details]
journal.log with traceback

Created attachment 2110703 [details]
step by step procedure

Created attachment 2110704 [details]
after installation in console: fdisk -l

Created attachment 2110705 [details]
after installation in console: lbskl

after the installation (with this error) I rebooted and system seems to be OK.
I have preserved /home from f42.

I reproduced the same error with with a BIOS installation (Petr used UEFI), also reformatting / and /boot and keeping existing /home (default F42 Workstation install).

With regular ext4 partitions for / and /home, I didn't reproduce this issue.

I asked Radek Vykydal what system finalization steps are missing because of the crash. He says:

The steps we are missing include

    running kickstart post scripts - hopefully not relevant for webui
    copying logs to the system
    selunux context restoring
    storage teardown

So I wouldn't say it is harmless without careful investigating.

(In reply to Kamil Páral from comment #7)
> I reproduced the same error with with a BIOS installation (Petr used UEFI),
> also reformatting / and /boot and keeping existing /home (default F42
> Workstation install).

Interestingly, if you perform the installation again (on the same machine), with exactly the same steps, it doesn't crash. So it has to be somehow relevant to what the filesystem contents are (F42 compared to F43 files), or the btrfs subvolumes are somehow slightly different (so far, I only noticed that during the first reinstall, I see root/var/lib/machines subvolume as available, while it's not present during the second reinstall).

This is the default F42 Workstation subvolume list:

$ sudo btrfs subvolume list -a /
ID 256 gen 548 top level 5 path <FS_TREE>/root
ID 257 gen 549 top level 5 path <FS_TREE>/home
ID 258 gen 546 top level 256 path root/var/lib/machines

The crash seems related to the root/var/lib/machines subvolume. Possibly if you don't assign it in the custom mount UI. Testing for more info.

Tested and working workarounds:
a) in anaconda, go to storage editor and delete root/var/lib/machines subvolume. Then exit the storage editor and configure custom mounts as usual (/boot, /, /home).
b) in anaconda, go to storage editor and delete root/var/lib/machines subvolume, then also root subvolume. Then create a new root subvolume (under top-level volume) and configure your mount points directly in storage editor. Anaconda should confirm it's a valid layout and pick it up when you try to exit the storage editor.

In both cases, the new system will not have root/var/lib/machines subvolume - but it should be possible to create it afterwards, if needed.



I also tried to mount root/var/lib/machines to /var/lib/machines and reformat it in the custom UI, but that fails with an error message (a different anaconda bug to be filed). 

I also tried to create root/var/lib/machines subvolume under the root subvolume in storage editor, but that has weird consequences. You need to name it, so I used var-lib-machines (slashes are not allowed), var/lib/machines mountpoint, and ended up with this incorrect layout (and indeed, there is /var-lib-machines directory):

# btrfs subvolume list -a /
ID 257 gen 617 top level 5 path <FS_TREE>/home
ID 259 gen 617 top level 5 path <FS_TREE>/root
ID 260 gen 577 top level 259 path root/var-lib-machines
ID 261 gen 615 top level 259 path root/var/lib/machines

So another bug to be filed against cockpit or anaconda.

Created attachment 2110804 [details]
journal.log after installation freeze (not crash)

I'm not sure if this is related but I've experienced two apparent installation freezes near the end, on different machines using different install options, during Finalization, Configuring installed system. Eventually I stop waiting and just reboot, and it turns out the installed system seems perfectly functional. This journal.log was during the second instance. The file hadn't been updated in over 40 minutes, but it looked like the contents of /boot were normal, so I took my chances and rebooted.

Should also mention that I experienced the bug reported here on one occasion (see https://bugzilla.redhat.com/show_bug.cgi?id=2406260 which appears to be a dupe of this) which is why I suspect a connection. Out of 4 installation attempts, only one ended normally, one had the crash associated with this bug, and two had the installation freeze I described above. However, after rebooting the installed system was usable in all 4 attempts.

Correction, 5 attempts, 3 freezes, 1 unsure what happened, on 3 different machines.

Machine 1: One freeze using Mount point assignment, one normal install using Share disk with other operating systems.

Machine 2: One freeze using Mount point assignment.

Machine 3: One unsure outcome using Mount point assignment (the machine rebooted when I wasn't paying attention, not sure what caused it but it was usable after removing the install media), one freeze using Share disk with other operating systems.

In each of the 4 abnormal cases, the last thing I saw was Finalization, Configuring installed system.

Add a third attempt on Machine 1, using Use entire disk (a different disk on the same machine), which froze. Comparing the journal.log with the one I uploaded (from Machine 3), they end in exactly the same place. Correction to above. Machine 2 wasn't a freeze, it was the failed install reported in https://bugzilla.redhat.com/show_bug.cgi?id=2406260 . So 6 attempts total, 3 freezes, 1 normal install, 1 explicit crash, 1 uncertain. In every case the installation is usable afterwards. Apologies if this is unrelated.

(In reply to Kamil Páral from comment #12)
> Tested and working workarounds:
> a) in anaconda, go to storage editor and delete root/var/lib/machines
> subvolume. Then exit the storage editor and configure custom mounts as usual
> (/boot, /, /home).
> b) in anaconda, go to storage editor and delete root/var/lib/machines
> subvolume, then also root subvolume. Then create a new root subvolume (under
> top-level volume) and configure your mount points directly in storage
> editor. Anaconda should confirm it's a valid layout and pick it up when you
> try to exit the storage editor.
> 
> In both cases, the new system will not have root/var/lib/machines subvolume
> - but it should be possible to create it afterwards, if needed.

I tried the a) but in my case it seems the installed system has the root/var/lib/machines subvolume:

ID 257 gen 134 top level 5 path <FS_TREE>/home
ID 258 gen 134 top level 5 path <FS_TREE>/root
ID 259 gen 114 top level 258 path root/var/lib/machines

One issue worth noting is that /home does not have compress options (compress=zstd:1) in /etc/fstab:

UUID=c1fb6c96-3181-47ca-a049-c84d51fb3276 / btrfs subvol=root,compress=zstd:1 0 0
UUID=1bd328bc-acfd-450f-a557-96254a38945c /boot ext4 defaults 1 2
UUID=c1fb6c96-3181-47ca-a049-c84d51fb3276 /home btrfs subvol=home 0 0

Is is a known problem of home reuse via mount point assignment and it fixed in reinstall scenario. Maybe it is worth filing a bug (not sure if we have such) and trying to address - (allow to) preserve or allow to set fstab options in mount point assignment.

The cause of the issue happening in F43 seems to be:

1) In F43 we started to generate kickstart (/root/anaconda-ks.cfg) from individual modules for Live installation  https://github.com/rhinstaller/anaconda/pull/6398

2) We require (already in F42) incorrect MountPointRequest for the root/var/lib/machines:

Oct 24 12:22:37 localhost-live org.fedoraproject.Anaconda.Modules.Storage[3321]: DEBUG:anaconda.modules.storage.partitioning.manual.manual_module:Requests are set to '[MountPointRequest(device_spec='vda1', format_options='', format_type='efi', ks_spec='', mount_options='', mount_point='/boot/efi', reformat=True), MountPointRequest(device_spec='vda2', format_options='', format_type='ext4', ks_spec='', mount_options='', mount_point='/boot', reformat=True), MountPointRequest(device_spec='BTRFS-870bb39f-c033-4171-a5e8-e6810c8c571e-root', format_options='', format_type='btrfs', ks_spec='', mount_options='subvol=root', mount_point='/', reformat=True), MountPointRequest(device_spec='BTRFS-870bb39f-c033-4171-a5e8-e6810c8c571e-home', format_options='', format_type='btrfs', ks_spec='', mount_options='subvol=home', mount_point='/home', reformat=False), MountPointRequest(device_spec='BTRFS-870bb39f-c033-4171-a5e8-e6810c8c571e-root/var/lib/machines', format_options='', format_type='btrfs', ks_spec='', mount_options='subvol=root/var/lib/machines', mount_point='', reformat=False)]'.

(In reply to Andre Robatino from comment #13)
> I'm not sure if this is related but I've experienced two apparent
> installation freezes near the end

Sounds like a different problem, please report a separate bug.

(In reply to Radek Vykydal from comment #17)
> I tried the a) but in my case it seems the installed system has the
> root/var/lib/machines subvolume:

Oh, interesting, I can confirm this, actually for both a) and b). I didn't see that subvolume directly after installation, but I see it after rebooting into the installed system. Perhaps I'm just doing something wrong with the btrfs tools. Great, this improves the situation.

> One issue worth noting is that /home does not have compress options
> (compress=zstd:1) in /etc/fstab:

Thanks for a reminder, I'll add a note about this.

There are two Common Issue entries related to this:

https://discussion.fedoraproject.org/t/installer-crashes-when-btrfs-subvolume-gets-reformatted-while-having-nested-subvolumes/170252

https://discussion.fedoraproject.org/t/easy-reinstall-of-fedora-keeping-home-isnt-available-with-the-default-disk-layout-of-fedora-42-and-older/168033

Filed https://bugzilla.redhat.com/show_bug.cgi?id=2406677 for my issue. In my case, deleting /var/lib/machines before install didn't help.

*** Bug 2407351 has been marked as a duplicate of this bug. ***

Proposed as a Blocker for 44-beta by Fedora user psklenar using the blocker tracking app because:

 bug violates 
https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria#Guided_partitioning

problem description here:
https://discussion.fedoraproject.org/t/installer-crashes-when-btrfs-subvolume-gets-reformatted-while-having-nested-subvolumes/170252

*** Bug 2411991 has been marked as a duplicate of this bug. ***

This bug seems get worse with f44, and here is a simple %100 reproducer with f44:

1.Boot Fedora-Workstation-Live-Rawhide-20251102.n.0.x86_64.iso 
2.Create some partitions using  storage-editor:at least one partition should be formatted with btrfs 
3.Click into  "mount point assignment", set / on the btrfs partition, click "Next" to continue the installation

And here is the anaconda side(though I feel curious about why only btrfs is involved) fix I asked  AI to provide,I checked,the bug is gone after apply it.


diff --git a/pyanaconda/modules/storage/partitioning/interactive/utils.py b/pyanaconda/modules/storage/partitioning/interactive/utils.py
index c10a7bff2a..c49c09d54f 100644
--- a/pyanaconda/modules/storage/partitioning/interactive/utils.py
+++ b/pyanaconda/modules/storage/partitioning/interactive/utils.py
@@ -786,10 +786,17 @@ def get_device_factory_arguments(storage, request: DeviceFactoryRequest, subset=
     :param subset: a subset of argument names to return or None
     :return: a dictionary of device factory arguments
     """
+    device = storage.devicetree.get_device_by_device_id(request.device_spec)
+    disks = []
+    for disk_spec in request.disks:
+        disk = storage.devicetree.get_device_by_device_id(disk_spec)
+        if disk is not None:
+            disks.append(disk)
+    
     args = {
         "device_type": request.device_type,
-        "device": storage.devicetree.get_device_by_device_id(request.device_spec),
-        "disks": [storage.devicetree.get_device_by_device_id(d) for d in request.disks],
+        "device": device,
+        "disks": disks,
         "mountpoint": request.mount_point or None,
         "fstype": request.format_type or None,
         "label": request.label or None,
diff --git a/pyanaconda/modules/storage/partitioning/manual/manual_module.py b/pyanaconda/modules/storage/partitioning/manual/manual_module.py
index cfef0938e4..d6371e6ba9 100644
--- a/pyanaconda/modules/storage/partitioning/manual/manual_module.py
+++ b/pyanaconda/modules/storage/partitioning/manual/manual_module.py
@@ -81,7 +81,13 @@ class ManualPartitioningModule(PartitioningModule):

             if request.device_spec:
                 device = self.storage.devicetree.get_device_by_device_id(request.device_spec)
-                mount_data.device = device.path
+                if device is not None:
+                    mount_data.device = device.path
+                else:
+                    # Device not found, fall back to the original spec
+                    log.warning("Device with ID '%s' not found, using kickstart spec '%s' instead", 
+                               request.device_spec, request.ks_spec)
+                    mount_data.device = request.ks_spec
             else:
                 mount_data.device = request.ks_spec