Fedora KDE 39->40 upgrade fails with protected package

Ask Fedora
, , ,
1

I have had a couple if issues like this.

I dont know if this was my 3rd attempt to upgrade F39->F40, but I think so. Maybe that was F38->F39.

During upgrade, it fails, because the protected package setup-version-f39 would be removed.

There must be an issue with unprotecting outdated packages.

The documentation on how to do this with dnf is either nonexitent or not well discoverable.

I ended up doing it with some random rpm -e command from Stackexchange.

That is not great.

Btw, I used dnf4 and the packages were really minimal. I also tagged workstation because there should be no difference in how dnf behaves

2

Added dnf, dnf-system-upgrade, kde-plasma, workstation

3

Do you have the output of dnf when this was failing?

4

protected_packages

list

List of packages that DNF should never completely remove. They are protected via Obsoletes as well as user/plugin removals.

The default is: dnf, glob:/etc/yum/protected.d/*.conf and glob:/etc/dnf/protected.d/*.conf. So any packages which should be protected can do so by including a file in /etc/dnf/protected.d with their package name in it.

DNF will protect also the package corresponding to the running version of the kernel. See also protect_running_kernel option

https://dnf.readthedocs.io/en/latest/conf_ref.html

1 Like
5

I can check, what is the best way to get those outputs afterwards?

It was always failing because the f39 ā€œsetupā€ would have been removed.

When removing that with force, the upgrade worked

6

Iā€™m not sure failed attempts are logged anywhere.

I keep a record of failures that I may want to bug report at the time of failure. For example: dnf update 2>&1 | tee dnf-failure.log

1 Like
7

this would be a great permanent addition. Do you know anything about this and dnf5?

will make an alias for now

8

Iā€™ve not looked at dnf5 very much.

Iā€™m also not planning to add aliases as that will just make my setup non-standard for doing RPM maintenance.

1 Like
9

That command with redirection of the output should not be reliant upon dnf in any way. Redirecting the output is a shell controlled issue and not dependent upon which command is being used. Thus creating an alias within your shell would be easy. Not quite so easy if you want it to be an alias within dnf itself.

10

Hm, yes this is standard of course, but doesnt DNF save what it actually did somewhere? Dnf history just saves what you told it to do, which is quite different.

11

I believe most of the logs are in /var/logs itā€™s also in the journal.

The system-upgrade is in the journal during the boot when it occurs. I donā€™t know if the errors are captured anywhere prior to the upgrade.

You can look at dnf system-upgrade log to get to the journal.

1 Like