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.
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
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
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.
well i m sorry i make the upgrade.
I can confirm the workaround by removing python3-dnf-plugins-core-0.1.21-2.fc23.noarch worked for me as well.
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?
Same situation as Petre, same kernel same dnf.conf
I had the same situation than Petre & Andrea and this worked for me : https://bugzilla.redhat.com/show_bug.cgi?id=1347999#c2
(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
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.
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.
*** Bug 1347999 has been marked as a duplicate of this bug. ***
*** Bug 1352240 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 1352199 has been marked as a duplicate of this bug. ***
*** Bug 1359522 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
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.
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.
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.
Here is the PR: https://github.com/rpm-software-management/dnf/pull/613