I was upgrading Fedora 38 to 40 and during the upgrade there was a “soft lockup” error and the upgrade seemed to be stuck. After waiting a while I decided to power off the system. The system booted fine, though the grub entry still shows f38. The about this system panel shows Fedora 40 but the kernel is reported to be 6.8.9-100.fc38.x86_64
I can log in, but dnf offline-upgrade seems to still look for f38 software (though only libdeflate is found for update. I had updated prior to upgrade so not surprising.). Discover shows Fedora 40 as the default source.
Additionally openssh fails to start the daemon due to the following
(sshd)[7242]: sshd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
sshd[7242]: OpenSSL version mismatch. Built against 30000090, you have 30200010
systemd[1]: sshd.service: Main process exited, code=exited, status=255/EXCEPTION
I suspect this is due to incomplete updating. Is there a way to redo the system-upgrade or to at least figure out all the conflicts that are left?
Thanks. The output of rpm -qa | sort seems to be mostly duplicates with only a few from f38 without a f40 equivalent.
Running dnf distro-sync results in a number of conflicting pacakges, mostly around sddm packages provided by Plasma 6.
Trying to run dnf distro-sync --allowerasing produces the error that this would remove dnf, grub2-tools-minimal, plasma-desktop, sudo, systemd, systemd-udev
It most likely would be, as first the new package versions are recorded in the rpm databas as the package are unpacked and installed. After all that, the information of the old versions are cleared from the database.
Cool, so that indicates that most of the packages were updated where the F40 versions were installed, but the F38 versions weren’t uninstalled.
Could you list the output of distro-sync just so we can see exactly what packages are causing issues?
The last time I had to do this, I followed more of a “surgical” method where I manually dealt with various packages to ensure that they were updated to the F40 version and the F38 version removed.
I wouldn’t use skip-broken just yet. Ideally we should be able to fix all the packages, we’ll just have to do it bit by bit.
sudo dnf distro-sync --releasever=40
Last metadata expiration check: 0:06:28 ago on Wed 03 Jul 2024 01:28:19 PM CEST.
Error:
Problem 1: package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicui18n.so.72()(64bit), but none of the providers can be installed
- package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicuuc.so.72()(64bit), but none of the providers can be installed
- libicu-72.1-2.fc38.x86_64 from @System does not belong to a distupgrade repository
- problem with installed package mozjs78-78.15.0-10.fc38.x86_64
Problem 2: problem with installed package sddm-x11-0.20.0-1.fc38.noarch
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora-modular
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from updates-modular
- package sddm-x11-0.21.0-4.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from updates-modular
- problem with installed package sddm-wayland-plasma-6.1.1-1.fc40.noarch
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora-modular
- package sddm-x11-0.21.0-4.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from updates-modular
- package sddm-x11-0.21.0-4.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora-modular
- sddm-x11-0.20.0-1.fc38.noarch from @System does not belong to a distupgrade repository
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora-modular
- package sddm-x11-0.21.0-4.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from updates-modular
- package sddm-x11-0.21.0-4.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora-modular
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from updates-modular
- package sddm-x11-0.21.0-4.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora-modular
- package sddm-x11-0.21.0-4.fc40.noarch from fedora-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from updates-modular
- package sddm-x11-0.21.0-4.fc40.noarch from updates-modular conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
Ok, this shows what you describe, but dnf remove --duplicates fails with the error
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
Also the output lists many packages like the following Installed package tex-preview-13.3-3.fc40.noarch not available. does that indicate that these fc40 packages were not actually installed?
Ahh, yes --relesasever=40 was the issue with that, and yes fedora-release-{common,identity,kde} were duplicated.
I disabled fedora-modular and updates-modular, which shortens the output a bit, but this is now the output from distro-sync (remove --updates produces the same list of package conflicts)
Last metadata expiration check: 0:50:41 ago on Wed 03 Jul 2024 01:28:16 PM CEST.
Error:
Problem 1: package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicui18n.so.72()(64bit), but none of the providers can be installed
- package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicuuc.so.72()(64bit), but none of the providers can be installed
- libicu-72.1-2.fc38.x86_64 from @System does not belong to a distupgrade repository
- problem with installed package mozjs78-78.15.0-10.fc38.x86_64
Problem 2: problem with installed package sddm-wayland-plasma-6.1.1-1.fc40.noarch
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from @System
- package sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.0.3-2.fc40.noarch from fedora
- package sddm-x11-0.21.0-4.fc40.noarch from fedora conflicts with sddm-greeter-displayserver provided by sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates
- package sddm-wayland-plasma-6.1.1-1.fc40.noarch from updates conflicts with sddm-greeter-displayserver provided by sddm-x11-0.21.0-4.fc40.noarch from fedora
- problem with installed package sddm-x11-0.20.0-1.fc38.noarch
- sddm-x11-0.20.0-1.fc38.noarch from @System does not belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
I manually removed sddm-x11 and mozjs78 and the problems with conflicting packages or unavailable dependencies go away, however, the problem with protected packages still remains
Problem: The operation would result in removing the following protected packages: dnf, grub2-tools-minimal, plasma-desktop, sudo, systemd, systemd-udev
(which may trick the system into reinstalling the f40 ones and uninstalling the f38 ones).
Yeh, this is because the deps are all messed up at the moment. It needs to remove some f38 packages, but they’re protected and it doesn’t know how to handle it. So we’ll have to do these bits manually.
Obligatory note: if you have a different /home partition or a recent backup of your user data, it’ll be quicker to fresh install and re-mount the partition/restore from your backup. Fixing the system is possible in theory, but one cannot say how much tinkering it’ll require.
Does it make sense that running dnf remove --duplicates --releasever=40 would list all packages with the fc40 version replacing fc38 and the download size of 5.9GB of packages? (I would think these are already installed and thus the size would be smaller, but maybe that’s just the interface?) I haven’t run the process, as I was unsure.
sudo dnf --releasever=40 update fedora-release\* just said everything is up-to-date.
sudo dnf --releasever=40 reinstall fedora-release\* replaced the old f37-f38 version with f39-f40. However, (as expected?) distro-sync still errors with the protected packages problem.
I have everything in btrfs subvolumes inside of an encrypted luks container. Is it possible to reinstall just the system in this case or or will I need to repartition and then copy home and configs from backup after creating the users? I guess I would also need to determine all the extra software that I use which I have installed over the years.
Does running dnf commands without providing the releasever argument now look for f40 repos and all that?
Yeh, I think that’ll be expected. The man page says:
“To ensure the integrity of the system it reinstalls the newest package”.
Was that throwing any errors, otherwise, that’ll be one to run. It should remove all the f38 packages and re-install all the f40 ones ensuring that they’re correctly installed. That should clean up most of the mess.
I’m not sure about this—not on btrfs yet.
But yes, you’ll have to install the extra packages you collected over the years.
User installed flatpaks should be (ones installed with --user), but not systemwide ones I don’t think.
After removing another package that was in conflict gcc-gdb... I was able to run remove --duplicates and distro-sync without any special options. This seems to have downloaded things, and openssh is running fine. However, the kernel is still stuck at 6.8.9-100.fc38.x86_64 even after explicitly installing 6.8.7-200.fc40 with dnf and running dracut.
Also after rebooting my normally 1920x1080 display only supports 640x480, but I haven’t really tried to solve this issue yet.
As noted in my response to @Ankur, I have been able to run the dnf commands without any special options, the F40 packages seem to be installed, but the kernel is still stuck on fc38.