Questionable, see Issue when trying to install F44 Beta with Anaconda Web-UI - #6 by bookwar
There is a realistic chance this bug is still there, if it is one. The question is what and how it was tested. More data necessary to evaluate all that
F43 fully updated, fresh reboot, rpm verified gnomes-boxes.
autogenerated gnome-boxes config
<domain type="kvm">
<name>fedora-unkno-8</name>
<uuid>f82ed165-a011-4010-8966-1537aef84f2b</uuid>
<title>Fedora 44 beta</title>
<metadata>
<boxes:gnome-boxes xmlns:boxes="https://wiki.gnome.org/Apps/Boxes">
<os-state>live</os-state>
<media-id>http://fedoraproject.org/fedora/unknown:4</media-id>
<media>/home/user/Downloads/Fedora-Workstation-Live-44_Beta-1.2.x86_64.iso</media>
</boxes:gnome-boxes>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://fedoraproject.org/fedora/unknown"/>
</libosinfo:libosinfo>
</metadata>
<memory unit="KiB">4194304</memory>
<currentMemory unit="KiB">4194304</currentMemory>
<vcpu placement="static">12</vcpu>
<os firmware="efi">
<type arch="x86_64" machine="pc-q35-10.1">hvm</type>
<firmware>
<feature enabled="yes" name="enrolled-keys"/>
<feature enabled="yes" name="secure-boot"/>
</firmware>
<loader readonly="yes" secure="yes" type="pflash" format="qcow2">/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2</loader>
<nvram template="/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2" templateFormat="qcow2" format="qcow2">/home/user/.config/libvirt/qemu/nvram/fedora-unkno-8_VARS.qcow2</nvram>
<boot dev="cdrom"/>
<boot dev="hd"/>
<bootmenu enable="yes"/>
</os>
<features>
<acpi/>
<apic/>
<smm state="on"/>
</features>
<cpu mode="host-passthrough" check="none" migratable="on">
<topology sockets="1" dies="1" clusters="1" cores="6" threads="2"/>
</cpu>
<clock offset="localtime">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
<timer name="hpet" present="no"/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>destroy</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled="no"/>
<suspend-to-disk enabled="no"/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="writeback" discard="unmap"/>
<source file="/home/user/.local/share/gnome-boxes/images/fedora-unkno-8"/>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</disk>
<disk type="file" device="cdrom">
<driver name="qemu" type="raw"/>
<source file="/home/user/Downloads/Fedora-Workstation-Live-44_Beta-1.2.x86_64.iso" startupPolicy="mandatory"/>
<target dev="hdc" bus="sata"/>
<readonly/>
<address type="drive" controller="0" bus="0" target="0" unit="2"/>
</disk>
<controller type="usb" index="0" model="qemu-xhci" ports="15">
<address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
</controller>
<controller type="sata" index="0">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
</controller>
<controller type="pci" index="0" model="pcie-root"/>
<controller type="pci" index="1" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="1" port="0x10"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
</controller>
<controller type="pci" index="2" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="2" port="0x11"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
</controller>
<controller type="pci" index="3" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="3" port="0x12"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
</controller>
<controller type="pci" index="4" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="4" port="0x13"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
</controller>
<controller type="pci" index="5" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="5" port="0x14"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
</controller>
<controller type="pci" index="6" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="6" port="0x15"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
</controller>
<controller type="virtio-serial" index="0">
<address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
</controller>
<controller type="ccid" index="0">
<address type="usb" bus="0" port="1"/>
</controller>
<interface type="bridge">
<mac address="52:54:00:0e:dc:33"/>
<source bridge="virbr0"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
<smartcard mode="passthrough" type="spicevmc">
<address type="ccid" controller="0" slot="0"/>
</smartcard>
<serial type="pty">
<target type="isa-serial" port="0">
<model name="isa-serial"/>
</target>
</serial>
<console type="pty">
<target type="serial" port="0"/>
</console>
<channel type="spicevmc">
<target type="virtio" name="com.redhat.spice.0"/>
<address type="virtio-serial" controller="0" bus="0" port="1"/>
</channel>
<channel type="spiceport">
<source channel="org.spice-space.webdav.0"/>
<target type="virtio" name="org.spice-space.webdav.0"/>
<address type="virtio-serial" controller="0" bus="0" port="2"/>
</channel>
<input type="tablet" bus="usb">
<address type="usb" bus="0" port="2"/>
</input>
<input type="mouse" bus="ps2"/>
<input type="keyboard" bus="ps2"/>
<graphics type="spice">
<listen type="none"/>
<image compression="off"/>
<gl enable="no"/>
</graphics>
<sound model="ich9">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
</sound>
<audio id="1" type="spice"/>
<video>
<model type="virtio" heads="1" primary="yes">
<acceleration accel3d="no"/>
</model>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="3"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="4"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="5"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="6"/>
</redirdev>
<watchdog model="itco" action="reset"/>
<memballoon model="virtio">
<address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
</memballoon>
</devices>
</domain>
F44 beta, updates-testing enabled, fully updated on another machine.
The storage checker reports the error message of the initial post in all my test sessions.
The error is caused by failure to unmount /home and / subvolumes, possibly because the umounts are issued in the wrong order, as demonstrated in this example:
$ df /dev/vda3
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda3 16087040 6272 15545344 1% /mnt/sysroot
$ sudo umount /mnt/sysroot/home
umount: /mnt/sysroot/home: no mount point specified.
$ sudo umount /mnt/sysroot/
$ sudo umount /mnt/sysroot/home
When I unmount / in a terminal before “Return to installation” the storage checker reports ok.
@ilikelinux, @py0xc3 Feel free to reproduce the issue. Use F44 beta on whatever host you have available and create the config shown in the very first pic. The key is to mount both /home and / subvolumes. No mounts, no issue. That’s it.
I was able to reproduce the issue on GNOME Boxes (Flatpak) using Fedora-Workstation-Live-44_Beta-1.2.x86_64.iso.
As @tk2345 mentioned, I suspect there might be an issue with the order in which the storage editor automatically unmounts devices when “Return to installation” is clicked.
Also, Once this state occurs, root and home can no longer be unmounted, so the only way I found to recover was to go to “Create Partition Table”, select “Overwrite existing data with zeros (slower)”, and redo the partition setup from scratch — though there may be another way that I’m not aware of.
Additionally, if manually mounting is not necessary during setup, I wonder if the “Mount” option in the menu is needed at all?
My steps were as follows:
-
Open the storage editor
-
Create a partition:
-
Mount point: /boot/efi
-
Type: EFI system partition
-
Size: 512 MB
-
-
Create a partition:
-
Mount point: /boot
-
Type: ext4
-
Size: 2 GB
-
-
Create a partition:
-
Type: btrfs
-
Size: remaining space (all)
-
-
Create a subvolume:
-
Name: root
-
Mount point: /
-
-
Create a subvolume:
-
Name: home
-
Mount point: /home
-
-
Set the mount point for the home subvolume
-
Set the mount point for the root subvolume
-
Click “Return to installation”
I am guessing that steps 7 & 8 are actually mounting the devices.
Based on the settings you used I have to wonder why you are using the storage editor instead of simply allowing it to automatically perform those steps. Except for the size of the efi partition (default is 600MB) your settings match the automatic partitioning done by the installer.
There have been a few quirks with the new webui installer (in the storage editor) that I have seen as well but the automatic partitioning seems to always work.
I will test your steps with a VM and see if I get the same results.
You are right, steps 7 & 8 are mounting the devices.
My steps were just an attempt to reproduce the issue reported in this thread — I don’t actually intend to use this partition setup in practice.
I did exactly what you show for steps except mounting the btrfs file systems in steps 7 & 8. The installation completed with no errors
I don’t think the editor unmounts the devices when it returns to the installation.
Your comment about an issue seems valid and the mount option probably should not be active.
@tk2345
Try the installation again, but this time do not mount / and /home before returning to the installation.
So the editor does not unmount the devices automatically.
I wonder if what’s happening is that closing the editor with subvolumes still mounted triggers some internal error, which results in a not-very-user-friendly error message being displayed. Though I’m not entirely sure about that.
Me to no issues. While making a subvolume there it has the option to write the mount point, without separately do it afterwards. The difference is that it not shows the size in advance. Sub volumes anyway share the space, no need to display the size as it is always the same.
This might be needed to mount existing partitions with data, to verifier. I would not totally remove, however a note that mounting separately, is not needed, would make sense.
I gave a mount point to the top level btrfs and to undo, I also just created a new Partition Table. Without the slow option. To restart the partitioning.
Thank you for reproducing the issue!
True. I guess the safest way to recover is to reboot and restart the installation.
I agree. The mount option (in its current state) is not helping.
I was not looking for alternative paths through the storage editor, which work. I’m sure there are plenty so that most users will never end up in this state.
My ask was to reproduce the issue, because @ lruzicka couldn’t trigger it.
@isiin
I repeated my test exactly as you showed with a VM, although I reversed steps 7 & 8. (It is only logical (and mandatory) that / be mounted before /home)
The installation completed as expected.
I then tried again but this time I mounted /home before I mounted / (in the order you noted with steps 7 & 8)
This time it gave me the error already noted.
I strongly suspect this is because mounting / after having already mounted /home meant that /home could not be unmounted because it was hidden under /.
Logic and the file system require that / be mounted first since everything else is mounted to existing mount points in the / file system.
Mounting anything else to the same mount point always hides what was first mounted there from the OS. If the installer knows that /home was mounted but it is inaccessible then when it tries to unmount it (before unmounting /) the installer then fails before it unmounts / and that failure will cause anything after that to fail.
This error does not seem like an installer error, but rather a user error in the sequence events were performed.
It is like building a house, you have to start with the fundation, just then you can start creating the levels on it.
The expression root is in this case incorrect, because there exists a /root directory which is the home of the root user.
I for my selves better use the Expression Filesystem which contains all folders we need to create a running system with all files and links. On which the forward slash is the lowest level (The root of the file tree) and is used as mount point for it.
I was also able to confirm that the issue only occurs when /home is mounted before /, and not when / is mounted first.
Since the subvolumes are listed in alphabetical order in the UI (with “home” appearing above “root”), it is easy to accidentally mount them in the wrong order by simply going top to bottom.
Also, I noticed that my steps incorrectly listed vfat as the type for /boot/efi. The correct type is EFI System Partition. I will correct this.
Not incorrect at all.
/ is the root of the file system tree for all 'nix systems (and has been from the very beginning) – the location that is the base upon which the entire file system for the OS is built. Every other directory tree is a branch off the root of that tree. /root is just one branch of that tree that happens to be the home directory for the user ‘root’ and is named for that user, just like directories under /home are (by default, but not required to be) named directly for the user who owns that home directory.
The installer calls it the “EFI System Partition” since that is the flag it is given for boot purposes. Calling it that in the installer makes certain there is no ambiguity about its purpose. The file system type in that partition is “vfat” so you were not incorrect.
@bookwar I think the details relevant for you are in post #35 above. Jeff added some more details. Looks like a bug and Jeff provided details that could suffice to fix it 
The assumption this is a bug is based on the assumption that the installer is intended to determine itself the appropriate order about when to mount what partition, such as determining itself that / must be mounted before /home.
As you said the newest ISOs have no changes to the storage editor, that might be still in the newest version.
But in case anyone has time and resources atm, they are free to reproduce it with the newest installer though. Just that we know for sure The more the team is supported, the more bugs they can solve
To label / as root is incorrect and causes confusion. When you click on it in a file navigator (you not even can click directly on it, you need to type it in the path) to see the whole filesystem, right?
A correct label would be root_of_filesystem or just RoF. I for my selves choose the label Filesystem to avoid this confusion.
Because Fedora uses the label of the the sub-volumes root and home by default. This labels are shown in the file browser when opening it. As home is the base directory for the user data /home, users assume (especially new once) that root is the users root home directory.
If we simply would ban to label / as root, we could avoid this kind of problem/miss conception. Even if this is named so since the beginning of UX OS’s, not means that we should not reconsider the naming of it, to clarify, of what exactly we speaking about.
That is why I also not see a issue when anaconda has a problem with the fact, that you can not create a subvolume named /home before you have a Filesystem/RoF to put it into it.
You can create them in any order. You simply cannot mount them in random order. / must be mounted first.