Bug 1291506 - "dnf reinstall kernel-headers" first reinstalls and then erases same version
"dnf reinstall kernel-headers" first reinstalls and then erases same version
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
22
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-14 20:37 EST by windchine
Modified: 2016-01-05 05:01 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-04 10:04:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description windchine 2015-12-14 20:37:32 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"

How reproducible:
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

Actual results:
No kernel headers installed.

Expected results:
Expect to find current kernel headers in an appropriately named directory off /usr/src/kernels/

Additional info:

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.
Dependencies resolved.
==========================================================================
 Package         Arch       Version         Repository     Size
==========================================================================
Reinstalling:
 kernel-headers  x86_64     4.2.6-201.fc22  updates        1.0 M

Transaction Summary
==========================================================================

Total download size: 1.0 M
Is this ok [y/N]: y
Downloading Packages:
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.
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 

Reinstalled:
  kernel-headers.x86_64 4.2.6-201.fc22                                                                                                                                   
Complete!
Comment 1 Honza Silhan 2015-12-23 09:54:45 EST
(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?
Comment 2 windchine 2015-12-30 11:15:20 EST
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.

Thanks.

As requested:

# rpm -q kernel-headers
kernel-headers-4.2.7-300.fc23.x86_64

# rpm -q kernel-devel
kernel-devel-4.2.7-300.fc23.x86_64
Comment 3 Michal Domonkos 2016-01-04 10:04:06 EST
(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.

Great, thanks!

> 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.

Closing now.

Note You need to log in before you can comment on or make changes to this bug.