Cannot upgrade to Fedora 36 or 37: best update candidate for package mate-desktop-configs

,

Unable to upgrade from Fedora 35 to Fedora 36. The last regular updates did not help, now there’s Fedora 37 but any attempt to upgrade fails.

gnome-software just shows its usual oneliner and does not seem to log the error message anywhere (nothing in the terminal, /var/log/dnf.log doesn’t seem to have the error either):

Could not depsolve transaction; 1 problem detected:

Scripted attempts to upgrade using dnf fail with this confict:

Error: 
 Problem: cannot install the best update candidate for package mate-desktop-configs-1.26.0-4.fc35.noarch
  - problem with installed package mate-desktop-configs-1.26.0-4.fc35.noarch
  - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.9-1.fc36.noarch
  - cannot install the best candidate for the job
  - mate-desktop-configs-1.26.0-4.fc35.noarch does not belong to a distupgrade repository

Ignoring the problem does not seem to help and running dnf erase mate-desktop-configs would also remove mate-desktop.

You might try

  1. dnf upgrade --refresh --best --allowerasing
    The refresh just in case the current cached metadata on your system is out of date
    The best and allowerasing to see what it suggests as an alternative.

does this happen when just performing an upgrade or when trying to do the system upgrade to the newer release version? I see that the mate package is version fc35 but the oomd package is fc36.

If trying to do the release version upgrade then it is always recommended that you do a full system upgrade on the current version and verify no errors before attempting the system upgrade to a newer version.

Note the instrucitions for a release version upgrade are here

and that it says

dnf upgrade is not affected as this command will not upgrade to the next release, it will only install regular updates. All updates (for this release: 35) are installed.

Like I wrote in the beginning, this is about upgrades, i.e., from Fedora release 35 to 36 or 37.

Thanks for the link, although I am already aware of the instructions and how it works. The graphical upgrade tool gnome-software fails:

Which is why I’m using an upgrade script which runs dnf, it prints a bit of noise with minor warnings (RPM Fusion) followed by the error:

# dnf system-upgrade download --best --allowerasing --releasever 36 
...
Ignoring repositories: rpmfusion-free-updates
No match for group package "plasma-workspace-xorg"
No match for group package "k3b-extras-freeworld"
No match for group package "qgnomeplatform"
Error: 
 Problem: cannot install the best update candidate for package mate-desktop-configs-1.26.0-4.fc35.noarch
  - problem with installed package mate-desktop-configs-1.26.0-4.fc35.noarch
  - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.9-1.fc36.noarch
  - cannot install the best candidate for the job
  - mate-desktop-configs-1.26.0-4.fc35.noarch does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

I see that the mate package is version fc35 but the oomd package is fc36.

Good catch. The first one is installed (matches the current release):

# rpm -qi mate-desktop-configs 
Name        : mate-desktop-configs
Version     : 1.26.0
Release     : 4.fc35

But systemd-oomd-defaults is not installed and I guess the version “fc36” is a hint that it’s being pulled in by the upgrade:

# rpm -qi systemd-oomd-defaults
package systemd-oomd-defaults is not installed

With the option --skip-broken instead of --allowerasing, I just get 5 additional conflicts (including lua-libs and I don’t have the time to find out what that is, if something I use depends on it).

I am having a very bad user experience trying to keep this system up to date.

If you have already run the dnf upgrade --refresh command then I suggest you follow that with dnf distro-sync. There may be something else that is causing the problem that may be from a 3rd party. Please post the details as you did for the system-upgrade attempt so we can parse the errors one at a time and figure out the solution for each.

...
Dependencies resolved.
Nothing to do.
Complete!
# dnf distro-sync
Dependencies resolved.
Nothing to do.
Complete!

FIX

Now, this has been fixed for Fedora 37 - not for F36, so when upgrading a Fedora 35 installation, you’ll have to skip one release. I took the time to find the package that’s causing the conflict and reported a bug to Fedora.

Since it’s fixed for F37 only, users will have to select this release to upgrade their system:

$ sudo dnf system-upgrade download --best --allowerasing --releasever 37

Before confirming, double-check what’s listed under Removing: (everyone should check that always, otherwise you could end up without desktop environment if you add some “allowerasing” option without checking what would be removed). No Mate package is listed to be removed anymore.

I hope this helps someone out there. And I also hope that distro maintainers are a bit more careful in the future when adding new software as dependency like this systemd-oomd package.

THE END.


As if that wasn’t enough, the upgrade failed on one of several computers because the boot partition was full. Originally, it was set to 1 GB on this system, assuming that 1 GB would be more than enough to fit all initramfs images and all other files required for the boot loader - it wasn’t. Maybe someone else who’s facing this problem finds this page, so here’s what it looks like:

Total                                                                                  6.7 MB/s | 6.2 GB     15:37     
Fedora 37 - x86_64                                                                     1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x5323552A:
 Userid     : "Fedora (37) <fedora-37-primary@fedoraproject.org>"
 Fingerprint: ACB5 EE4E 831C 74BB 7C16 8D27 F55A D3FB 5323 552A
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-37-x86_64
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  installing package kernel-core-6.2.9-200.fc37.x86_64 needs 6MB more space on the /boot filesystem
  installing package grub2-efi-x64-1:2.06-94.fc37.x86_64 needs 12MB more space on the /boot filesystem
  installing package mactel-boot-0.9-27.fc37.x86_64 needs 6MB more space on the /boot filesystem
  installing package memtest86+-5.31-0.7.beta.fc37.x86_64 needs 7MB more space on the /boot filesystem

Error Summary
-------------
Disk Requirements:
   At least 12MB more space needed on the /boot filesystem.

GParted shows that the boot partition is basically full:

GParted allows you to shrink the system partition by 1 GB and then move it to the right by 1 GB in order to make space for the boot partition to be grown to 2 GB. Obviously that would have to be done while the system partition is not mounted, so for example from a Fedora installer disk or almost any other Linux live system like Parted Magic. But first, I’ll recommend to shrink the filesystem (which lives inside of the partition that we need to shrink) to prevent it from being corrupted at the end - there used to be a bug in GParted that would actually allow that to happen.

So let’s first shrink the filesystem inside of the system partition and to prevent rounding errors, let’s shrink it by a bit more than 1 GB:

$ sudo btrfs filesystem resize -5120m /
Resize device id 1 (/dev/nvme0n1p2) from 1.80TiB to 1.80TiB

Now the last 5 GB of the partition are not used by the BTRFS filesystem anymore, so the partition containing it can safely be shrunk…

Screenshot_20230413_165327

I wonder what you have in /boot that fills it up?

I have never seen my 1GB /boot partition at more than ~45% full even with 4 kernels kept installed.

Please show df and ls -l /boot

1 Like

The installonly_limit setting was changed (increased) in the past because of unresolved issues caused by some bug in the latest kernel back then and the second of the three kernels was also affected so selecting the last kernel in the boot menu was the only option to avoid the bug. If the limit is left at the default of three, creating a 1 GB boot partition when installing a system should be enough though. If someone changed the setting and now hit the limit or if someone didn’t pay attention to the size of the boot partition and allocated only a few hundred MB, it may be necessary to shrink and move the next partition and I thought my comment could help some future user facing this issue.