Broken package state after interrupted upgrade to F39

Ask Fedora
,
1

Hi
I tried to upgrade to Fedora 39 but my computer crashed during the upgrade process. I can still start it with Fedora 38 though.

I tried to run system-upgrade download again but now it wants to remove packages like grep as part of the upgrade process. See the output here. Another person in the fedora chat suggested to run dnf distro-sync which shows the following output:

> sudo dnf distro-sync
Letzte Prüfung auf abgelaufene Metadaten: vor 0:05:31 am Mo 09 Okt 2023 16:51:31 CEST.
Fehler: 
 Problem 1: package libicu72-72.1-2.fc39.x86_64 from @System requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be installed
  - package libicu72-72.1-2.fc39.x86_64 from @System requires libm.so.6(GLIBC_2.38)(64bit), but none of the providers can be installed
  - glibc-2.38-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - Problem mit installiertem Paket libicu72-72.1-2.fc39.x86_64
 Problem 2: package libimobiledevice-glue-1.0.0-1.fc39.x86_64 from @System requires libplist-2.0.so.4()(64bit), but none of the providers can be installed
  - libplist-2.3.0-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - Problem mit installiertem Paket libimobiledevice-glue-1.0.0-1.fc39.x86_64
 Problem 3: package mozjs115-115.1.0-1.fc39.x86_64 from @System requires libicui18n.so.73()(64bit), but none of the providers can be installed
  - package mozjs115-115.1.0-1.fc39.x86_64 from @System requires libicuuc.so.73()(64bit), but none of the providers can be installed
  - libicu-73.2-2.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - Problem mit installiertem Paket mozjs115-115.1.0-1.fc39.x86_64
 Problem 4: package glibc-2.38-1.fc39.i686 from @System requires glibc-langpack = 2.38-1.fc39, but none of the providers can be installed
  - package llvm16-libs-16.0.6-5.fc39.i686 from @System requires libc.so.6(GLIBC_2.38), but none of the providers can be installed
  - glibc-langpack-en-2.38-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - glibc-langpack-de-2.38-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - glibc-all-langpacks-2.38-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - Problem mit installiertem Paket llvm16-libs-16.0.6-5.fc39.i686
 Problem 5: package glibc-2.38-1.fc39.x86_64 from @System requires glibc-common = 2.38-1.fc39, but none of the providers can be installed
  - package llvm16-libs-16.0.6-5.fc39.x86_64 from @System requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be installed
  - package llvm16-libs-16.0.6-5.fc39.x86_64 from @System requires libm.so.6(GLIBC_2.38)(64bit), but none of the providers can be installed
  - glibc-common-2.38-1.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - Problem mit installiertem Paket llvm16-libs-16.0.6-5.fc39.x86_64
(Versuchen Sie '--skip-broken' zur Befehlszeile hinzuzufügen, um nicht-installierbare Pakete zu überspringen)

Does anyone know how I can finish the upgrade process and get out of the half F38, half F39 state?

2

I wish there were a well documented and well tested procedure for this case.

From the pastebin listing I see that the packages to be removed (Entfernen) are old fc38 packages, which are probably marked as duplicate. So each of these package have a version fc39 as well as fc38 installed – only according to rpm. The actual files installed in your file system are from the latest installed version, and the dnf just needs to be told that the old one should be removed from its database.

Also take a look at (from man dnf)

       dnf [options] remove --duplicates
              Removes  older  versions  of  duplicate packages. To ensure the integrity of the system it reinstalls the newest
              package. In some cases the command cannot resolve conflicts. In such cases the dnf  shell  command  with  remove
              --duplicates and upgrade dnf-shell sub-commands could help.

If you run dnf repolist does it show “Fedora 39” or “Fedora 38”?

3

It shows Fedora 38

copr:copr.fedorainfracloud.org:jn64:Cemu    Copr repo for Cemu owned by jn64
copr:copr.fedorainfracloud.org:varlad:helix Copr repo for helix owned by varlad
fedora                                      Fedora 38 - x86_64
fedora-cisco-openh264                       Fedora 38 openh264 (From Cisco) - x86_64
fedora-modular                              Fedora Modular 38 - x86_64
pgdg-common                                 PostgreSQL common RPMs for Fedora 38 - x86_64
pgdg11                                      PostgreSQL 11 for Fedora 38 - x86_64
pgdg12                                      PostgreSQL 12 for Fedora 38 - x86_64
pgdg13                                      PostgreSQL 13 for Fedora 38 - x86_64
pgdg14                                      PostgreSQL 14 for Fedora 38 - x86_64
pgdg15                                      PostgreSQL 15 for Fedora 38 - x86_64
pgdg16                                      PostgreSQL 16 for Fedora 38 - x86_64
rpmfusion-free                              RPM Fusion for Fedora 38 - Free
rpmfusion-free-updates-testing              RPM Fusion for Fedora 38 - Free - Test Updates
rpmfusion-nonfree                           RPM Fusion for Fedora 38 - Nonfree
rpmfusion-nonfree-steam                     RPM Fusion for Fedora 38 - Nonfree - Steam
rpmfusion-nonfree-updates-testing           RPM Fusion for Fedora 38 - Nonfree - Test Updates
updates                                     Fedora 38 - x86_64 - Updates
updates-modular                             Fedora Modular 38 - x86_64 - Updates

Is there maybe a way to tell dnf to reinstall all the dependencies of the fc39 packages so that their version is corrected?

4

dnf distrosync --releasever=39 should be able to do that. But I wonder if you should first run dnf remove --duplicates --releasever=39. I never needed to run this so I am not totally sure how that would work. In any case, run everything from pure commandline interface, that is, alt-shift-F4 and then log in.

5

I agree that those are probably duplicates. You could check whether that’s the case, e.g. rpm -qa | grep grep

I expect this would propose a similar transaction to dnf system-upgrade. If it does, it might be better to try that again instead. Definitely back up any irreplaceable data if you haven’t already.