Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1824102 - dnf fails to distro-sync on openSUSE Tumbleweed as it cannot remove kernel-default
Summary: dnf fails to distro-sync on openSUSE Tumbleweed as it cannot remove kernel-de...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: dnf-community
TreeView+ depends on / blocked
 
Reported: 2020-04-15 10:33 UTC by Dan Čermák
Modified: 2023-05-25 19:30 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-25 19:30:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Novell 1170232 0 None None None 2020-04-22 14:30:01 UTC

Description Dan Čermák 2020-04-15 10:33:12 UTC
Description of problem:
I am running dnf on openSUSE Tumbleweed and have been running recently into the issue that dnf can no longer distro-sync to the newest snapshot. Instead it reports the error:
Problem: The operation would result in removing the following protected packages: kernel-default

Adding --allowerasing or --skip-broken does not fix the issue


Version-Release number of selected component (if applicable):
dnf --version
4.2.19
  Installed: dnf-0:4.2.19-1.2.noarch at Sat Mar 14 07:04:12 2020
  Built    : https://bugs.opensuse.org at Mon Mar  9 10:41:33 2020

  Installed: rpm-0:4.15.1-4.1.x86_64 at Sun Apr 12 07:42:37 2020
  Built    : https://bugs.opensuse.org at Wed Apr  8 18:00:36 2020



Steps to Reproduce:
1. Get openSUSE Tumbleweed, install dnf, copy the zypper repos over to dnf's config directory.
2. Try to run dnf distro-sync


Actual results:
On kernel updates dnf sometimes does not want to upgrade as it cannot remove kernel-default.

Expected results:
It should upgrade the kernel and remove the older one in the same way zypper does (but, you know, without using zypper)

Comment 1 Dan Čermák 2020-04-15 11:09:20 UTC
I have uploaded the output of `dnf --debugsolver distro-sync` to firefox send: https://send.firefox.com/download/96d5bbc3ccf9cfaf/#e8v7kSttItMK8xPIb87Oeg (unfortunately that link will expire in 7 days or 100 downloads, so please grab a copy of it soon-ish; I can of course re-upload it).

Comment 2 Marek Blaha 2020-04-20 14:50:44 UTC
Thanks for reporting and debugsolver data.

Please can you provide a few additional pieces of information?

- versions of other parts of dnf stack (`rpm -q dnf libdnf libsolv`)
- version of the running kernel (`uname -a`)
- dnf configuration file (`cat /etc/dnf/dnf.conf`)
- limit the distro-sync only to kernel-default package and try to find out minimal set of repositories for which the bug occurs. Please provide debugsolver data for this command. I suppose something like `dnf distro-sync --debugsolver --repoid=download.opensuse.org-oss,openSUSE-20190717-0 kernel-default` could do the job.

Comment 3 Dan Čermák 2020-04-20 21:44:30 UTC
(In reply to Marek Blaha from comment #2)
> Thanks for reporting and debugsolver data.
> 
> Please can you provide a few additional pieces of information?
> 
> - versions of other parts of dnf stack (`rpm -q dnf libdnf libsolv`)

dnf-4.2.19-1.2.noarch
libdnf2-0.45.0-3.1.x86_64
libsolv-devel-0.7.11-1.2.x86_64

> - version of the running kernel (`uname -a`)

Linux Boreas 5.6.4-1-default #1 SMP Mon Apr 13 18:13:21 UTC 2020 (e42da4f) x86_64 x86_64 x86_64 GNU/Linux

> - dnf configuration file (`cat /etc/dnf/dnf.conf`)

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=False
skip_if_unavailable=True

> - limit the distro-sync only to kernel-default package and try to find out
> minimal set of repositories for which the bug occurs. Please provide
> debugsolver data for this command. I suppose something like `dnf distro-sync
> --debugsolver --repoid=download.opensuse.org-oss,openSUSE-20190717-0
> kernel-default` could do the job.

I've uploaded it here: https://send.firefox.com/download/7c323cab824076c2/#JWT7_I9V1e6K4WX1pqbCrQ

Comment 4 Marek Blaha 2020-04-21 13:19:46 UTC
This is my theory what is going on (it still needs further investigation):

From here on I will write kernel-1 instead of kernel-default-5.6.4-1.1.x86_64 and kernel-2 instead of kernel-default-5.6.4-1.2.x86_64 for the sake of readability.

- you have kernel-1 installed and running
- this package is not in repository any more. It was replaced by the version kernel-2
- the newer version kernel-2 obsoletes the kernel-1
- distrosync tries to install kernel-2 (the highest version available in the repos) and the `obsoletes` rule forces removal of kernel-1
- but kernel-1 cannot be removed as dnf protects currently running kernel version (this is the error message you are getting)

I see two basic approaches how to deal with this (both of them are kind of a workaround):
- either exclude kernel-default package from distro-sync
- or reboot with kernel other then 5.6.4 (according to debug data you should have kernel-default-5.6.2-1.3 installed) and then do the distrosync

In fact I'm not sure what is dnf supposed to do in situation that one kernel version obsoletes another and so they cannot be installed in parallel. I'll need to prepare test case for this and play with it a bit.

Comment 5 Dan Čermák 2020-04-21 21:40:14 UTC
(In reply to Marek Blaha from comment #4)
> This is my theory what is going on (it still needs further investigation):
> 
> From here on I will write kernel-1 instead of
> kernel-default-5.6.4-1.1.x86_64 and kernel-2 instead of
> kernel-default-5.6.4-1.2.x86_64 for the sake of readability.
> 
> - you have kernel-1 installed and running
> - this package is not in repository any more. It was replaced by the version
> kernel-2
> - the newer version kernel-2 obsoletes the kernel-1
> - distrosync tries to install kernel-2 (the highest version available in the
> repos) and the `obsoletes` rule forces removal of kernel-1
> - but kernel-1 cannot be removed as dnf protects currently running kernel
> version (this is the error message you are getting)

That makes sense. It also explains why this issue only appears sometimes and not every time.

> 
> I see two basic approaches how to deal with this (both of them are kind of a
> workaround):
> - either exclude kernel-default package from distro-sync
> - or reboot with kernel other then 5.6.4 (according to debug data you should
> have kernel-default-5.6.2-1.3 installed) and then do the distrosync

I can work around this by upgrading the kernel with zypper and the rest with dnf, although I would prefer to use dnf for everything ;-).

> 
> In fact I'm not sure what is dnf supposed to do in situation that one kernel
> version obsoletes another and so they cannot be installed in parallel. I'll
> need to prepare test case for this and play with it a bit.

From a user's perspective it would be preferable if the new kernel just gets installed. But I really cannot judge how this could negatively affect distributions that don't behave like Tumbleweed.

Comment 6 Neal Gompa 2020-04-22 01:42:50 UTC
(In reply to dan.cermak from comment #5)
> (In reply to Marek Blaha from comment #4)
> > This is my theory what is going on (it still needs further investigation):
> > 
> > From here on I will write kernel-1 instead of
> > kernel-default-5.6.4-1.1.x86_64 and kernel-2 instead of
> > kernel-default-5.6.4-1.2.x86_64 for the sake of readability.
> > 
> > - you have kernel-1 installed and running
> > - this package is not in repository any more. It was replaced by the version
> > kernel-2
> > - the newer version kernel-2 obsoletes the kernel-1
> > - distrosync tries to install kernel-2 (the highest version available in the
> > repos) and the `obsoletes` rule forces removal of kernel-1
> > - but kernel-1 cannot be removed as dnf protects currently running kernel
> > version (this is the error message you are getting)
> 
> That makes sense. It also explains why this issue only appears sometimes and
> not every time.
> 
> > 
> > I see two basic approaches how to deal with this (both of them are kind of a
> > workaround):
> > - either exclude kernel-default package from distro-sync
> > - or reboot with kernel other then 5.6.4 (according to debug data you should
> > have kernel-default-5.6.2-1.3 installed) and then do the distrosync
> 
> I can work around this by upgrading the kernel with zypper and the rest with
> dnf, although I would prefer to use dnf for everything ;-).
> 
> > 
> > In fact I'm not sure what is dnf supposed to do in situation that one kernel
> > version obsoletes another and so they cannot be installed in parallel. I'll
> > need to prepare test case for this and play with it a bit.
> 
> From a user's perspective it would be preferable if the new kernel just gets
> installed. But I really cannot judge how this could negatively affect
> distributions that don't behave like Tumbleweed.

So this is a little weird, because I thought that when we tell libsolv to do a dist-upgrade job like this, multiversioned packages like the kernel should be handled correctly as an install job without triggering a removal of the running kernel. We don't see the same issue when system-upgrading to a new Fedora release, and that has all the makings of the same problem, so how does this happen now?

Comment 7 Marek Blaha 2020-04-22 06:49:14 UTC
The problem here is with the 'Obsoletes: kernel-default = <older version>` directive in newer kernel version, which is quite unusual and I do not think Fedora use it.
This prevents dnf from installing both newer and older kernel side by side.

Comment 8 Marek Blaha 2020-04-22 08:45:23 UTC
btw, how exactly does zypper deal with upgrading the kernel?
Does it install both kernels in parallel (and ignores the obsolete). It might not be possible due to the file conflicts because both kernels are in the same version.
Or does the zypper do "classic" update of the kernel if the version of updated kernel is the same?

Comment 9 Neal Gompa 2020-04-22 13:23:41 UTC
(In reply to Marek Blaha from comment #8)
> btw, how exactly does zypper deal with upgrading the kernel?
> Does it install both kernels in parallel (and ignores the obsolete). It
> might not be possible due to the file conflicts because both kernels are in
> the same version.
> Or does the zypper do "classic" update of the kernel if the version of
> updated kernel is the same?

I believe that's what it does. I'm not sure why the Obsoletes is there, and it probably shouldn't be present...

Comment 10 Ben Cotton 2020-08-11 13:18:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 11 Ben Cotton 2022-02-08 21:44:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 12 Ben Cotton 2023-04-25 18:22:10 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 13 Ludek Smid 2023-05-25 19:30:03 UTC
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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