Description of problem: In osbuild of Fedora 40 Workstation, anaconda webUI fails to create partition. Tested both on x86_64 bare metal and aarch64 QEMU VM. Non-osbuild isos works as expected. Version-Release number of selected component (if applicable): Fedora-Workstation-Live-osb-40-20240218.n.0.x86_64 anaconda-webui-6-1.fc40.noarch cockpit-storaged-311-1.fc40.noarch libudisks2-2.10.1-4.fc40.x86_64 udisks2-2.10.1-4.fc40.x86_64 Steps to Reproduce: 1. boot osbuild Fedora 40 Workstation 2. in anaconda webUI, create a new GPT partitioning table 3. create a partition (tested: label boot, mount /boot, ext4, size 1GB) Actual results: Anaconda webUI shows an error: Failed to open file "/etc/fstab": No such file or directory error entry in journal: udisksd[1992]: Failed to open file "/etc/fstab": No such file or directory Expected results: Partition is created as expected.
Isn't that a bug in osbuild?
I proposed https://github.com/storaged-project/udisks/pull/1263 to make UDisks2 more robust in the face of a missing /etc/fstab. If UDisks2 releases too slowly, we can also put a workaround somewhere else. Does this bug block testing in general?
(In reply to Marius Vollmer from comment #2) > Does this bug block testing in general? I happen to notice this because there is no standard lorax build of aarch64 workstation iso, just the osbuild, but it is not blocking deliverable, if that's what you are asking.
(In reply to Lukas Brabec from comment #3) > (In reply to Marius Vollmer from comment #2) > > Does this bug block testing in general? > > I happen to notice this because there is no standard lorax build of aarch64 > workstation iso, just the osbuild, but it is not blocking deliverable, if > that's what you are asking. Hmm, I was worried that this might be a general problem with all the images that people use to test Anaconda, and all storage related testing would thus be pretty much impossible. But this doesn't seem to be the case. Thanks!
(In reply to Marius Vollmer from comment #2) > If UDisks2 releases too slowly, we can also put a workaround somewhere else. > Does this bug block testing in general? UDisks2 releases way too slowly but we can backport the patch in F40 packages.
FEDORA-2024-de4b62ca1a (udisks2-2.10.1-5.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-de4b62ca1a
FEDORA-2024-de4b62ca1a has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-de4b62ca1a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-de4b62ca1a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #6) > FEDORA-2024-de4b62ca1a (udisks2-2.10.1-5.fc40) has been submitted as an > update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-de4b62ca1a This update fixes the issue.
FEDORA-2024-de4b62ca1a (udisks2-2.10.1-5.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.