Bug 2536815
| Summary: | dnf command not available in kickstart, f45 netboot installer | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | kompost <lars.bohl> |
| Component: | lorax | Assignee: | Brian Lane <bcl> |
| Status: | MODIFIED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 45 | CC: | alpha, anaconda-maint, bcl, christopher, kkoukiou, lukas.ruzicka, mkolman, reallylongword, rhbz, w, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | AcceptedFreezeException RejectedBlocker | ||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2406955 | ||
|
Description
kompost
2026-09-17 19:54:33 UTC
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 |