When using a netinstall with a custom kickstart containing autopart directives and a package selection that is determined to be invalid, Anaconda will wipe the disk and prepare it for installation, only for the installation to fail. Reproducible: Always Steps to Reproduce: 1. Set up Anaconda with a kickstart to wipe and autopartition the disk with an intentionally broken package set Actual Results: Anaconda wipes the disk and then runs the package transaction test and fails. Expected Results: Anaconda first runs the package transaction test and fails without wiping the system.
This is also possible with the Fedora Server DVD install.
Proposed as a Blocker for 40-beta by Fedora user ngompa using the blocker tracking app because: I'm not exactly sure on the criterion, it seems to intersect between failure handling and package selection handling. But leaving systems broken as a result of a failure in Anaconda feels like a blocker.
This is particularly bad because it can mean that a system is rendered unbootable because Anaconda blows away the ESP before verifying that it can actually install something.
I doubt this is a viable blocker because I would expect it's worked this way since before Fedora existed. It's kind of the natural result you get by implementing an RH-ish installer: first you wipe the disk, then you run the payload deployment. The transaction verification is part of the package install process, dnf/rpm do it. anaconda isn't doing it itself. I expect it would be possible to design a more sophisticated workflow where anaconda asks dnf/rpm to test the transaction before doing the disk stuff (then hopefully can skip repeating it when it comes to actually install the packages), but if I'm right about this being how it's behaved forever, I don't really see how it can suddenly be a release blocker. You might want to test, say, Fedora Core 1 and see if it's the same. :D
I have a feeling that we are not able to check transaction errors before we download the packages, and as expected we can't download the package set until we have a place to do that which means storage has to be created. Neal could you please share a steps to reproduce here? I wonder how you broke the transaction.
(In reply to Jiri Konecny from comment #5) > I have a feeling that we are not able to check transaction errors before we > download the packages, and as expected we can't download the package set > until we have a place to do that which means storage has to be created. > Could we not initialize ramdisk storage instead? And what about when we're using the local DVD repo source? There's no downloading there. > Neal could you please share a steps to reproduce here? I wonder how you > broke the transaction. I don't have the sample right now, but I'll try to get one for you.
(In reply to Neal Gompa from comment #6) > (In reply to Jiri Konecny from comment #5) > > I have a feeling that we are not able to check transaction errors before we > > download the packages, and as expected we can't download the package set > > until we have a place to do that which means storage has to be created. > > > > Could we not initialize ramdisk storage instead? And what about when we're > using the local DVD repo source? There's no downloading there. > Err, I meant that we could use ramdisk storage instead if there's enough RAM available, since we know how much we're downloading.
Yes, we are downloading packages into RAM but that could be done only in some cases. You have to have memory to download these and changing the workflow for only some cases would make the installation process inconsistent and confusing to people. Also it would put more burden on developers for this special case. I don't think this is feasible solution for the team to implement and maintain. Especially when these cases are pretty rare.
(In reply to Jiri Konecny from comment #8) > Yes, we are downloading packages into RAM but that could be done only in > some cases. You have to have memory to download these and changing the > workflow for only some cases would make the installation process > inconsistent and confusing to people. Also it would put more burden on > developers for this special case. > Actually, you are downloading into RAM in all cases: https://github.com/rhinstaller/anaconda/blob/83fe8617dfb4abb1ac79087aa8ff4c9a3f2f8d50/pyanaconda/modules/payloads/payload/dnf/dnf_manager.py#L56 The DNF_CACHE_DIR is set to a location in /tmp, which is a tmpfs. It doesn't overflow to disk. At this point, I'm not sure *why* you don't re-order things to run the transaction check *before* partitioning. > I don't think this is feasible solution for the team to implement and > maintain. Especially when these cases are pretty rare. This is *not* rare when people are building kickstarts from scratch. It's simple enough to cause a failure by having either a typo in the package name or requesting mutually exclusive packages (like "curl" and "curl" minimal with a glob "curl*").
-4 in https://pagure.io/fedora-qa/blocker-review/issue/1439 , marking rejected.
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.
This is effectively an RFE, so tagging as such. That will preserve it from the EOL reaper.
(In reply to Jiri Konecny from comment #8) > Yes, we are downloading packages into RAM ... Would it be feasible to just get all the package metadata at first, for the purpose of running the transaction check? The payloads aren't required to just do that, are they? > ... Especially when these cases are pretty rare. That ain't been the case for me. I've been fighting transaction failure crashes for ages. ~1800 packages are OK, but ~7000 and anaconda crashes.
An idea just came to me: If the package source is local (e.g. DVD, disk, flash drive), instead of "downloading" (i.e., copying), why not just create a symlink farm? I.e., instead of copies, make symlinks to the source. I don't know how python does the copying, but to illustrate if it were being done in a shell, it would just be 'ln -s src dest' instead of 'cp src dest' (assuming 'src' is an absolute path, but you could get fancy and work around that with intermediary symlinks, or tweaking the src path with something like 'realpath'). OK, I hear you say that few people install from a local copy. But if it's as easy to implement as I imagine, why not? (BTW, an NFS source might quality as "local", too, at least if it's served from a LAN.)