How to switch Fedora variants for dnf in a system broken after upgrade 42->43?

Ask Fedora
1

After the latest system-upgrade my system broke. I couldn’t use an earlier kernel nor rescue.
With a lot of help, I can now log in using a command line input with boot parameter systemd.unit=multi_user.target. I can connect to the network.

None of the usual methods worked; full documentation is accessible at
https://forums.fedoraforum.org/showthread.php?335854-Repo-problems-after-upgrade-42-gt-43-Duplicates-and-Dependency-problems

uname -a

6.18.6-100.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jan 18 17:52:36 UTC 2026 x86_64 GNU/Linux

rpm -E %fedora

43
kinfocenter also states 43.

dnf however, thinks it sits of 42, while all repos are 43.
dnf update wants to update only 42 packages.

Received a lot of help there, but still no success at ‘rectifying’ dnf: How do I inform dnf that the system is running 43, respectively should be running 43? Yes, it was system-upgraded, it rebooted, everything, from 42 (and 42 from 41 several months ago).

Now it contains (dnf check) several thousand 42 packages and 43 packages in parallel.
–remove-duplicates and distro-sync don’t work, --allowerasing doesn’t go through because it would remove protected packages.

Therefore my question, and plea for help.

2 
sudo dnf distro-sync --releasever=43
1 Like
3

Welcome to the offical Fedora Community @digard

Please try to focus on the information you find here in our official discourse ( discussion.fedoraproject.org ) instance!

First of all I see that your repository still pointing to F42, which indicates that your upgrade not finished completely yet.

dnf is a simlink to dnf5 or dnf-3.
Please check first if they are correct:

 ls -l /usr/bin/dnf*  #should give you the output below

lrwxrwxrwx. 1 root root       4 set  1 21:00 /usr/bin/dnf -> dnf5
-rwxr-xr-x. 1 root root    1986 out 20 21:00 /usr/bin/dnf-3
lrwxrwxrwx. 1 root root       5 out 20 21:00 /usr/bin/dnf4 -> dnf-3
-rwxr-xr-x. 1 root root 1614256 set  1 21:00 /usr/bin/dnf5

Discover or Software app are still using dnf4. It can be that you have a mixup because of starting the upgrade with df4 alias one of the software mentioned (with other words you have to dnf databases on your system).

The correct way to debug your system is:
(while @augenauf allready mentioned a part of it :wink: )

4

Sorry if you’ve already tried this specific combination - but the following command has worked for some users in similar situations. It may work around the protected packages issue:

sudo dnf distro-sync \
    --refresh \
    --releasever=43 \
    --allowerasing \
    --skip-broken \
    --setopt=protected_packages=
1 Like
5

For a broken system, we don’t know if dnf is version 4 or 5, so you should always use dnfN with the appropriate option forms,
and when providing output from a dnfN command, include the full command-line.

It may help to know what caused the update to fail. Common reasons for failed updates/upgrades include:

  1. out of space on mass storage device
  2. power failure while update is running
  3. upgrade to 43 without fully updating 42
  4. hardware issue
  5. prematurely rebooting while a time-consuming update step is running in background

This forum has some recent threads for similar problems. Start by collecting information using rpm examples from those threads. Also please post the output from inxi -Fzxx so we understand the hardware.

1 Like
6

Some users have reported problems with the /etc/yum.repos.d/fedora.repo and /etc/yum.repos.d/fedora-updates files. It seems some have a file that replaces the $releasever part seen below with 42 and as such cannot read any other repo for the upgrades.

$ cat /etc/yum.repos.d/fedora.repo 
[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
countme=1
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

If you check that file with the command grep 42 /etc/yum.repos.d/fedora.repo and find that it has 42 where mine shown above has $releasever then the file must be edited to contain the $releasever instead.

Similarly check the /etc/yum.repos.d/fedora-updates.repo file to see if it may have the same error. Here is one case where that was seen.

and specifically

nano /etc/yum.repos.d/fedora-updates.repo

  GNU nano 8.3                                /etc/yum.repos.d/fedora-updates.repo                                          
[updates]
name=Fedora $releasever - $basearch - Updates
#baseurl=http://download.example/pub/fedora/linux/updates/$releasever/Everything/$basearch/
baseurl=https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/
enabled=1
countme=1
repo_gpgcheck=0
type=rpm
gpgcheck=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
1 Like
7

I thank everyone for their almost immediate help!!

The problem could be solved. Usually I am good at searches, but here I had failed, and that for a few days.
The solution was found here in this discussion, and I am not the only one hit by this.
For the upgrade I had already been hit by the wine problem, though I wasn’t aware of the dnf4->dnf5 problem, until the last hour.

The solution was a combination of two discussion posts here; working only after a complete removal of wine.

dnf distro-sync --releasever=43 --refresh --skip-broken --setopt=protected_packages=

In retrospect, I would have been helped earlier by a sticky post, pin, … after several people had been hit by the identical problem as early as December.

Thanks again for all your efforts!

(How do I set this to “Solved”?)

8

Thanks for your help. Though this is a solution that I had tried some days ago already. It works, but not in this state, where the problem arises from different actions of dnf4 and dnf5; that is using Discover.

9

That’s exactly the case. I think it was a major mistake to not inform all users that dnf(5) and Discover work differently. I had used both, and that had messed up the system.

1 Like