Upgrade old Fedora CoreOS 36, 37 or 38 to current version - how?

In a customer environment we have a couple of VMs running Fedora CoreOS with old versions 36, 37 or 38. Frankly, we simply forgot about those VMs for the last two years or so and did not regularly upgrade them. Now we discovered these again and that we have to upgrade them to current version 42. But the “normal” way fails. The reason seems to be that the VMs have layered packages.

Sample:

[root@nfs ~]# rpm-ostree status
State: idle
Deployments:
? fedora:fedora/x86_64/coreos/stable
Version: 38.20231002.3.1 (2023-10-17T02:25:40Z)
BaseCommit: 7ca4ce157e80858b1b47f6f4bfda997193e278e44fe4d0fa2bb43f76fa724eca
GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
RemovedBasePackages: nfs-utils-coreos 1:2.6.3-1.rc3.fc38
LayeredPackages: httpd libvirt nagios-plugins nagios-plugins-disk nagios-plugins-load nagios-plugins-nagios nagios-plugins-procs nagios-plugins-swap nagios-plugins-users nfs-utils nrpe open-vm-tools parted
...

When I try to upgrade this to a later version, this is what happens:

[root@nfs ~]# rpm-ostree deploy 40.20241019.3.0
Resolving version ‘40.20241019.3.0’
1 metadata, 0 content objects fetched; 592 B transferred in 1 seconds; 0 bytes content written
? Receiving objects; 99% (15735/15849) 8.0 MB/s 825.1 MB
2673 metadata, 13227 content objects fetched; 820886 KiB transferred in 104 seconds; 1.7 GB content written
Receiving objects; 99% (15735/15849) 8.0 MB/s 825.1 MB… done
Checking out tree 6df7006… done
Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora updates-archive
Updating metadata for ‘fedora-cisco-openh264’… done
Updating metadata for ‘fedora-modular’… done
Updating metadata for ‘updates-modular’… done
Updating metadata for ‘updates’… done
Updating metadata for ‘fedora’… done
Updating metadata for ‘updates-archive’… done
Importing rpm-md… done
rpm-md repo ‘fedora-cisco-openh264’; generated: 2024-03-12T11:45:42Z solvables: 3
rpm-md repo ‘fedora-modular’; generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo ‘updates-modular’; generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo ‘updates’; generated: 2025-05-13T02:13:56Z solvables: 35969
rpm-md repo ‘fedora’; generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo ‘updates-archive’; generated: 2025-05-13T03:35:14Z solvables: 87483
Resolving dependencies… done
Will download: 207 packages (67.5 MB)
Downloading from ‘updates-archive’… done
error: Cannot download swtpm-libs-0.9.0-2.fc40.x86_64.rpm: All mirrors were tried; Last error: Status code: 404 for https://fedoraproject-updates-archive.fedoraproject.org/fedora/40/x86_64/swtpm-tools-0.9.0-2.fc40.x86_64.rpm (IP: 143.204.55.82)

So it seems to be able to download the base image without problem. But when it tries to download the updates for the layered packages, it fails to find them. Apparently, the location has changed.

What would be your advice how to solve this problem? I can think of reverting the layered packages, upgrading and then adding the layered packages again. But perhaps there is a simpler solution?

The fedora archives link in the details you pasted are 404 not found. I navigated there and it was found, so coukd it be as simple as trying again?

With regular Fedora, one must update no more than 2 versions at a time, eg 37 to 39 and then 39 to 41. It can be possible to fotce an upgrade eg 36 to 42 but I would highly discourage it.

When I check this URL from above message simply in my browser, I get this:

And yes, only two major releases. As you can see in my initial message, I try from 38 to 40.

I now found out that I can simply uninstall “libvirt” (and all its dependencies) then it will upgrade. This way I got it to version 40 now.

When I now try to upgrade to version 42, I get another error:

error: Executing %transfiletriggerin for filesystem: Package ‘filesystem’ has (currently) unsupported script in ‘%transfiletriggerin’

Uh, oh …

I could solve this now as well by upgrading from 40 to 42 not in one step but first from 40 to 41 and then from 41 to 42 again.

So, upgrade of the first two VMs completed now.
Hopefully it will work on the other VMs as well (8 VMs total).

1 Like

These kinds of errors are the reason that fedora does not support multi-version upgrades as a single step.

Thanks for sharing the solution you have found.