Red Hat Bugzilla – Bug 1291506
"dnf reinstall kernel-headers" first reinstalls and then erases same version
Last modified: 2016-01-05 05:01:15 EST
Description of problem:
Kernel headers should be installed but cannot be found. Digest from "dnf reinstall kernel-headers" suggests that package is being installed and then immediately erased all as part of a single transaction.
Version-Release number of selected component (if applicable):
Unknown but F22 install is currently fully updated using "dnf -y update"
dnf downloads "kernel-headers-4.2.6-201.fc22.x86_64.rpm"
Tested on 2 machines, one running x86_64 and the other i686+PAE. Same behaviour for both.
Steps to Reproduce:
1. "dnf reinstall kernel-headers"
2. Kernel headers not present in /usr/src/kernels/
3. dnf report states it has also erased package after reinstalling it
No kernel headers installed.
Expect to find current kernel headers in an appropriately named directory off /usr/src/kernels/
Command digest ...
# dnf reinstall kernel-headers
Failed to synchronize cache for repo 'livna' from 'http://rpm.livna.org/mirrorlist': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling.
Last metadata expiration check performed 2:12:05 ago on Mon Dec 14 22:34:35 2015.
Package Arch Version Repository Size
kernel-headers x86_64 4.2.6-201.fc22 updates 1.0 M
Total download size: 1.0 M
Is this ok [y/N]: y
kernel-headers-4.2.6-201.fc22.x86_64.rpm 1.7 MB/s | 1.0 MB 00:00
Total 570 kB/s | 1.0 MB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Reinstalling: kernel-headers-4.2.6-201.fc22.x86_64 1/2
Erasing : kernel-headers-4.2.6-201.fc22.x86_64 2/2
Verifying : kernel-headers-4.2.6-201.fc22.x86_64 1/2
Verifying : kernel-headers-4.2.6-201.fc22.x86_64 2/2
(In reply to windchine from comment #0)
> Running transaction
> Reinstalling: kernel-headers-4.2.6-201.fc22.x86_64 1/2
> Erasing : kernel-headers-4.2.6-201.fc22.x86_64 2/2
> Verifying : kernel-headers-4.2.6-201.fc22.x86_64 1/2
> Verifying : kernel-headers-4.2.6-201.fc22.x86_64 2/2
We should investigate how the DNF transaction set looks after resolution. If into rpm transaction goes just reinstall demand then rpm is on blame. The total summary does not mention the Erase package.
I don't see any file inside /usr/src/kernels/ dir: `sudo dnf repoquery --releasever=22 kernel-headers -l | grep src`
Do you have kernel-headers on the system after dnf command execution? Can you send output of `rpm -q kernel-headers`, please?
I realize now that the package I needed to install the kernel headers into /usr/src/kernels/ was actually "kernel-devel", not "kernel-headers", so that part of the bug report is spurious.
The misleading transaction report however led me to think that the package was being installed and then removed. Without that report I would likely have reached the correct conclusion and found the correct package to install rather than concluding that dnf or the package metadata were faulty. I think it would be of value if dnf (etc.) could be modified to not issue the spurious "Erasing" message under these conditions.
# rpm -q kernel-headers
# rpm -q kernel-devel
(In reply to windchine from comment #2)
> I realize now that the package I needed to install the kernel headers into
> /usr/src/kernels/ was actually "kernel-devel", not "kernel-headers", so that
> part of the bug report is spurious.
> The misleading transaction report however led me to think that the package
> was being installed and then removed. Without that report I would likely
> have reached the correct conclusion and found the correct package to install
> rather than concluding that dnf or the package metadata were faulty. I think
> it would be of value if dnf (etc.) could be modified to not issue the
> spurious "Erasing" message under these conditions.
The "Erasing" message indeed comes from the rpm transaction set which contains an install element (shown as "Reinstalling") and an erase element (shown as "Erasing") for each reinstall operation. I do agree that this is confusing to the user, though. However, as Jan mentioned, the only conclusive message is the transaction summary towards the end ("Reinstalled:") which works correctly.