Fedora Account System
Red Hat Associate
Red Hat Customer
dnf4 broken with no alternative in the Everything/netboot installer When running a basic dnf-install: dnf4 -y install --nogpgcheck --releasever=45 --installroot=/mnt/sysroot ugrep We get an error message: Cannot find rpmkeys executable to verify signatures. Error: GPG check FAILED Reproducible: Always Steps to Reproduce: 1. Download the "everything/netboot" installer, f45 beta. I used this one: https://ftp.halifax.rwth-aachen.de/fedora/linux/releases/test/45_Beta/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-45_Beta-1.3.iso In the grub command line, append "inst.ks=https://repo.akusari.net/pflaster/manual.cfg" (as described here: https://codeberg.org/kaputtix/pflaster) Side note: pflaster is not required, any kickstart script with "sleep inf" in "%pre" can be used to reproduce this. 2. Once the "%pre" script of the kickstart is running, switch to a new tmux tab (C-b c) 3. Try to install something using dnf4. For example, run the following commands: sed '/^$/ q' /usr/share/dnf5/repos.d/fedora.repo > /etc/yum.repos.d/fedora.repo mkdir -p /mnt/sysroot dnf4 -y install --nogpgcheck --releasever=45 --installroot=/mnt/sysroot ugrep Actual Results: Cannot find rpmkeys executable to verify signatures. Error: GPG check FAILED Expected Results: Either the dnf4 command above should succeed, or dnf5 should be included in the installer Additional Information: We need dnf to work around the "Unlocked LUKS" limitation (bug 2019455). We are using a LUKS-encrypted home partition, and without the workaround, bug 2019455 would make it impossible to avoid data loss, when recovering a broken system by reinstallation. https://anaconda-installer.readthedocs.io/en/latest/user-guide/troubleshooting/common-bugs.html https://bugzilla.redhat.com/show_bug.cgi?id=2019455 UPDATE: It seems like the other installation media have dnf5 installed. Only Everything/netboot is lacking dnf5. Everything/netboot is the only installer that supports kickstart, though.
Proposed as a Blocker for 45-beta by Fedora user the-rza using the blocker tracking app because: Please consider 2536815 as blocking the f45 beta. The Everything/Netinst installer medium (or any other installer medium too) must have a working dnf4 (or dnf5) available, to work around bugs like 2019455. Otherwise it will be the last straw, the installation medium will be entirely useless for us, and we will have to create our own installation medium.
For some added context, this is may be due to an approved change for F45: https://fedoraproject.org/wiki/Changes/RelocateRpmRepoConfigsToUsr "Legacy RPM package managers (like DNF version 4, YUM, etc.) will not function as system package managers anymore, since the configuration will largely not exist for them anymore."
Thanks Chris, that's good to know. If dnf4 won't work, fine, but then dnf5 should be included in the installer. However: [root@vbox ~]# dnf -bash: dnf: command not found [root@vbox ~]# dnf5 -bash: dnf5: command not found
Proposed as a Blocker for 45-final by Fedora user the-rza using the blocker tracking app because: Since the beta is already out the door, proposing 2536815 as a final blocker instead. dnf, in any form, should be available in the installation medium.
Hmm, while it's fine to have dnf4 in the repos for special uses, at this point, it should be considered strictly legacy. Having it as *the* installer on an image is very unexpected. Can we just update to dnf5 there?
It's not the installer's responsibility to pull in DNF5 in the installation environment. Anaconda does not use to DNF binaries, it uses python3-libdnf5 - therefore it does don't require dnf5. In the past it was incuded in lorax templates [1] [1] https://github.com/weldr/lorax/commit/09802fc86e81c36e24e6b194864ea2a3998a7b61
Clearing my "needinfo" status. I suppose this was accidental, or maybe I don't see what the question is. If it could be avoided, please don't "needinfo" me again, since apparently this exposes my E-Mail address to unauthenticated users. It should not be necessary. When I see questions here in the comments, I will try to answer them anyway.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #5) > Hmm, while it's fine to have dnf4 in the repos for special uses, at this > point, it should be considered strictly legacy. Having it as *the* installer > on an image is very unexpected. Can we just update to dnf5 there? I'm not sure what's pulling in dnf4, but at this point in the F45 cycle don't want to try removing it. Adding dnf5 cmdline tools should be ok, it only adds 3 packages: dnf5 libdnf5-cli sdbus-cpp Here's a PR for rawhide that I'll also backport to F45 if everyone agrees - https://github.com/weldr/lorax/pull/1533
AGREED Delayed Decision (Punt) Discussed at the 2026-09-21 (blocker / freeze exception) review meeting: We suspect this will turn out rejected, but we'd like to ask the current and former installer teams whether use of dnf from the installer environment is/has ever been intended/supported, and look more into the issue the reporter is trying to work around, before making a final decision. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-09-21/f45-blocker-review.2026-09-21-16.01.log.txt
Replying to this remark from the chat log: "if it's true you can't reinstall and reuse an encrypted /home" Yes, that seems to be what the phrase from "common bugs and issues", "Anaconda doesn’t support LUKS devices that are unlocked outside the installer. The device has to be unlocked in Anaconda.", implies. You cannot reinstall with Anaconda when /home is on luks, or lvm-on-luks. Please do try. Confirmation would be nice.
Discussed in 2026-09-28 blocker review meeting: https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-09-28/f45-blocker-review.2026-09-28-16.00.html . This was rejected as a blocker but accepted as a freeze exception issue; it doesn't violate any release criteria, but it's cheap and easy to add dnf5 to the installer environment, it is useful and cannot be fixed post-release, so an FE is appropriate.
Note, we're treating this bug as strictly being for "package manager in installer environment". The issue(s) with reinstalling using an encrypted /home should be reported and investigated separately; it's fine to propose that as a blocker if you think it's a candidate.
https://github.com/weldr/lorax/commit/57e62936234736b6eaddb40c08c8352dc52bcfe1 adding dnf5 was merged for f45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3daa32415c with lorax-45.4-1.fc45 is in testing. I'll mark it as fixing this bug.
FEDORA-2026-3daa32415c (lorax-45.4-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3daa32415c