Installer WebUI Critical Error: Installation of the system failed: Installing software 0% org.fedoraproject.Anaconda.PayloadInstallationError: Failed to install image: rsync exited with code 11 Please attach the file /tmp/webui.log to the issue. Reproducible: Always I have tried to reproduce bug 2237375, but instead of using two disks, I used only one disk and created two btrfs volumes (both named blivet). I picked one to use for installation. The installation started fine, but soon crashed.
Created attachment 1987517 [details] webui.log
Might be caused by bug 2237375.
Reproducer: 1. Boot anaconda webui with a clean disk. 2. Run blivet-gui from anaconda. 3. Create biosboot or esp partition, boot partition (ext4), and two btrfs volumes of different sizes - don't give them any custom names, so that they'll both get the default 'blivet' name. 4. Back in anaconda, rescan storage, then manually assign mountpoints. 5. Pick the first 'blivet' volume for /. Note: The UI will be misleading, you'll see two 'blivet' volumes with the same size (that's incorrect, they should have different sizes). Essentially it seems to display the first blivet volume duplicated. The same problem appears on the installation summary page. Just pick the first one. 6. Start install. After some time (in my case, when the installation percentage was at 72%), it'll abort the installation and show a crash dialog.
Thanks to Lili, we've found out the actual problem here. Anaconda wasn't installing to the first btrfs volume, it was installing to the second one! Even though it clearly displayed that the first one would be used (I could tell by seeing the size). The installation crashed just because the second btrfs volume wasn't large enough. I tried again just one - if I make the second btrf volume large enough, the installation succeeds and the system boots, but of course it's installed to a different partition than I wanted! So the basic problem here is that anaconda uses LABEL as the primary identification for mount points, and if there are two partitions with the same label (which is not prohibited), it gets absolutely confused. Its UI is broken, and it misleads the user that partition A will get used, while in reality partition B gets used. There's a high risk of data loss here. Due to bug 2237375, blivet-gui creates exactly such partitions/volumes. But even if it didn't, and the user had two partitions/volumes with the same LABEL for other reasons, the installer must not write somewhere else then indicated in its UI. Proposing for a blocker discussion.
*** Bug 2235774 has been marked as a duplicate of this bug. ***
I found this bug will only happen when users are trying to use more than one btrfs volumes, I checked with lvm and btrfs,raid and btrfs,lvm and lvm,all works fines. btrfs volume's label name which is not changeable by user, is "blivet",so set lv and raid partition label to 'blivet',you will get devices with same label names. I found one odd(for me) fact: create two btrfs volumes with the same name(so the devices' label name are the all "blivet"),create one subvolume for each,name them differently, so that you will know the exact device when you are setting mount point.Cause anaconda will mount wrongly,so set the btrfs volume ,which is Not for "/", to "/", and the one for "/" to some other mount point,say,/home,the installation will be finished successfully,but after you login to the system you will find the not-for-"/" volume partition is gone.
I just found out that,if the two btrfs volumes are created on two different disks,this bug will also not happen,so,in conclusion, this bug will only happen, if the two btrfs volume are created on same disks,and it looks like that there is no need to worry about the situation described in #comment4:the user had two partitions/volumes with the same LABEL for other reasons, the installer must not write somewhere else then indicated in its UI. Please feel free to correct me,or ask for more information,logs,screenshot,screencast,etc.
Okay,a little awkward,but sorry,I lied about the last comment,this bug will also happen on two different disk situation,I got that conclusion because I thought / will need more than 4G space,and I set the not-for-root btrfs volume size to 4G,it did not crash,so I thought this bug didn't happen,but after I looked into the newly installed system just now,I found that the root partition is mounted to the 4G volume,to be specific,/home is also mounted there.
Created attachment 1988087 [details] 4G screenshot
After further debugging, I have the following findings: 1) standard partitions (e.g. ext4) are not affected. Even if I have several ext4 partitions with the same label, Anaconda installs into the correct one as selected (Anaconda doesn't even show labels in mount point dialog, just device names like vda3). 2) This also affects btrfs volumes of the same label which have subvolumes of a different name. Iow, this is not just about subvolume-less btrfs. This confirms Lili's findings above. Details below: I requested blivet-gui to create the following: * create vda3 type btrfs (with a default label, i.e. "blivet"), create a subvolume named root1 * create vda4 type btrfs (with a default label, i.e. "blivet"), create a subvolume named root2 Blivet-gui created it correctly. Then I asked anaconda to do the following: * mount / into vda3/root1 (which implies a reformat) * don't do anything with vda4 The end result was: * vda3 has been removed (!!!). The whole partition. * root1 subvolume has been created under vda4. So suddenly I had vda4/root1 and vda4/root2. * the OS was installed into vda4/root1 (compare this to instructions above)
To simulate a somewhat likely real-world scenario, I added 2 drives to a VM and installed default F37 Workstation to vda and default F38 Workstation to vdb. The resulting layout was: (F37) vda3: btrfs labeled "fedora_localhost-live" with subvolumes "root" and "home" (F38) vdb3: btrfs labeled "fedora_localhost-live" with subvolumes "root00" and "home00" (note: those 00 suffixes are there because I had vda connected while installing F38. If I had disconnected it, the subvolumes would be "root" and "home", same as above. Then I booted F39 Workstation and asked anaconda to do the following: * select both drives for installation (let's say I wanted e.g. to reuse ESP on vda, or mount some data partition, etc) * mount / into vdb3/root00 (which implies a reformat) * don't do anything with vda3 This means keep F37, reinstall F38. But basically the same problem as above happened: * vdb3/root00 was removed * vda3/root00 was created and mounted for / So again, the OS was installed into the wrong partition.
Discussed during the 2023-09-11 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as it violates the following criterion: "the installer must be able to: ... Assign mount points to existing storage volumes" on webUI. While the triggering condition is not super common, the potential consequences are catastrophic enough that we believe it should block release. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-11/f39-blocker-review.2023-09-11-16.00.txt
Final solution to this will be tricky, however, I would like to ask if we are able to show an error to user when this happens, so the user is able to rename BTRFS and continue? We can provide the final fix later if that is requested.
So we are proposing two solutions: - Show an error and allow user to fix the issue. - This could be a bit tricky because blivet-gui does not allow renaming of the devices. - Show the fatal error - https://github.com/rhinstaller/anaconda/pull/5165 Both of these fixes could be reasonably done and we can then work on a final solution which could be delivered later. Is there a preference on which one you want to have?
As webUI has been deferred to F40 and this bug is specific to the webUI flow, it is clearly no longer a blocker. Given that, I think just working on the long-term solution (...in English, using the term you used is...ahem...not usually advised, as it's the very specific translation of a certain WWII-related German phrase...) in Rawhide is fine, we probably don't need a short-term hack.
actually, the logical thing to do is to defer the blocker status to F40, I guess.
Until the proper solution will be implemented, the UI now prohibits the user to go ahead with 'Mount point assignment' installation scenario, if there are devices with non-unique names. See upstream PR https://github.com/rhinstaller/anaconda/pull/5165
That sounds like it should make this not a blocker, but out of interest, did we ever get to the "proper solution" here? Kamil, can you re-test with current F40 and see if this still seems like a blocker? Thanks!
https://github.com/rhinstaller/anaconda/pull/5165 is just a workaround for this issue, WIP solution (not using name as a unique device identifier) is here: https://github.com/rhinstaller/anaconda/pull/5435
(In reply to Adam Williamson from comment #18) > Kamil, can you re-test with current F40 and see if this still seems like a > blocker? Thanks! The workaround seems to be working well. Anaconda no longer allows me to proceed with installation when two devices have the same label. Clearing the blocker flags.
OK, let's update a few more fields to make this bug about the current case, then.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.