Bug 1348766 - "The operation would result in removing the booted kernel" when installonlypkgs is set in dnf.conf
"The operation would result in removing the booted kernel" when installonlypk...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
25
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
: Triaged
: 1347999 1352199 1352240 1359522 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-21 22:44 EDT by Fabiano Franz
Modified: 2016-10-04 14:03 EDT (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-04 14:03:21 EDT
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 Fabiano Franz 2016-06-21 22:44:17 EDT
Description of problem:

Trying to upgrade f23 to f24 (post release) with

sudo dnf upgrade --refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=24

The last operation fails with

Error: The operation would result in removing the booted kernel: kernel-core-4.5.7-200.fc23.x86_64.
 
I tried dnf clean then dnf distro-sync, and system-upgrade with --allowerasing and --best, none of them helped.  

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

dnf-plugin-system-upgrade 0.7.1-1.fc23

How reproducible:

Always

Steps to Reproduce:
1.
2.
3.

Actual results:

Cannot perform the upgrade from f23 to f24.

Error: The operation would result in removing the booted kernel: kernel-core-4.5.7-200.fc23.x86_64.

Expected results:


Additional info:

$ sudo tail -n 20 /var/log/dnf.log

Jun 21 23:31:54 DEBUG --> Finished dependency resolution
Jun 21 23:31:54 DDEBUG timer: depsolve: 4003 ms
Jun 21 23:31:55 INFO Dependencies resolved.
Jun 21 23:31:55 DDEBUG Cleaning up.
Jun 21 23:31:55 SUBDEBUG 
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 60, in main
    return _main(base, args)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 120, in _main
    ret = resolving(cli, base)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 142, in resolving
    base._plugins.run_resolved()
  File "/usr/lib/python3.4/site-packages/dnf/plugin.py", line 82, in fn
    dnf.util.mapall(operator.methodcaller(method), self.plugins)
  File "/usr/lib/python3.4/site-packages/dnf/util.py", line 183, in mapall
    return list(map(fn, *seq))
  File "/usr/lib/python3.4/site-packages/dnf-plugins/protected_packages.py", line 80, in resolved
    raise dnf.exceptions.Error(KERNEL_MSG % kernel_pkg)
dnf.exceptions.Error: The operation would result in removing the booted kernel: kernel-core-4.5.7-200.fc23.x86_64.
Jun 21 23:31:55 CRITICAL Error: The operation would result in removing the booted kernel: kernel-core-4.5.7-200.fc23.x86_64.
Comment 1 Eric Doutreleau 2016-06-22 16:51:33 EDT
I had exactly the same problem

i remove  python3-dnf-plugins-core-0.1.21-2.fc23.noarch

and after that it worked 

hope that helps
Comment 2 Martin Curlej 2016-06-29 12:00:12 EDT
Had the same problem. After uninstalling the python3-dnf-plugins-core package upgraded without problems.(In reply to Eric Doutreleau from comment #1)

> I had exactly the same problem
> 
> i remove  python3-dnf-plugins-core-0.1.21-2.fc23.noarch
> 
> and after that it worked 
> 
> hope that helps
Comment 3 Zbigniew Jędrzejewski-Szmek 2016-06-29 12:29:03 EDT
Removing python3-dnf-plugins-core is a work-around which breaks installonly protection for kernel. DNF should not be trying to remove the installed kernel.

What are the contents of /etc/dnf/dnf.conf, and what kernels do you have installed (rpm -q kernel-core)? Also, if possible, please paste the whole output with the list of packages from dnf system-upgrade.
Comment 4 Eric Doutreleau 2016-06-29 15:02:57 EDT
well i m sorry i make the upgrade.
Comment 5 Ronaldo Rivera 2016-06-29 22:11:23 EDT
I can confirm the workaround by removing python3-dnf-plugins-core-0.1.21-2.fc23.noarch worked for me as well.
Comment 6 Petre 2016-07-01 12:38:47 EDT
Similar problem here. I am on F24.

$ rpm -q kernel-core
kernel-core-4.5.7-300.fc24.x86_64


$ cat /etc/dnf/dnf.conf                                                                                                                                           
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
installonlypkgs=electron

Is it safe to remove python3-dnf-plugins-core and upgrade?
Comment 7 Andrea Zucchelli 2016-07-01 12:41:57 EDT
Same situation as Petre, same kernel same dnf.conf
Comment 8 Fredy 2016-07-01 14:03:35 EDT
I had the same situation than Petre & Andrea and this worked for me :

https://bugzilla.redhat.com/show_bug.cgi?id=1347999#c2
Comment 9 Petre 2016-07-02 14:39:34 EDT
(In reply to Fredy from comment #8)
> I had the same situation than Petre & Andrea and this worked for me :
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1347999#c2


I commented out this line and it worked:

installonlypkgs=electron
Comment 10 Nick Coghlan 2016-07-04 17:26:33 EDT
OK, it looks like the culprit for the immediate problem people are seeing is the https://copr.fedorainfracloud.org/coprs/mosquito/atom/ COPR repository: https://github.com/FZUG/repo/issues/129

It's not specifically related to the system upgrade process, it's related to the electron RPM in that COPR appending the "installonlypkgs=electron" line to /etc/dnf/dnf.conf

That specific case has been resolved in the above linked issue, so if you remove the DNF conf line mentioned above and then do a "dnf upgrade -y", the problem won't come back.

However, that doesn't fix the underlying cause of the misbehaviour: explicitly setting "installonlypkgs" in /etc/dnf/dnf.conf currently removes the implicit kernel protections, which makes that setting unduly hard to use correctly.

Accordingly, I'm changing the affected component for this BZ to dnf-plugins-core, and amending the title to reflect the fact the problem occurs whenever "installonlypkgs" is set in /etc/dnf/dnf.conf and F24 needs to upgrade the kernel, rather than being specific to upgrades from F23.
Comment 11 Paul Jones 2016-07-05 04:38:31 EDT
It appears that this problem now occurs on F23 when doing an update. It is not just when upgrading.

# dnf update
Dependencies resolved.
Error: The operation would result in removing the booted kernel: kernel-core-4.5.7-200.fc23.x86_64.

If you need any further information please let me know.
Comment 12 Igor Gnatenko 2016-07-05 15:22:02 EDT
*** Bug 1347999 has been marked as a duplicate of this bug. ***
Comment 13 Igor Gnatenko 2016-07-05 15:22:04 EDT
*** Bug 1352240 has been marked as a duplicate of this bug. ***
Comment 14 Fedora Admin XMLRPC Client 2016-07-08 05:36:50 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Igor Gnatenko 2016-07-11 07:15:44 EDT
*** Bug 1352199 has been marked as a duplicate of this bug. ***
Comment 16 Igor Gnatenko 2016-07-24 13:14:44 EDT
*** Bug 1359522 has been marked as a duplicate of this bug. ***
Comment 17 Jan Kurik 2016-07-26 01:01:45 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 18 Jaroslav Mracek 2016-09-16 04:29:45 EDT
The problem here is that by default INSTALLONLYPKGS=('kernel', 'installonlypkg(kernel)', 'installonlypkg(kernel-module)', 'installonlypkg(vm)')

But if in dnf.conf is
installonlypkgs=electron

than only electron is installonlypkgs, therefore kernel packages are handled as standard packages.

The question is what we can do? We can introduce installonlypkgs+=electron that will append electron into installonlypkgs, but it doesn't prevent the problem when installonlypkgs=electron in dnf.conf. Or we can say that installonlypkgs=electron mean append electron into list, but it is nonsense because why user cannot completely refactor the group of installonlypkgs.
What do you think? Please your opinion here is really essential.

Anyway in meanwhile I am going to improve the documentation to prevent the problem.
Comment 19 Zbigniew Jędrzejewski-Szmek 2016-09-16 08:17:42 EDT
I'd do the same that systemd does for settings which should "accumulate"
1. "installonlypackages=foo" adds foo to the existing list
2. "installonlypackages=" resets the list

This is very close to current semantics (in case 2.), and will DTRT that users seems to expect in case 1.
Comment 20 Jaroslav Mracek 2016-09-16 11:02:07 EDT
Thanks for reaction, but config parser take only last option if presented multiple time. I prepared patch that will honor example [1] from Comment 19.
Comment 21 Jaroslav Mracek 2016-09-16 11:35:31 EDT
Here is the PR: https://github.com/rpm-software-management/dnf/pull/613

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