Bug 1298126 - Devel subpackage of kernel should require versioned main package (kernel-devel >> kernel)
Summary: Devel subpackage of kernel should require versioned main package (kernel-deve...
Keywords:
Status: CLOSED DUPLICATE of bug 1450577
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedFreezeException
: 1062997 (view as bug list)
Depends On:
Blocks: depchain 1294173
TreeView+ depends on / blocked
 
Reported: 2016-01-13 10:16 UTC by Raphael Groner
Modified: 2017-12-18 20:53 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-18 20:53:46 UTC
Type: Bug


Attachments (Terms of Use)

Description Raphael Groner 2016-01-13 10:16:03 UTC
Description of problem:
Updates of kernel package break dkms. DNF introduces a new behaviour with thenew --best --allowerasing options. that was not seen with yum. If a new kernel update gets applied, kernel-devel stays in the system with the old version. We can not build modules for the new kernel, e.g. automatically via dkms. Package kernel-devel needs to be manually updated afterwards. Is that intentionally? I am aware that there can be more than one kernel be installed for grub options, but one source only via kernel-devel. An unexperienced user gets confused and is forced to stop dkms related third party software.

Possible fix:

%package devel
Requires: kernel-devel = %{version}-%{release}


Version-Release number of selected component (if applicable):
-

How reproducible:
always

Steps to Reproduce:
1. see below
2.
3.

Actual results:
dnf refuses to update kernel-devel package without more user intervention

Expected results:
kernel-devel always keeps the same version as kernel main package

Additional info:
[root@farny ~]# LC_ALL=C dnf update kernel-devel
Last metadata expiration check performed 0:39:35 ago on Fri Dec 25 08:32:04 2015.
Dependencies resolved.
================================================================================
 Package                   Arch        Version              Repository     Size
================================================================================
Removing:
 kernel                    x86_64      4.2.5-201.fc22       @updates        0  
 kernel-core               x86_64      4.2.5-201.fc22       @updates       42 M
 kernel-modules            x86_64      4.2.5-201.fc22       @updates       17 M
 kernel-modules-extra      x86_64      4.2.5-201.fc22       @updates      2.1 M
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 kernel-devel              x86_64      4.2.8-200.fc22       updates       9.7 M

Transaction Summary
================================================================================
Remove  4 Packages
Skip    1 Package

Installed size: 61 M
Is this ok [y/N]: 
Operation aborted.
[root@farny ~]# LC_ALL=C dnf update kernel-devel --best --allowerasing
Last metadata expiration check performed 0:39:58 ago on Fri Dec 25 08:32:04 2015.
Dependencies resolved.
================================================================================
 Package                   Arch        Version              Repository     Size
================================================================================
Installing:
 kernel-devel              x86_64      4.2.8-200.fc22       updates       9.7 M
Removing:
 kernel                    x86_64      4.2.5-201.fc22       @updates        0  
 kernel-core               x86_64      4.2.5-201.fc22       @updates       42 M
 kernel-devel              x86_64      3.19.7-200.fc21      @System        35 M
 kernel-devel              x86_64      4.1.3-100.fc21       @System        36 M
 kernel-devel              x86_64      4.1.4-200.fc22       @updates       36 M
 kernel-modules            x86_64      4.2.5-201.fc22       @updates       17 M
 kernel-modules-extra      x86_64      4.2.5-201.fc22       @updates      2.1 M

Transaction Summary
================================================================================
Install  1 Package
Remove   7 Packages

Total download size: 9.7 M
Is this ok [y/N]: y
Downloading Packages:
kernel-devel-4.2.8-200.fc22.x86_64.rpm          4.9 MB/s | 9.7 MB     00:01    
--------------------------------------------------------------------------------
Total                                           3.0 MB/s | 9.7 MB     00:03     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : kernel-devel-4.2.8-200.fc22.x86_64                          1/8 
  Erasing     : kernel-4.2.5-201.fc22.x86_64                                2/8 
  Erasing     : kernel-devel-3.19.7-200.fc21.x86_64                         3/8 
  Erasing     : kernel-devel-3.19.7-200.fc21.x86_64                         4/8 
  Erasing     : kernel-devel-3.19.7-200.fc21.x86_64                         5/8 
  Erasing     : kernel-modules-extra-4.2.5-201.fc22.x86_64                  6/8 
  Erasing     : kernel-modules-4.2.5-201.fc22.x86_64                        7/8 
  Erasing     : kernel-core-4.2.5-201.fc22.x86_64                           8/8 
warning: file /lib/modules/4.2.5-201.fc22.x86_64/updates: remove failed: No such file or directory
  Verifying   : kernel-devel-4.2.8-200.fc22.x86_64                          1/8 
  Verifying   : kernel-core-4.2.5-201.fc22.x86_64                           2/8 
  Verifying   : kernel-devel-3.19.7-200.fc21.x86_64                         3/8 
  Verifying   : kernel-devel-4.1.3-100.fc21.x86_64                          4/8 
  Verifying   : kernel-devel-4.1.4-200.fc22.x86_64                          5/8 
  Verifying   : kernel-modules-4.2.5-201.fc22.x86_64                        6/8 
  Verifying   : kernel-4.2.5-201.fc22.x86_64                                7/8 
  Verifying   : kernel-modules-extra-4.2.5-201.fc22.x86_64                  8/8 

Removed:
  kernel.x86_64 4.2.5-201.fc22                                                  
  kernel-core.x86_64 4.2.5-201.fc22                                             
  kernel-devel.x86_64 3.19.7-200.fc21                                           
  kernel-devel.x86_64 4.1.3-100.fc21                                            
  kernel-devel.x86_64 4.1.4-200.fc22                                            
  kernel-modules.x86_64 4.2.5-201.fc22                                          
  kernel-modules-extra.x86_64 4.2.5-201.fc22                                    

Installed:
  kernel-devel.x86_64 4.2.8-200.fc22                                            

Complete!

[root@farny ~]# /etc/init.d/vboxdrv setup
Stopping VirtualBox kernel modules                         [  OK  ]
Uninstalling old VirtualBox DKMS kernel modules            [  OK  ]
Trying to register the VirtualBox kernel modules using DKMS[  OK  ]
Starting VirtualBox kernel modules                         [  OK  ]

Comment 1 Raphael Groner 2016-01-13 10:30:12 UTC
Possible fix (fixed the typo in my original post, comment #0):

%package devel
Requires: kernel = %{version}-%{release}

Comment 2 Josh Boyer 2016-01-13 13:44:50 UTC
(In reply to Raphael Groner from comment #0)
> Description of problem:
> Updates of kernel package break dkms. DNF introduces a new behaviour with
> thenew --best --allowerasing options. that was not seen with yum. If a new
> kernel update gets applied, kernel-devel stays in the system with the old
> version. We can not build modules for the new kernel, e.g. automatically via
> dkms. Package kernel-devel needs to be manually updated afterwards. Is that
> intentionally? I am aware that there can be more than one kernel be
> installed for grub options, but one source only via kernel-devel. An
> unexperienced user gets confused and is forced to stop dkms related third
> party software.

This is a dnf problem.  The kernel-devel package intentionally doesn't require the main kernel package because you do not need the main kernel package to build against.  The kernel-devel package has historically been used to build modules for multiple kernel versions on the same machine.

There are probably other bugs open for this somewhere, but I can't remember their numbers or find them in the 62M of bugmail I have.

Comment 3 Zbigniew Jędrzejewski-Szmek 2016-01-13 21:02:37 UTC
(In reply to Raphael Groner from comment #1)
> Possible fix (fixed the typo in my original post, comment #0):
> 
> %package devel
> Requires: kernel = %{version}-%{release}
Shouldn't this be 'Requires: kernel%{?_isa} = %{version}-%{release}'?

(In reply to Josh Boyer from comment #2)
> This is a dnf problem.  The kernel-devel package intentionally doesn't
> require the main kernel package because you do not need the main kernel
> package to build against.
Maybe Recommends not Requires? dnf would install it by default, and it would still be possible to avoid installation if wanted.

Comment 4 Honza Silhan 2016-01-19 14:26:21 UTC
Yes, there should be weak dependency as it's not a requirement of the package. We will get touch with kernel packaging and let them know how it should be packaged correctly so even depsolver could know how to deal with them.

Comment 5 Jan Kurik 2016-02-24 15:33:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 6 Fedora Blocker Bugs Application 2016-02-27 19:08:01 UTC
Proposed as a Freeze Exception for 24-alpha by Fedora user raphgro using the blocker tracking app because:

  Jan Silhan 2016-01-19 15:26:21 CET

Yes, there should be weak dependency as it's not a requirement of the package. We will get touch with kernel packaging and let them know how it should be packaged correctly so even depsolver could know how to deal with them.

Comment 7 Kamil Páral 2016-03-07 18:18:09 UTC
Discussed at today's blocker review meeting [1]. Rejected as a freeze exception - there doesn't seem to be anything here which would actually be helped by a freeze exception. This does not involve release media and can't be easily fixed by pushing to updates-testing, which is still enabled by default. It can be re-proposed with a clearer justification.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-07/

Comment 8 Josh Boyer 2016-03-07 18:39:41 UTC
(In reply to Jan Silhan from comment #4)
> Yes, there should be weak dependency as it's not a requirement of the
> package. We will get touch with kernel packaging and let them know how it
> should be packaged correctly so even depsolver could know how to deal with
> them.

This never happened as far as I know.  I'd love to see suggestions.

Comment 9 Edgar Hoch 2016-06-16 13:05:49 UTC
I am not sure if this describes the same problem, but I think so:

We have servers running for a long time without reboot. For example:

# uname -r
4.4.6-301.fc23.x86_64

In the meantime there was installed more than three new kernel versions by dnf-automatic:

# rpm -q kernel kernel-devel
kernel-4.4.6-301.fc23.x86_64
kernel-4.5.5-201.fc23.x86_64
kernel-4.5.6-200.fc23.x86_64
kernel-devel-4.4.9-300.fc23.x86_64
kernel-devel-4.5.5-201.fc23.x86_64
kernel-devel-4.5.6-200.fc23.x86_64

The problem is, that there are three kernel packages and three kernel-devel packages, but the version numbers doesn't agree. The oldest kernel package version and the oldest kernel-devel package version differ.

When an update of a akmod package occurs, it tries to build a kmod package for the new version against the current running kernel. But this fails because the kernel source required for the kmod build is missing, because kernel-devel for the running kernel version was automatically removed sometimes in the past. (We had installed it.)

For example, we have servers that act as GPU servers for CUDA software. Today I got the error message (same server used as for examples above):

# nvidia-smi 
Failed to initialize NVML: Driver/library version mismatch

I checked the versions and what to do for building the new driver module.

# rpm -q --scripts akmod-nvidia
posttrans scriptlet (using /bin/sh):
nohup /usr/sbin/akmods --from-akmod-posttrans --akmod nvidia &> /dev/null &

# /usr/sbin/akmods --from-akmod-posttrans --akmod nvidia
Checking kmods exist for 4.4.6-301.fc23.x86_64             [  OK  ]
Files needed for building modules against kernel
4.4.6-301.fc23.x86_64 could not be found as the following
directories are missing:
/usr/src/kernels/4.4.6-301.fc23.x86_64/
/usr/lib/modules/4.4.6-301.fc23.x86_64/build/Is the correct[FEHLGESCHLAGEN]ckage installed?


I have tried to install the kernel-devel package for the current running kernel, but it was not found. It seems it was removed too early from the repositories. I think all released kernel packages for a Fedora release should stay on the repositories.

[root@kornweihe ~]# LANG=C dnf list all kernel-devel
Last metadata expiration check: 3:44:17 ago on Thu Jun 16 11:06:09 2016.
Installed Packages
kernel-devel.x86_64                                      4.4.9-300.fc23                                       @updates
kernel-devel.x86_64                                      4.5.5-201.fc23                                       @updates
kernel-devel.x86_64                                      4.5.6-200.fc23                                       @updates

# LANG=C dnf install kernel-devel-4.4.6-301.fc23.x86_64
Last metadata expiration check: 3:44:56 ago on Thu Jun 16 11:06:09 2016.
No package kernel-devel-4.4.6-301.fc23.x86_64 available.
Dependencies resolved.
Nothing to do.
Complete!
# LANG=C dnf downgrade kernel-devel-4.4.6-301.fc23.x86_64
Last metadata expiration check: 3:45:10 ago on Thu Jun 16 11:06:09 2016.
No package kernel-devel-4.4.6-301.fc23.x86_64 available.
Error: Nothing to do.

I could try to find the old package on koji.fedoraproject.org and download and install it manually. At least it is available there.


But this behavior breaks the automatic build of new driver modules for new versions of extern driver packages with akmod, like nvidia-driver, wl, VirtualBox - to list some of them.

I use akmod because kmod packages of external software has some delay of creation some times and I don't want to delay the installation of new kernel versions because of breaking dependencies for some kmod packages.


The behaviour we need for working with akmod:

If a kernel package stays installed because it is the version of the current running kernel, and kernel-devel for this kernel version is installed, it should stay installed too and must not removed by updates.

kernel-devel should removed by updates only when the kernel package of the same version is removed.

Comment 10 Fedora Admin XMLRPC Client 2016-07-08 09:33:00 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Jaroslav Mracek 2017-05-04 12:18:13 UTC
*** Bug 1062997 has been marked as a duplicate of this bug. ***

Comment 12 Jaroslav Mracek 2017-05-05 06:51:45 UTC
I am really sorry but we cannot solve the problem. There are several reasons and I will try to highlight some of them.

1. The first question if every user requires same version of package and devel package on system? I think that no, but if yes the problem will be easily solved by hard dependency (for that solution it is necessary to make request on each package to add requires to devel packages, because dnf delivery solution requested by user based on packaging rules).

2. Often different versions of devel kernel packages and kernel providing packages is due to protection of running kernel package but not protection of devel package. If oldest kernel is running kernel, dnf removes oldest kernel devel package but not oldest package that provides kernel (kernel-core). This is not nice behavior, but if devel package do not requires kernel package we cannot do much because by binding kernel devel to kernel we prohibit differences in version between those packages (dnf will act like requires in devel package is present, therefore we have behavior like in #1)

3. Proposed weak dependency solution will not solve the problem.

I am really sorry but DNF should support only general solution but in this case there is no such a option, therefore I have to close the request.

Comment 13 Raphael Groner 2017-05-05 10:24:59 UTC
Jaroslav, thanks for your explanation. But still I think this bug should stay as open. Maybe someone finds a good solution.

Could a meta package solve it somehow or a workaround by comps?

Comment 14 Jaroslav Mracek 2017-05-05 11:26:36 UTC
Well ok, but in this case I think that it will be better to change a component to kernel, because they can provide a solution on packaging level.

Comment 15 Nicolas Chauvet (kwizart) 2017-12-18 20:53:46 UTC
(In reply to Raphael Groner from comment #0)
> Description of problem:
> Updates of kernel package break dkms. DNF introduces a new behaviour with
> thenew --best --allowerasing options. that was not seen with yum. If a new
> kernel update gets applied, kernel-devel stays in the system with the old
Here I stop.
(Rewind to the original message)
While I disagree with this ticket original title (the kernel-devel has strictly not point to require a kernel, as explained by Josh in c#2)
In your original post, you describe the really opposite problem: you have a kernel updated and the kernel-devel that "stays behind".

Boolean dependencies could allow to accurately describe what is the requirement.
Basically from a given kernel package: "if a kernel-devel is installed, then I need this kernel-devel >= %{version}"

I'm going to suggest looking forward 1450577

*** This bug has been marked as a duplicate of bug 1450577 ***


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