Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.The installer no longer installs earlier versions of packages
Previously, the installer did not correctly load the DNF configuration file during the installation process. As a consequence, the installer sometimes installed earlier versions of select packages in the RPM transaction.
This bug has been fixed, and only the latest versions of packages are now installed from the installation repositories. In cases where it is impossible to install the latest versions of the packages, the installation fails as expected.
Description of problem:
Given a kickstart file, if you add deprecated packages (eg. langtable-data) to the packages to be installed, the DNF transaction will end up trying to downgrade packages. However, since older packages are potentially not available in the repository, the transaction error message the user is presented with may look like this (random example):
14:06:57,611 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/w/webkit2gtk3-jsc-2.24.4-2.el8_1.x86_64.rpm
14:06:57,612 CRT dnf: Package "webkit2gtk3-jsc-2.24.4-2.el8_1.x86_64" from local repository "LocalRHEL-AppStream" has incorrect checksum
14:06:57,682 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/l/libreoffice-core-6.0.6.1-20.el8.x86_64.rpm
14:06:57,682 CRT dnf: Package "libreoffice-core-1:6.0.6.1-20.el8.x86_64" from local repository "LocalRHEL-AppStream" has incorrect checksum
14:06:57,684 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/l/libreoffice-draw-6.0.6.1-20.el8.x86_64.rpm
This looks like there is a problem with the checksum, but the real issue is the file/package isn't available since the dnf transaction tried to downgrade to package not available.
Version-Release number of selected component (if applicable): 8.x
How reproducible: Always
Steps to Reproduce:
1. Use reposync to fetch the relevant RHEL 8(.3) repositories
2. Add any package that has been deprecated from 8.2 to 8.3 to your kickstart file
3. Use this as installation source during a RHEL 8.3 install
Actual results:
Error message is misleadning and it's anyway questionable if Anaconda should allow downgrades during the DNF transaction - but there might be reasons.
Expected results:
Better error message and/or downgrading during the DNF transaction isn't allowed unless explicitly asked for (kickstart config option?)
Additional info:
Linking customer case.
Hi, thank you a lot for investigation. If the same issue is happening also for the direct `yum` calls then it's not a specific to Anaconda but rather problem DNF behavior.
Switching component to DNF.
With direct yum calls, it's obvious. The point here is that Anaconda should catch this somehow and provide the user with a more meaningful error message.
And my additional point was that we should potentially think about if Anaconda should run DNF in a away that would prevent downgrading at all, since this will in almost all cases lead to a failure, as usually only the latest packages are available in the repositories.
Oliver
Reassigning back to anaconda based on the previous comment.
Comment 6Pavla Kratochvilova
2020-11-23 15:21:02 UTC
After additional discussion, I am reassigning this back to dnf, because the error message should probably be improved already in dnf.
As for the question whether Anaconda should run DNF in a way that would prevent downgrades, I don't think that's what's happening, because Anaconda just installs all the packages (it doesn't do any upgrades/downgrades). I'd say the problem is more likely in repositories (having inconsistent repodata).
Based on the comment 13, I'm removing the FutureFeature because this seems like inconsistency in the Anaconda configuration. We should investigate the reasoning for not loading the best= option.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7462
Description of problem: Given a kickstart file, if you add deprecated packages (eg. langtable-data) to the packages to be installed, the DNF transaction will end up trying to downgrade packages. However, since older packages are potentially not available in the repository, the transaction error message the user is presented with may look like this (random example): 14:06:57,611 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/w/webkit2gtk3-jsc-2.24.4-2.el8_1.x86_64.rpm 14:06:57,612 CRT dnf: Package "webkit2gtk3-jsc-2.24.4-2.el8_1.x86_64" from local repository "LocalRHEL-AppStream" has incorrect checksum 14:06:57,682 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/l/libreoffice-core-6.0.6.1-20.el8.x86_64.rpm 14:06:57,682 CRT dnf: Package "libreoffice-core-1:6.0.6.1-20.el8.x86_64" from local repository "LocalRHEL-AppStream" has incorrect checksum 14:06:57,684 CRT dnf: Error opening file for checksum: /run/install/LocalRHEL-AppStream.nfs/Packages/l/libreoffice-draw-6.0.6.1-20.el8.x86_64.rpm This looks like there is a problem with the checksum, but the real issue is the file/package isn't available since the dnf transaction tried to downgrade to package not available. Version-Release number of selected component (if applicable): 8.x How reproducible: Always Steps to Reproduce: 1. Use reposync to fetch the relevant RHEL 8(.3) repositories 2. Add any package that has been deprecated from 8.2 to 8.3 to your kickstart file 3. Use this as installation source during a RHEL 8.3 install Actual results: Error message is misleadning and it's anyway questionable if Anaconda should allow downgrades during the DNF transaction - but there might be reasons. Expected results: Better error message and/or downgrading during the DNF transaction isn't allowed unless explicitly asked for (kickstart config option?) Additional info: Linking customer case.