Bug 2210694
| Summary: | Config error: Parsing file "/etc/dnf/dnf.conf" failed: Parsing file '/etc/dnf/dnf.conf' failed: IniParser: Missing section header at line 1 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Pazdziora <jpazdziora> |
| Component: | dnf | Assignee: | Jan Kolarik <jkolarik> |
| Status: | POST --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | amatej, daniel.mach, jmracek, jpazdziora, jrohel, lslebodn, mblaha, mburket, packaging-team-maint, pkratoch, rmeggins, rpm-software-management, valdis.kletnieks |
| Target Milestone: | --- | Keywords: | Regression, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| 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: | |||
|
Description
Jan Pazdziora
2023-05-29 07:23:42 UTC
In https://src.fedoraproject.org/rpms/dnf/c/e1d55d6da26f89662e3669d910aead08cde2a7e2?branch=rawhide I see Remove ownership of dnf.conf so the problem is caused by a change in the dnf component. Even if the root cause is likely that the Fedora container image assumes that the file exists and just appends that tsflags line there, I believe it's the dnf maintainers that should set the assumptions and expected behaviour before landing a change that breaks the containerized use-cases. (In reply to Jan Pazdziora from comment #1) > In > https://src.fedoraproject.org/rpms/dnf/c/ > e1d55d6da26f89662e3669d910aead08cde2a7e2?branch=rawhide I see Remove > ownership of dnf.conf so the problem is caused by a change in the dnf > component. > > Even if the root cause is likely that the Fedora container image assumes > that the file exists and just appends that tsflags line there, I believe > it's the dnf maintainers that should set the assumptions and expected > behaviour before landing a change that breaks the containerized use-cases. That change makes dnf move /etc/dnf/dnf.conf to dnf.conf.rpmsave, so the next run of dnf doesn't see any of the config variables that used to be there. I spotted this bug report after I opened bug #2210931 against DNF. *** Bug 2210931 has been marked as a duplicate of this bug. *** This is temporarily fixed by untagging the dnf packages introducing these changes from Rawhide. We will investigate the problem in the meanwhile. The default dnf.conf now should be like: """ # see `man dnf.conf` for defaults and possible options [main] """ Sorry, I meant that is how default dnf.conf should look like after introducing the proposed changes... Today I was testing two use cases with new dnf and dnf5 packages already in nightly copr repos. Setup ----- 1. podman run --rm -ti registry.fedoraproject.org/fedora:rawhide sh 2. dnf install dnf-plugins-core 3. dnf copr enable rpmsoftwaremanagement/dnf-nightly Usecase A - upgrade to newest dnf, then install newest dnf5 ----------------------------------------------------------- 4. dnf upgrade dnf # now /etc/dnf/dnf.conf doesn't exist as nobody owns it without the newest dnf5 package being present # /etc/dnf/dnf.conf.rpmsave is created as the backup of the original config file 5. dnf copr enable rpmsoftwaremanagement/dnf5-unstable 6. dnf install dnf5 # now /etc/dnf/dnf.conf is created, containing the dnf5 defaults: """ # see `man dnf.conf` for defaults and possible options [main] """ Usecase B - install newest dnf5, upgrade dnf, replace dnf in a single transaction --------------------------------------------------------------------------------- 4. dnf copr enable rpmsoftwaremanagement/dnf5-unstable 5. dnf install dnf5 # /etc/dnf/dnf.conf remains unchanged # /etc/dnf/dnf.conf.rpmnew is the new empty config file delivered by the dnf5 So it seems, using the nightly copr repos, it is currently working as expected. In Rawhide, we are now working with dependent components using the DNF CLI needed in the build environment to manage their transition to DNF5 CLI. After that is done and tested, we are planning to release new versions into the Rawhide. I guess the original issue was caused by untagging the dnf5 package first, while the new dnf package remained in the Rawhide for some time. I apologize for not realizing that the use case for users who simply upgrade dnf without any connection to dnf5 was not included. For these users who haven't installed the latest libdnf5 dependency, it is possible to install/upgrade dnf without dnf.conf being present on the system. This should be fixed now by this PR: https://github.com/rpm-software-management/dnf/pull/1937. Therefore I am switching this to POST. Important - the original cause of the bug is not in DNF or in DNF5. The problem is in particular packages that modifies blindly `dnf.conf` by adding come configuration to the end of the file. It is an approach that easily breaks DNF or configuration because dnf.conf may contain more sections then `[main]`. Our solution will again move the cause of the problem to the background. (In reply to Jaroslav Mracek from comment #9) > Important - the original cause of the bug is not in DNF or in DNF5. The > problem is in particular packages that modifies blindly `dnf.conf` by adding > come configuration to the end of the file. It is an approach that easily > breaks DNF or configuration because dnf.conf may contain more sections then > `[main]`. Except that tsflags=nodocs is not added by any package but by the Fedora base container image definition. Can you please file a bug to track any needed change in the approach for the container images with the right product / component? > Our solution will again move the cause of the problem to the background. Could you elaborate what you mean by that? This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39. |