How to Upgrade Fedora 44 to Fedora 45 (GUI, CLI and Rollback)

The Fedora 44 to 45 upgrade itself is one download and one reboot. What breaks is the software sitting on top of it. MariaDB asks for mariadb-upgrade, PostgreSQL flags every database with a collation mismatch because glibc moved, Podman 6 refuses to start containers created with slirp4netns, Python virtual environments lose all their packages, and half of your GNOME extensions come back marked out of date.

Original content from computingforgeeks.com - post 171961

This guide covers both upgrade paths (GNOME Software on the desktop, dnf system-upgrade on a server), the pre-checks that catch lagging repos before you reboot, the fix for every breakage above, and two tested ways back to Fedora 44 if the upgrade goes wrong: a Btrfs subvolume swap on Workstation and an LVM snapshot merge on Server. Everything here was run on two fresh machines, a Fedora 44 Workstation with RPM Fusion, Chrome, VS Code, Docker CE and Flatpak apps, and a Fedora 44 Server running MariaDB, PostgreSQL, Cockpit and rootless Podman, both taken to Fedora 45 with the same commands.

--releasever=45 resolves to whichever Fedora 45 tree the mirrors publish, so the procedure is the same whenever you run it. Details that depend on repo state, such as updates-testing and vendor repos that lag a release, are called out where they matter, and the last section has a quick check for each. For the feature list, read what is new in Fedora 45. For a clean install instead, follow the Fedora 45 Server and Workstation install guide.

What the upgrade did on both test machines

Both machines were installed from the Fedora 44 netinstall ISOs with a kickstart that selected the real product environments, so the disk layouts match a normal install: Btrfs root and home with an ext4 /boot on Workstation, XFS on LVM with a 15 GiB root on Server. Workstation got 4 vCPU and 8 GiB RAM, Server 2 vCPU and 4 GiB.

Measurement	Workstation (GNOME Software)	Server (dnf system-upgrade)
Installed RPMs before	1,946 (plus 5 Flatpaks)	845
Download size	2.3 GB	961 MiB (1 min 38 s)
Packages in the transaction	1,937 from the repos (offline log)	18 installed, 815 upgraded, 14 downgraded
Offline transaction	5 min 33 s	6 min 42 s
Reboot to login again	376 s	443 s
Group upgrades (adds kmscon)	No	Yes
Broke and needed a fix	2 GNOME extensions plus the Fedora AppIndicator RPM, Python venv	MariaDB datadir, PostgreSQL collation, rootless Podman on slirp4netns
Kept working with no action	Keyring secrets, Chrome, VS Code, Docker CE, Flatpaks	Cockpit, the nginx quadlet, SELinux enforcing

The major version jumps behind those breakages: Python 3.14 to 3.15, MariaDB 11.8 to 12.3, Podman 5 to 6, OpenSSL 3 to 4, glibc 2.43 to 2.44, systemd 259 to 262, RPM 6.0 to 6.1, and GNOME 50 to 51. PostgreSQL stays on the 18 line.

Prerequisites

• A Fedora 44 system (Workstation, Server, Cloud or a spin) and an account with sudo
• Free space on / of at least twice the download size. The packages sit in /var/lib/dnf/offline/packages until the offline transaction finishes (2.2 GB on the Workstation)
• Console access (VM console, IPMI or a keyboard). SSH is gone for the whole offline phase
• A rollback point: a Btrfs snapshot, an LVM snapshot, or a full backup. Both methods are covered below and should be set up before the reboot
• The list of third-party repositories and database services on the box, because those are what need attention afterwards

Bring Fedora 44 fully up to date

The upgrade resolves against what is installed, so start from a current Fedora 44. A stale DNF stack is the usual source of odd dependency errors in the download step:

sudo dnf upgrade --refresh -y
sudo reboot

Reboot even if you think nothing important changed. Both test boxes pulled a new kernel here, and you want to leave Fedora 44 from the kernel you would fall back to. There is no plugin to install first: system-upgrade ships inside DNF5, so guides that tell you to install dnf-plugin-system-upgrade date from DNF4.

Record a baseline so you have something to compare against later:

fastfetch --pipe --logo none | grep -E '^(OS|Kernel|Packages|Memory|Disk)'

The Workstation started here, after its Fedora 44 updates and a reboot:

OS: Fedora Linux 44 (Workstation Edition) x86_64
Kernel: Linux 7.2.7-200.fc44.x86_64
Packages: 5 (flatpak), 1946 (rpm)
Memory: 1.54 GiB / 7.72 GiB (20%)
Disk (/): 6.86 GiB / 37.41 GiB (18%) - btrfs

Check every repository against Fedora 45

Third-party repos that build per release use $releasever in their URL, and during the upgrade that variable becomes 45. A repo with no Fedora 45 tree does not stop the upgrade, because Fedora ships skip_if_unavailable=True as a distribution default. It prints a wall of 404 errors and silently leaves that vendor’s packages on their Fedora 44 builds. Find out which repos are affected before the reboot. This loop tests each enabled repo against the Fedora 45 tree, one at a time, with the skip turned off:

for r in $(dnf repo list --enabled | awk 'NR>1 {print $1}'); do
  if sudo dnf makecache -q --refresh --releasever=45 --repo="$r" --setopt=skip_if_unavailable=False >/dev/null 2>&1; then
    echo "OK    $r"
  else
    echo "FAIL  $r"
  fi
done

On the Workstation, three repos failed:

OK    fedora-cisco-openh264
OK    code
OK    rpmfusion-nonfree
FAIL  docker-ce-stable
OK    updates
OK    fedora
FAIL  rpmfusion-nonfree-updates
OK    google-chrome
OK    rpmfusion-free
FAIL  rpmfusion-free-updates

Each failure means something different:

• Docker CE has no fedora/45 directory yet. The Fedora 44 Docker packages stay installed and keep working (the Workstation ran hello-world fine on Fedora 45), but you get no Docker updates until the repo is fixed. The fix is in the post-upgrade section.
• RPM Fusion updates returned 404 on our run because RPM Fusion had not yet published its Fedora 45 updates repos. The base rpmfusion-free and rpmfusion-nonfree repos already work, and they carry the rpmfusion-*-release-45 packages, so the upgrade still moves RPM Fusion to 45 on its own.
• Google Chrome and VS Code pass because their URLs contain no release number. They are fine across Fedora upgrades.

VirtualBox and NVIDIA’s CUDA repo also returned 404 for Fedora 45 when these tests ran. If a failing repo ships something you cannot live without for a few weeks (a kernel module, say), wait for the vendor before upgrading.

Check Podman before the upgrade

Podman 6 removes three things for good: the BoltDB database backend, slirp4netns networking, and cgroups v1. BoltDB matters most. The Podman 6 change page is blunt that containers, pods and volumes in a BoltDB store become unusable after the upgrade. Check the backend and the default rootless network for every user that runs containers, and for root:

podman info --format '{{.Host.DatabaseBackend}} {{.Host.RootlessNetworkCmd}} cgroup={{.Host.CgroupsVersion}}'
sudo podman info --format '{{.Host.DatabaseBackend}}'

A default Fedora 44 install reports SQLite, pasta and cgroups v2 for both. SQLite has been Podman’s default since 4.8, so only older container stores are still on BoltDB:

sqlite pasta cgroup=v2
sqlite

Run the check after the Fedora 44 update and reboot from the previous section: Podman 5.8 tries to migrate a BoltDB store automatically on reboot. If either line still says boltdb, migrate by hand on Fedora 44 while Podman 5.8 is still installed. The command stops running containers, so do it in a maintenance window:

podman system migrate --migrate-db

Run it as each affected user and again with sudo for root containers. If the middle field says slirp4netns, a containers.conf still sets the old network. The test Server had one on purpose, and fixing it after the upgrade is covered below, because Podman 6 tells you exactly what to run. The Podman 6 breaking changes guide covers the rest of the API and CLI changes.

Take a rollback point

A snapshot costs a minute and gives you a way back to a working Fedora 44 in one reboot. Both layouts below were rolled back successfully on the test machines, and the rollback steps are further down. The snapshot does not cover /boot on either layout (ext4 on Workstation, a separate XFS partition on Server). Take a tar of it first, so the backup file ends up inside the snapshot of /.

Workstation: read-only Btrfs snapshot of the root subvolume

Fedora Workstation puts / in a subvolume named root and /home in one named home. Mount the top level of the filesystem to see both. Replace /dev/sda3 with your Btrfs partition (findmnt -no SOURCE / shows it):

sudo tar -C / -cpf /root/boot-f44.tar boot
sudo mkdir -p /mnt/btrfs-top
sudo mount -o subvolid=5 /dev/sda3 /mnt/btrfs-top
sudo btrfs subvolume snapshot -r /mnt/btrfs-top/root /mnt/btrfs-top/root-f44-pre-upgrade
sudo umount /mnt/btrfs-top
sudo btrfs subvolume list /

The new subvolume sits next to root and home:

ID 256 gen 212 top level 5 path home
ID 257 gen 212 top level 5 path root
ID 258 gen 66 top level 257 path var/lib/portables
ID 259 gen 66 top level 257 path var/lib/machines
ID 260 gen 212 top level 5 path root-f44-pre-upgrade

Two details matter later. home is a separate subvolume, so a rollback leaves your files and desktop settings alone. The nested var/lib/portables and var/lib/machines subvolumes are not part of the snapshot and have to be moved by hand during a rollback. If you already run Snapper, a Snapper snapshot with grub-btrfs works too and adds a boot menu entry for it.

Server: LVM snapshot of the root logical volume

Fedora Server leaves most of the volume group free (22 GiB on a 40 GiB disk), which is exactly what an LVM snapshot needs. Check the names first:

sudo vgs
sudo lvs

The test Server’s volume group carried its hostname, and the root LV was the only one:

  VG                   #PV #LV #SN Attr    VSize  VFree
  fedora_cfg-f44up-srv   1   1   0 wz--n-- 37.41g 22.41g
  LV   VG                   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root fedora_cfg-f44up-srv -wi-ao---- 15.00g

Back up /boot, then snapshot root. Put your own volume group name in VG:

VG=fedora_cfg-f44up-srv
sudo tar -C / -cpf /root/boot-f44.tar boot
sudo lvcreate -s -L 8G -n root-pre-f45 "$VG/root"

Size the snapshot for the whole upgrade, not for a quick test. After the upgrade and its first boot, this 8 GiB snapshot was already 45% full, because every rewritten block of / gets copied into it. A snapshot that fills up becomes invalid and is useless for a rollback. Keep it until Fedora 45 has proven itself, then remove it with sudo lvremove fedora_cfg-f44up-srv/root-pre-f45 (your VG name), because a classic LVM snapshot slows down every write to the origin while it exists. For database hosts, the LVM snapshots for consistent server backups guide covers flushing the databases before the snapshot.

Upgrade Fedora Workstation with GNOME Software

GNOME Software shows the upgrade banner on its Updates page by itself once Fedora marks 45 as the current release. Our run came before that, so we turned on the setting below, which also offers releases not yet marked current. Skip it if the banner is already there. If you do set it, undo it after the upgrade with gsettings reset org.gnome.software show-upgrade-prerelease, or GNOME Software will offer the next Fedora before it is final. Run it in your desktop session, not with sudo:

gsettings set org.gnome.software show-upgrade-prerelease true

Open Software and switch to the Updates tab. The Fedora Linux 45 banner appears at the top with a Download button:

The Integrated Firmware row under the banner is a separate fwupd item, the Secure Boot signature database update from the 2011 to the 2023 Microsoft certificates. It is unrelated to the release upgrade. It writes to the UEFI signature database, so apply it separately, with the machine on mains power, rather than in the same sitting as the release upgrade.

Click Download. GNOME Software asks for your password right away, with a polkit message about an rpm transaction with signature-unverified packages. Expect it on a release upgrade and authenticate.

Stay at the screen until you have typed the password. The first attempt on the test machine failed with “Unable to upgrade: authentication required” because the screen locked while the prompt was open, and the prompt timed out behind the lock screen. Clicking Download again brought the prompt back. After authentication, the download progress shows in the banner:

GNOME Software on Fedora 44 does not use PackageKit for this. Its DNF5 plugin hands the job to dnf5daemon-server, which stores the same kind of offline transaction as the command line. You can confirm it from a terminal before you reboot:

sudo dnf offline status

The initiating command names the daemon instead of a dnf command line:

An offline transaction was initiated by the following command:
	dnf5daemon-server
Run `dnf5 offline reboot` to reboot and perform the offline transaction.

That also means pkcon offline-get-prepared reports “No offline updates have been prepared” the whole time, which looks like a failed download and is not one. When the download finishes, the banner button changes to Restart & Upgrade:

Click it and confirm the dialog, which gives you 60 seconds before it restarts. The machine boots into the offline upgrade target and shows a progress screen:

Do not power off while the counter is on screen. The test Workstation spent 5 min 33 s here and was back at the login screen 376 s after the restart. The first login on Fedora 45 greets you with a “Software Updates Installed” notification:

One difference from the command line: GNOME Software upgrades packages but not comps groups. The CLI upgrade on the Server added kmscon (the new default console) through the Core group. The Workstation upgraded through GNOME Software never got it. Add it with sudo dnf group upgrade core if you want the console to match a fresh Fedora 45 install.

Upgrade Fedora Server with dnf system-upgrade

On a server, or on a desktop where you prefer the terminal, download the whole release first:

sudo dnf system-upgrade download --releasever=45 -y

If the repo check found a lagging vendor repo, add --disablerepo=docker-ce-stable (one flag per repo) to keep the 404 noise out of the log. DNF resolves the release, downloads every package, test-runs the transaction and imports the Fedora 45 key. The Server’s summary:

Transaction Summary:
 Installing:        18 packages
 Upgrading:        815 packages
 Replacing:        835 packages
 Downgrading:       14 packages

Total size of inbound packages is 961 MiB. Need to download 961 MiB.

Replacing is not an extra set of packages. DNF5 counts each old build that an upgrade, downgrade or obsolete replaces, which is why it sits close to the upgrade and downgrade totals combined. The 14 downgrades look worse than they are. Fedora 44 updates had shipped newer builds than the Fedora 45 base tree for packages including fwupd, libdnf, libsecret, vim-minimal, python3-botocore and PostgreSQL, and system-upgrade is a distro-sync, so it aligns them to the new release. PostgreSQL goes from 18.6 back to 18.3 this way, a minor version within the same major that uses the same on-disk format.

Confirm the stored transaction, then reboot into it:

sudo dnf system-upgrade status
sudo dnf system-upgrade reboot -y

Keep the -y when you run the reboot over a non-interactive SSH command. Without it the confirmation prompt reads no answer, prints “The system will now reboot”, and nothing happens. The Server’s offline transaction ran from 00:41:53 to 00:48:35, and SSH was back 443 s after the reboot command. Cockpit came up on the new release with no changes:

Verify the upgrade

The same fastfetch line from the baseline shows the new release and kernel:

fastfetch --pipe --logo none | grep -E '^(OS|Kernel|Packages|Memory|Disk)'

The Server went from 845 to 858 packages:

OS: Fedora Linux 45 (Server Edition Prerelease) x86_64
Kernel: Linux 7.2.7-300.fc45.x86_64
Packages: 858 (rpm)
Memory: 761.11 MiB / 3.79 GiB (20%)
Disk (/): 3.92 GiB / 14.94 GiB (26%) - xfs

Prerelease in the name and RELEASE_TYPE=development in /etc/os-release mean the machine was upgraded before Fedora 45 was marked stable. A later fedora-release update switches them to the stable values. The offline log is kept per boot, and it is the place to look if something went wrong during the transaction:

sudo dnf system-upgrade log
sudo dnf system-upgrade log --number=1 | grep 'dnf5\[' | tail -3

The Workstation’s log ends with the key warning and the completion line:

The following boots appear to contain offline transaction logs:
1 / 4c0d456addfa4e25b5b6c3fb55a12d6e: 2026-09-28 22:09:01 44→45
Sep 29 01:14:34 cfg-f44up-ws dnf5[651]: Warning: skipped OpenPGP checks for 1937 packages from repositories: fedora, fedora-cisco-openh264, rpmfusion-free, rpmfusion-nonfree
Sep 29 01:14:34 cfg-f44up-ws dnf5[651]: Transaction complete! Cleaning up and rebooting...
Sep 29 01:14:34 cfg-f44up-ws dnf5[651]: Complete!

The skipped OpenPGP checks are normal for the offline boot. The signatures were verified and the Fedora 45 key imported during the download, before the reboot. The boot list shows UTC while the journal lines show local time, which is why the two timestamps differ. Finish the check with systemctl --failed and getenforce. Both machines came up with no failed units and SELinux still Enforcing.

Fix what the upgrade breaks

Everything in this section was hit on the test machines, in this order. Most of it fails quietly: services start, and the problem shows up as a warning in a log or on the first command you run.

MariaDB: “The datadir located at /var/lib/mysql needs to be upgraded using ‘mariadb-upgrade’ tool”

Fedora 45 moves MariaDB from 11.8 to 12.3. The service starts on the old data directory and serves queries, but Fedora’s mariadb-check-upgrade helper logs a warning on every start until the system tables are upgraded:

sudo journalctl -b -u mariadb | grep mariadb-check-upgrade

The Server logged the full instructions right after the first boot:

Sep 29 00:48:54 cfg-f44up-srv mariadb-check-upgrade[1191]: The datadir located at /var/lib/mysql needs to be upgraded using 'mariadb-upgrade' tool. This can be done using the following steps:
Sep 29 00:48:54 cfg-f44up-srv mariadb-check-upgrade[1191]:   1. Back-up your data before with 'mariadb-upgrade'
Sep 29 00:48:54 cfg-f44up-srv mariadb-check-upgrade[1191]:   2. Start the database daemon using 'systemctl start mariadb.service'
Sep 29 00:48:54 cfg-f44up-srv mariadb-check-upgrade[1191]:   3. Run 'mariadb-upgrade' with a database user that has sufficient privileges

The marker file still names the old version, 11.8.8-MariaDB in /var/lib/mysql/mariadb_upgrade_info. Take a dump, then run the upgrade tool against the running server and restart it:

sudo mariadb-dump --all-databases --single-transaction | gzip | sudo tee /root/mariadb-before-upgrade.sql.gz >/dev/null
sudo mariadb-upgrade
sudo systemctl restart mariadb

The tool checks every table and ends with its eighth phase:

shop.orders                                        OK
sys
sys.sys_config                                     OK
Phase 7/8: uninstalling plugins
Phase 8/8: Running 'FLUSH PRIVILEGES'
OK

After the restart the warning is gone and mariadb_upgrade_info reads 12.3.2-MariaDB. The sample table kept all its rows. On a MySQL host the jump is from 8.4 to 9.7, and the same rule applies: back up first. The MariaDB on Fedora guide covers the rest of the server setup.

PostgreSQL: “database has a collation version mismatch”

PostgreSQL stays on the 18 line, so there is no pg_upgrade this time. glibc moves from 2.43 to 2.44, though, and PostgreSQL records the glibc collation version each database was created with. Every connection to each database prints this after the upgrade:

WARNING:  database "inventory" has a collation version mismatch
DETAIL:  The database was created using collation version 2.43, but the operating system provides version 2.44.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE inventory REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

It is a warning, not an error, and queries keep working. Ignore it and you risk a text index that no longer matches the new sort order, which shows up as rows that a query should find and does not, or duplicates in a unique index. List the affected databases:

sudo -u postgres psql -Atc "SELECT datname, datcollversion, pg_database_collation_actual_version(oid) FROM pg_database WHERE datallowconn"

All three databases on the test Server, the templates included, were created under 2.43:

postgres|2.43|2.44
inventory|2.43|2.44
template1|2.43|2.44

Rebuild the indexes in each one and record the new version. REINDEX DATABASE locks tables while it runs, so on a large production database, schedule it or rebuild the text indexes one at a time with REINDEX INDEX CONCURRENTLY:

for db in $(sudo -u postgres psql -Atc "SELECT datname FROM pg_database WHERE datallowconn" 2>/dev/null); do
  sudo -u postgres psql -q -d "$db" -c "REINDEX DATABASE \"$db\"" -c "ALTER DATABASE \"$db\" REFRESH COLLATION VERSION"
done

Each connection still prints the mismatch warning once, then the loop reports the version change for every database:

NOTICE:  changing version from 2.43 to 2.44
NOTICE:  changing version from 2.43 to 2.44
NOTICE:  changing version from 2.43 to 2.44

Run the listing query again and every row shows 2.44. Include template1, or every database you create later starts with the stale version. template0 does not accept connections, so the loop skips it and it keeps 2.43; databases created from it (createdb -T template0, or a pg_restore -C) need the same REINDEX and REFRESH COLLATION VERSION afterwards. See the PostgreSQL on Fedora guide for the server setup itself.

Podman: “slirp4netns support has been removed, run `podman system migrate`”

Rootless containers that were created with slirp4netns stop at start after the move to Podman 6. The nginx container created on Fedora 44 with --network slirp4netns (named legacy-slirp here) failed like this:

Error: unable to start container "08fab44c5664e0bcb9c29212199cbd77c15af4d8c07ea949b30e867dc9c01a42": slirp4netns support has been removed, run `podman system migrate` to update this container to use pasta

A config file that still names slirp4netns breaks every new container too, not only the old ones. podman run failed before pulling anything:

Error: invalid default_rootless_network_cmd option "slirp4netns"

Find the setting in the user and system config files:

grep -rn slirp4netns ~/.config/containers/ /etc/containers/containers.conf /etc/containers/containers.conf.d/ 2>/dev/null

Delete the default_rootless_network_cmd line it points to (pasta is the default; use sudo sed if the hit is under /etc/containers), then migrate the existing containers. The migrate stops every running container of that user, so restart them afterwards:

sed -i '/default_rootless_network_cmd/d' ~/.config/containers/containers.conf
podman system migrate
podman inspect legacy-slirp --format '{{.HostConfig.NetworkMode}}'

The container now reports pasta, starts, and serves on its published port again:

pasta

Rootful containers and quadlets that use the default network are not affected. The nginx quadlet on the test Server served HTTP 200 on the first Fedora 45 boot without any change. Quadlets that name slirp4netns, the iptables firewall driver and netavark 2 network isolation are covered in fixing Podman after a Fedora upgrade.

Python virtual environments: “ModuleNotFoundError: No module named ‘requests'”

Fedora 45 replaces Python 3.14 with 3.15, and /usr/bin/python3.14 is gone after the upgrade. A venv created on Fedora 44 still starts, because its python symlink points at /usr/bin/python3, but its packages live in lib/python3.14/site-packages and the new interpreter never looks there:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import requests; print(requests.__version__)
    ^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'requests'

The same applies to anything installed with pip install --user. The fix is a rebuild. It is easiest when you save the package list on Fedora 44, before the upgrade:

~/venv-tools/bin/pip freeze > ~/venv-tools-requirements.txt

After the upgrade, recreate the venv in place and reinstall:

python3 -m venv --clear ~/venv-tools
~/venv-tools/bin/pip install -r ~/venv-tools-requirements.txt
~/venv-tools/bin/python -c "import requests, sys; print(sys.version.split()[0], requests.__version__)"

The rebuilt venv runs on the new interpreter:

3.15.0rc2 2.34.2

If you forgot the freeze, ls ~/venv-tools/lib/python3.14/site-packages still lists what was installed. Tools installed with pipx need the same rebuild, which pipx reinstall-all does in one go. For the wider toolchain, see the Python, Node.js, Go and Rust on Fedora guide.

GNOME extensions show “OUT OF DATE”

GNOME Shell refuses to load an extension whose metadata.json does not list the running shell version. On the first GNOME 51 login, three of the four extensions on the test Workstation were disabled. gnome-extensions list gives you the UUIDs to check:

for u in [email protected] blur-my-shell@aunetx [email protected] [email protected]; do echo "== $u"; gnome-extensions info $u | grep -E "State|Version"; done

Dash to Dock had already published a GNOME 51 build on extensions.gnome.org. The others had not, and that includes the one installed from Fedora’s own repos (the RPM build carries no Version field):

== [email protected]
  Version: 109
  State: ACTIVE
== blur-my-shell@aunetx
  Version: 72
  State: OUT OF DATE
== [email protected]
  Version: 60
  State: OUT OF DATE
== [email protected]
  State: OUT OF DATE

The Fedora 45 build of gnome-shell-extension-appindicator still declares shell versions 45 to 50, so an RPM from the Fedora repos is no guarantee. Before upgrading, check each extension’s extensions.gnome.org page for a GNOME 51 entry. The page lists the supported versions per release, and that list is the reliable one. Once the authors publish GNOME 51 builds, update the extensions from the Extensions app or extensions.gnome.org. Forcing old extensions to load with disable-extension-version-validation can break the shell at login, so wait for the update or replace the extension. The GNOME Tweaks and extensions guide covers the tooling.

Keyring secrets move to oo7 (no action needed)

The upgrade installs oo7-daemon next to gnome-keyring, and on the first login oo7 takes over the Secret Service bus name. A secret stored on Fedora 44 with secret-tool was readable on Fedora 45 with no prompt:

secret-tool lookup service cfg-lab user sysadmin
busctl --user list | grep org.freedesktop.secrets

The value comes back, and the bus name now belongs to oo7:

f44-lab-token-7731
org.freedesktop.secrets                      6853 oo7-daemon      sysadmin :1.16         [email protected] -       -

The migration leaves the original ~/.local/share/keyrings/login.keyring in place, adds a login.keyring.migrated marker, and writes the new store under ~/.local/share/keyrings/v1. Keeping the original file is what makes a rollback safe: after the Workstation went back to Fedora 44, gnome-keyring read the same secret again.

VS Code: “No usable version of libssl was found”

Fedora 45 ships OpenSSL 4. VS Code’s extension signature checker is a .NET binary that needs libssl.so.3. On a fresh Fedora 45 install without it, every extension install fails with “Signature verification failed”. The upgraded Workstation did not hit this: extension installs worked, because the upgrade pulled in openssl3-libs as a dependency of another package. The Server did not get it. Check rather than assume:

rpm -q openssl3-libs || sudo dnf install -y 'libssl.so.3()(64bit)'

The same library fixes other .NET-based tools that stop working on Fedora 45. The VS Code on Fedora guide has the full error and the Flatpak alternative.

“package … does not verify: … NOKEY” from rpm -i

RPM on Fedora 45 enforces signature verification (%_pkgverify_level is all). Installing a downloaded package with plain rpm -ivh when its key is not imported now fails, where Fedora 44 printed a warning and carried on:

Verifying...                          ########################################
Preparing...                          ########################################
	package rpmfusion-free-release-45-0.2.noarch does not verify: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY

Install local packages through DNF instead. DNF installs the file and prints Warning: skipped OpenPGP checks for 1 package from repository: @commandline, so only use it on files you downloaded from the vendor over HTTPS:

sudo dnf install ./rpmfusion-free-release-45.noarch.rpm

Old scripts that call rpm -ivh on vendor packages are what break. Either import the vendor key with rpm --import first or switch the script to dnf install. The RPM Fusion and codecs guide already uses the DNF form.

Clean up after the upgrade

Pull the first round of updates (and decide on updates-testing)

Our upgraded systems came up with updates-testing enabled, and RPM Fusion did the same with its own testing repos. dnf repolist on the Workstation listed updates-testing, rpmfusion-free-updates-testing and rpmfusion-nonfree-updates-testing. On the Server, the first dnf upgrade after the upgrade wanted 112 upgrades and 5 new packages, all of them from updates-testing. Switch it off and the same command reports nothing to do:

sudo dnf config-manager setopt updates-testing.enabled=0
sudo dnf upgrade --refresh

DNF5 writes the change to an override file instead of editing the repo file:

# Generated by libdnf5.
# Do not modify this file manually, use dnf5 config-manager instead.
[updates-testing]
enabled=0

That file is /etc/dnf/repos.override.d/99-config_manager.repo. If dnf repo list shows no testing repos on your machine, skip this step. Keep testing on only if you want fixes before they reach the stable updates repo.

Remove orphans and look for leftovers

Preview what DNF considers unneeded before removing anything:

sudo dnf autoremove --assumeno

On the Server it flagged eight packages (9 MiB), mostly old fwupd plugin dependencies:

Removing:
 flashrom           x86_64 0:1.6.0-6.fc45      fedora       6.9 MiB
 libbabeltrace      x86_64 0:1.5.11-22.fc45    fedora     518.8 KiB
 libftdi            x86_64 0:1.5-27.fc45       fedora      89.2 KiB
 libjaylink         x86_64 0:0.5.0-1.fc45      fedora     101.4 KiB
 libjcat            x86_64 0:0.2.6-1.fc45      fedora     213.6 KiB
 python3-libxml2    x86_64 0:2.13.9-4.fc45     fedora       1.2 MiB
 qrencode-libs      x86_64 0:4.1.1-13.fc45     fedora     164.7 KiB
 sudo-python-plugin x86_64 0:1.9.17-16.p2.fc45 fedora     104.0 KiB

Transaction Summary:
 Removing:           8 packages

Read the list before you confirm. autoremove only knows install reasons, so a library you use directly but installed as a dependency shows up here as well. Then run the three checks that replace the DNF4 extras plugin:

sudo dnf check
dnf list --extras
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

dnf check printed nothing and exited 0 on the Server, dnf list --extras returned “No matches found”, and find turned up no .rpmnew files. Packages from a vendor repo with no Fedora 45 tree, such as Docker CE on its fc44 builds, are what --extras lists on a desktop. If you do get some, sudo dnf install rpmconf && sudo rpmconf -a walks you through merging them.

Point lagging vendor repos back at a working tree

Docker CE keeps working on Fedora 45 with its Fedora 44 packages, but its repo fails every refresh and you get no Docker updates. Until Docker publishes fedora/45, point the repo at the Fedora 44 tree with an override:

sudo dnf config-manager setopt docker-ce-stable.baseurl="https://download.docker.com/linux/fedora/44/\$basearch/stable"
sudo dnf makecache --refresh

Once curl -s -o /dev/null -w '%{http_code}\n' https://download.docker.com/linux/fedora/45/ returns 200, remove the override and sync only the Docker packages. The Docker on Fedora guide has the full setup:

sudo dnf config-manager unsetopt docker-ce-stable.baseurl
sudo dnf distro-sync --refresh containerd.io 'docker-*'

The same pattern works for VirtualBox or any other repo that lags a release. Keep the distro-sync scoped to the vendor’s packages. If you installed packages from updates-testing and then switched it off, a full distro-sync would also downgrade any of them that have not reached the stable updates repo yet.

Where the Fedora repo files went

Fedora 45 moves the packaged repo definitions from /etc/yum.repos.d to /usr/share/dnf5/repos.d. After the upgrade, the Server’s /etc/yum.repos.d was empty, and the four Fedora repo files (fedora, fedora-updates, fedora-updates-testing, fedora-cisco-openh264) lived under /usr. Third-party repo files still go to /etc/yum.repos.d. The move only happens for files you never edited. If you edited fedora.repo in place (for a local mirror, say), the edited copy stays in /etc and silently overrides the new one. Recreate those changes with dnf config-manager setopt, which survives package updates, then remove the edited file. The DNF5 cheat sheet has the rest of the config-manager syntax.

Old kernels

Both machines kept two Fedora 44 kernels next to the new one, which is the three-kernel install limit. Leave them. They are the fallback entries in the GRUB menu, and the next two Fedora 45 kernel updates replace them anyway.

Roll back to Fedora 44

Both methods start the same way. Set a Fedora 44 kernel as the default boot entry while you are still on Fedora 45, because the Fedora 45 kernel in /boot has no modules on a Fedora 44 root:

sudo grubby --info=ALL | grep ^kernel
sudo grubby --set-default /boot/vmlinuz-7.2.7-200.fc44.x86_64

Pick the newest fc44 path from the first command. grubby confirms the new default:

The default is /boot/loader/entries/4c40fb0b1eae4e46ba66d796c4901719-7.2.7-200.fc44.x86_64.conf with index 1 and kernel /boot/vmlinuz-7.2.7-200.fc44.x86_64

Server: merge the LVM snapshot

Merging a snapshot into a mounted root cannot happen live, so LVM schedules it for the next activation. Set VG again, because the shell that set it before the upgrade is long gone:

VG=fedora_cfg-f44up-srv
sudo lvconvert --merge "$VG/root-pre-f45"
sudo reboot

LVM answers with the delay notice:

  Delaying merge since origin is open.
  Merging of snapshot fedora_cfg-f44up-srv/root-pre-f45 will occur on next activation of fedora_cfg-f44up-srv/root.

The machine boots straight into Fedora 44 while the merge finishes in the background (sudo lvs -a shows the progress in the Data% column). On the test Server, MariaDB was back on 11.8 with its original data directory, PostgreSQL reported collation version 2.43 again, and both Podman containers started under Podman 5. What the snapshot does not restore is /boot. Once lvs no longer lists the snapshot, remove the Fedora 45 kernel files and put the Fedora 44 copy back:

sudo sh -c 'rm -f /boot/*.fc45.x86_64* /boot/loader/entries/*.fc45.x86_64.conf'
sudo tar -C / -xpf /root/boot-f44.tar
sudo grubby --info=ALL | grep ^kernel

Only Fedora 44 entries remain, and the next reboot came up clean with no failed units:

kernel="/boot/vmlinuz-7.2.7-200.fc44.x86_64"
kernel="/boot/vmlinuz-6.19.10-300.fc44.x86_64"
kernel="/boot/vmlinuz-0-rescue-4c40fb0b1eae4e46ba66d796c4901719"

The sh -c wrapper matters, because /boot/loader/entries is not readable by your user and an unwrapped glob silently matches nothing. The tar also restores /boot/efi, which puts the Fedora 44 shim and GRUB binaries back. rpm -V shim-x64 grub2-efi-x64 printed nothing afterwards on the Workstation, so the files matched the Fedora 44 packages again.

Workstation: swap the Btrfs root subvolume

The kernel command line mounts the subvolume by name (rootflags=subvol=root). Rename the current root out of the way, create a writable snapshot of the Fedora 44 snapshot under the name root, and move the two nested subvolumes across. You can do all of it from the running Fedora 45 system:

sudo mount -o subvolid=5 /dev/sda3 /mnt/btrfs-top
cd /mnt/btrfs-top
sudo mv root root-f45-failed
sudo btrfs subvolume snapshot root-f44-pre-upgrade root
for s in var/lib/portables var/lib/machines; do sudo rmdir root/$s && sudo mv root-f45-failed/$s root/$s; done
cd / && sudo umount /mnt/btrfs-top
sudo reboot

Before the reboot, sudo btrfs subvolume list / should show the new root with the two nested subvolumes under it, and root-f45-failed next to it. After the reboot the Workstation was on Fedora 44 and GNOME 50, the three extensions that were out of date on GNOME 51 were active again, and the keyring secret was readable through gnome-keyring. Two leftovers need cleaning. The snapshot was taken during the GNOME Software download, so it carried 406 MB of partial downloads in /var/lib/dnf:

sudo dnf system-upgrade clean

Then restore /boot with the same rm and tar commands as the Server. This is where the order of the backup matters. On the test machine the tar was taken after the snapshot, so it was not inside the restored root, and it had to be fished out of root-f45-failed/root/boot-f44.tar. Once Fedora 44 runs well again, delete the failed root with sudo btrfs subvolume delete /mnt/btrfs-top/root-f45-failed (mounted the same way) to get its space back.

Troubleshooting errors from the test runs

Error: “Unknown argument “remove-retired-packages” for command “dnf5″”

DNF5 suggests installing dnf5-command(remove-retired-packages), but no Fedora 45 package provides it. Use dnf list --extras from the cleanup section and remove what it lists by name.

Error: “Unknown argument “–unsatisfied” for command “repoquery””

DNF5 dropped repoquery --unsatisfied. sudo dnf check does the same job for the installed package database. No output and exit code 0 means no broken dependencies.

“Unable to upgrade: authentication required” in GNOME Software

The polkit prompt never got an answer. It happened twice in testing: once when the screen locked while the prompt was open, and once when GNOME Software had been launched from an SSH shell instead of from the desktop. Start Software from the desktop, click Download again, and answer the prompt.

Status code: 404 for …/fedora/45/…/repomd.xml

A vendor repo has no Fedora 45 tree yet. It is harmless under Fedora’s default skip_if_unavailable=True, but it buries real errors in the output. Disable the repo for the download with --disablerepo, then use the baseurl override from the cleanup section until the vendor catches up.

Quick checks after your own upgrade

Which of these you hit depends on how far Fedora’s mirrors and the third-party vendors had got when you ran the upgrade. This is what our runs showed, and what to look at on your own machine:

Item	On our upgrade runs	What to check
RELEASE_TYPE in os-release	development, Prerelease in the name	stable once fedora-release is updated
updates-testing	Enabled, all 112 first-day updates came from it	dnf repo list; switch it off for stable-only updates
RPM Fusion updates repos	404 for Fedora 45	Re-run the repo check
Docker CE, VirtualBox, CUDA	No Fedora 45 tree	curl the vendor URL, then remove the override
GNOME Shell	51 release candidate	gnome-shell --version, then extension support for that version
Downgrades in the transaction	14 packages	Read the Downgrading section of the transaction summary

The database, Podman, Python and signature fixes come from the Fedora 45 package set itself, so they apply to any Fedora 45 upgrade. If SELinux denials appear after your own upgrade, the SELinux survival guide for Fedora covers reading them without switching to permissive. When the box is settled, work through the things to do after installing Fedora 45 list for the parts a release upgrade does not touch.