Anyone an idea how to fix/get around this mess?
-
Anyone an idea how to fix/get around this mess?
I have a system that says its Fedora 42 in /etc/os-release
But it has still the fc41 packages installed and tries to use these repos with dnf update.Trying again to run the system upgrade errors out as seen in the second screenshot, and doing a normal dnf update with forcing the releasever variable to 42 fails because of all these conflicting files between the fc41 and fc42 packages

#Fedora #Fedora41 #Fedora42 #DNF #DuckDuckFedi


-
Anyone an idea how to fix/get around this mess?
I have a system that says its Fedora 42 in /etc/os-release
But it has still the fc41 packages installed and tries to use these repos with dnf update.Trying again to run the system upgrade errors out as seen in the second screenshot, and doing a normal dnf update with forcing the releasever variable to 42 fails because of all these conflicting files between the fc41 and fc42 packages

#Fedora #Fedora41 #Fedora42 #DNF #DuckDuckFedi


@9Lukas5 DNF: Neugersdorf
-
Anyone an idea how to fix/get around this mess?
I have a system that says its Fedora 42 in /etc/os-release
But it has still the fc41 packages installed and tries to use these repos with dnf update.Trying again to run the system upgrade errors out as seen in the second screenshot, and doing a normal dnf update with forcing the releasever variable to 42 fails because of all these conflicting files between the fc41 and fc42 packages

#Fedora #Fedora41 #Fedora42 #DNF #DuckDuckFedi


@9Lukas5 is there still some older repo enabled in /etc/yum.repos.d/?
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ describes how the upgrade path on the cli looks and how to get rid of old packages. May help here.
-
@9Lukas5 is there still some older repo enabled in /etc/yum.repos.d/?
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ describes how the upgrade path on the cli looks and how to get rid of old packages. May help here.
@bekopharm nope, duplicates is not the problem.
It's a weird inbetween state it seems.I now applied a regexp on all erroring packages where dnf didn't just swap the fc41 with the fc42 package by itself running this command:
dnf -y --releasever=42 swap $fc41-pkg-name $fc42-pkg-name
After this it seems to run the dnf update --releasever=42 just fine.
Let's wait if it will then use the relasever 42 automatically without me telling it explicitly
-
@bekopharm nope, duplicates is not the problem.
It's a weird inbetween state it seems.I now applied a regexp on all erroring packages where dnf didn't just swap the fc41 with the fc42 package by itself running this command:
dnf -y --releasever=42 swap $fc41-pkg-name $fc42-pkg-name
After this it seems to run the dnf update --releasever=42 just fine.
Let's wait if it will then use the relasever 42 automatically without me telling it explicitly
@9Lukas5 sounds a lot like power was cut in the middle of a release update

-
@9Lukas5 sounds a lot like power was cut in the middle of a release update

@bekopharm honestly? No idea anymore.
It's a VM not used productively, wasn't booted in weeks/months.
So no big deal if I it would be broken beyond recovery.But I wanted to see if I can fix it, just in case I have something like it on a productive machine sometime

I didn't even immediately realize it is in an inbetween state, because the system info told me its a Fedora 42, so I thought thats fine. Only when I today tried to dnf update and saw it reach out for the F41 repos I got sceptic
