PSA: Rawhide - what to do if switch to dnf5 fails because dnf is protected

Ask Fedora
1

I’ve heard a couple of folks report that they tried updating a Rawhide system or container and it failed with:

Problem: The operation would result in removing the following protected packages: dnf

The problem seems to be caused by doing the upgrade with an older dnf installed. dnf-4.15.1-1.fc39 was tagged into Rawhide on May 18th, and it dropped the protection of dnf (and yum). So there was a month or so where the ‘current’ dnf package you got on Rawhide update dropped the protection of dnf itself, and if you updated to that version before the dnf5-by-default update arrived this week, your upgrade to dnf5 should go fine.

However, if you didn’t update your system to dnf-4.15.1-1.fc39, you’ll encounter this problem when you try to update now, because the older dnf build you have installed still considers itself protected.

The most reliable workaround for this, as suggested by the DNF team (thanks!), is to add --setopt=protected_packages=, to your update command. This overrides the list of “protected packages” to be empty, and should allow the update to proceed.

It’s also been reported that using the pre-switchover dnf5 to do the switchover upgrade (the one that makes dnf5 the default and removes dnf) may not work. If it doesn’t, then just use dnf to run that upgrade instead.

Sorry for any trouble caused by this!

2

How about the name? Will dnf5 be renamed to dnf or still being dnf5 in F39.
Or was this just in F38 so that we can it run it parallel?

3

This is about Rawhide. In Rawhide, the dnf command is now provided by the dnf5 package. That’s the transition the post is about.

4

Isn’t offline-upgrade no longer supported with dnf5?

sudo dnf offline-upgrade download
Unknown argument "offline-upgrade" for command "dnf5". Add "--help" for more information about the arguments.

Sorry if it is not the right please to ask. Feel free to move/delete…

1 Like
5

This is an informational post so it’s not exactly the right place, but - seems like you’re right! Don’t know how I hadn’t noticed that. This is the issue for it. I’ll see if we plan to fix this for F39. thanks for mentioning it.

1 Like
6

The suggested workaround using dnf 4.15.1-1 doesn’t work with the current F39 toolbox image (which has dnf 4.15.0-1).

I managed to use 4.16.1-2 as the intermediate step instead.

Reproducer:

podman pull fedora-toolbox:39
toolbox create -i fedora-toolbox:39 f39-dnf-test
toolbox run -c f39-dnf-test sudo dnf up # expected fail

mkdir -p /tmp/dnf
cd /tmp/dnf
koji download-build 2202454 # 4.15.1-1.fc39
toolbox run -c f39-dnf-test sudo dnf up ./*.rpm # dnf is now 4.15.1-1
toolbox run -c f39-dnf-test sudo dnf up # still fails to switch to dnf5

rm ./*.rpm
koji download-build 2209712 # 4.16.1-2.fc39
toolbox run -c f39-dnf-test sudo dnf up ./*.rpm # dnf is now 4.16.1-2
toolbox run -c f39-dnf-test sudo dnf up  # successful switch to dnf5
2 Likes
7

I’ve replaced the suggested workaround with one proposed by the DNF team at 2216807 – upgrade to dnf5 fails because dnf is protected , which seems likely to be more reliable.