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

We took two fresh machines from Fedora 44 to 45 with the same commands, a Workstation with RPM Fusion, Chrome, VS Code, Docker CE and Flatpak apps, and a Server running MariaDB, PostgreSQL, Cockpit and rootless Podman. In November 2026 we ran the CLI path again against the final Fedora 45 repos on a Fedora 44 VM carrying six vendor repos, and every vendor repo status below comes from that rerun.

You get both upgrade paths, the pre-checks that catch lagging repos, a fix for every breakage above, and two tested ways back to Fedora 44. 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

We installed the first two machines 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 and XFS on LVM with a 15 GiB root on Server. Workstation got 4 vCPU and 8 GiB RAM, Server 2 vCPU and 4 GiB. Our third run is the November rerun against the final repos, on a Fedora 44 Cloud Edition VM (4 vCPU, 6 GiB, Btrfs) with MariaDB, PostgreSQL, Cockpit, rootless Podman, Docker CE and five more vendor repos on it.

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

Behind those breakages sit major version jumps, 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. The rerun confirmed every one of those jumps in the final package set, so the fixes further down apply whenever you upgrade.

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)'

Our rerun VM started here, after its Fedora 44 updates and a reboot.

OS: Fedora Linux 44 (Cloud Edition) x86_64
Kernel: Linux 7.2.15-200.fc44.x86_64
Packages: 611 (rpm)
Memory: 595.52 MiB / 5.75 GiB (10%)
Disk (/): 1.76 GiB / 19.90 GiB (9%) - btrfs

Keep that output somewhere off the machine. After the upgrade you’ll run the same line and compare the release, the kernel and the package count.

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

We ran it on the rerun VM on November 3, 2026. Eight of the 17 enabled repos failed, and all of them belong to three vendors.

OK    cuda-fedora44-x86_64
OK    docker-ce-stable
OK    fedora
OK    fedora-cisco-openh264
FAIL  hashicorp
FAIL  pgdg14
FAIL  pgdg15
FAIL  pgdg16
FAIL  pgdg17
FAIL  pgdg18
FAIL  pgdg-common
OK    rpmfusion-free
OK    rpmfusion-free-updates
OK    rpmfusion-nonfree
OK    rpmfusion-nonfree-updates
OK    updates
FAIL  virtualbox

An OK is not always the full story, so read each vendor’s line against what it actually serves:

• Docker CE now has a complete fedora/45 tree: seven packages, docker-buildx-plugin, docker-compose-plugin and docker-model-plugin included. The upgrade replaced every Docker package with its fc45 build, and hello-world ran on the first boot. No override is needed any more.
• RPM Fusion passes, and the upgrade swaps in rpmfusion-*-release-45-0.2. Its free-fedora-45 metalink resolves, but every one of the 64 mirror URLs it returned on our VM pointed at RPM Fusion’s development/45 tree because releases/45 still answers 404. The release packages leave the stable -updates repos disabled (they are empty anyway) and turn on -updates-testing, which is where RPM Fusion’s Fedora 45 updates, newer ffmpeg builds included, come from. Leave that split alone; the cleanup section shows why.
• HashiCorp, PGDG and VirtualBox return 404 for every Fedora 45 path. The upgrade still runs, and their Fedora 44 packages stay installed without updates.
• NVIDIA CUDA passes only because its repo file hardcodes fedora44 instead of $releasever. NVIDIA has no fedora45 tree, so after the upgrade you keep getting the Fedora 44 CUDA builds.
• Google Chrome and VS Code passed on the Workstation because their URLs contain no release number. They are fine across Fedora upgrades.

If a failing repo ships something you can’t live without for a few weeks (a kernel module, say, or a PostgreSQL major that Fedora doesn’t package), wait for the vendor before upgrading. The Fedora third-party repo 404 guide has the per-vendor workaround for each of these, and the Terraform on Fedora guide covers the HashiCorp case in full.

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. We gave the test Server 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 decides whether to show the upgrade banner from Fedora’s collections feed, not from the mirrors. It offers a release marked Active and hides one marked Under Development. Check what the feed says before you go looking for a banner that isn’t there:

curl -s https://admin.fedoraproject.org/pkgdb/api/collections/ | python3 -c 'import json,sys; [print(c["version"], c["status"]) for c in json.load(sys.stdin)["collections"] if c["version"] in ("44","45")]'

We ran it again on the upgraded lab VM on November 3, 2026. Fedora 45 was already the stable release with its own repos, yet the feed still listed it as Under Development, so GNOME Software on that day showed no banner by itself. Fedora’s release engineering team changes the status by hand, so your result may differ, and the steps below cover both states.

45 Under Development
44 Active

While 45 reads Under Development, turn on the setting below so GNOME Software offers it anyway. Once the feed says Active, the banner appears on its own and you can skip this. If you do set it, undo it after the upgrade with gsettings reset org.gnome.software show-upgrade-prerelease, or GNOME Software will offer Fedora 46 long before it ships. 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=hashicorp (one flag per repo, and --disablerepo='pgdg*' takes all six PGDG repos) to keep the 404 noise out of the log. The rerun left them enabled on purpose: the download printed 32 Status code: 404 lines from HashiCorp, PGDG and VirtualBox, skipped those repos and carried on. DNF resolves the release, downloads every package, test-runs the transaction and imports the Fedora 45 key along with RPM Fusion’s 45 keys. Here is what our rerun reported.

Transaction Summary:
 Installing:        21 packages
 Upgrading:        589 packages
 Replacing:        602 packages
 Removing:           2 packages
 Downgrading:        6 packages

Total size of inbound packages is 525 MiB. Need to download 525 MiB.
After this operation, 15 MiB extra will be used (install 2 GiB, remove 2 GiB).

Replacing isn’t 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 two removals are the oldest Fedora 44 kernel (kernel-core and kernel-modules-core), dropped to stay inside the three-kernel limit. The downgrades look worse than they are. Fedora 44 updates had shipped newer builds than the Fedora 45 base tree, and system-upgrade is a distro-sync, so it aligns them to the new release. On the rerun that hit bind-libs, bind-utils and four PostgreSQL packages; the September Server had 14, adding fwupd, libdnf, libsecret, vim-minimal and python3-botocore. PostgreSQL goes from 18.6 back to 18.3 on both, 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 September Server’s offline transaction ran from 00:41:53 to 00:48:35, and SSH was back 443 s after the reboot command. The smaller rerun VM finished its transaction in 3 min 8 s and answered SSH on Fedora 45 after 219 s. Cockpit came up on the new release with no changes:

Cockpit’s overview names the edition the box was installed as, Cloud Edition here, and drops any development tag once the machine runs the final fedora-release package. A Server install shows Server Edition in the same spot.

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)'

Our rerun VM went from 611 to 623 packages and booted the Fedora 45 kernel.

OS: Fedora Linux 45 (Cloud Edition) x86_64
Kernel: Linux 7.2.15-300.fc45.x86_64
Packages: 623 (rpm)
Memory: 708.58 MiB / 5.75 GiB (12%)
Disk (/): 1.73 GiB / 19.90 GiB (9%) - btrfs

Then confirm the release type. RELEASE_TYPE=stable means the machine runs the final fedora-release package. If yours reads development, the box still carries the older fedora-release build, and the next sudo dnf upgrade pulls the package that switches it:

grep -E '^(PRETTY_NAME|RELEASE_TYPE)=' /etc/os-release

Ours came up stable, with no failed units and SELinux still enforcing.

The offline log is kept per boot, and it’s 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

Our rerun’s log ends with the key warning and the completion line. Note docker-ce-stable in the repository list, because Docker came across from its own Fedora 45 tree in the same transaction.

The following boots appear to contain offline transaction logs:
1 / 60e61ae9cd574896ad390f494663b0e4: 2026-11-03 10:53:01 44→45
Nov 03 10:56:09 f45-01 dnf5[638]: Warning: skipped OpenPGP checks for 616 packages from repositories: docker-ce-stable, fedora, rpmfusion-free, rpmfusion-nonfree, updates
Nov 03 10:56:09 f45-01 dnf5[638]: Transaction complete! Cleaning up and rebooting...
Nov 03 10:56:09 f45-01 dnf5[638]: 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 transaction started at 10:53:01 and finished at 10:56:09, so the whole offline phase took just over three minutes on a box this size. Finish the check with systemctl --failed and getenforce. All three 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

Our rerun VM logged the full instructions right after the first Fedora 45 boot, the same as the September Server.

Nov 03 10:56:23 f45-01 mariadb-check-upgrade[1029]: The datadir located at /var/lib/mysql needs to be upgraded using 'mariadb-upgrade' tool. This can be done using the following steps:
Nov 03 10:56:23 f45-01 mariadb-check-upgrade[1029]:   1. Back-up your data before with 'mariadb-upgrade'
Nov 03 10:56:23 f45-01 mariadb-check-upgrade[1029]:   2. Start the database daemon using 'systemctl start mariadb.service'
Nov 03 10:56:23 f45-01 mariadb-check-upgrade[1029]:   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 both runs. 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, template1 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__)"

On the rerun VM, the rebuilt venv runs on the final Python 3.15 interpreter:

3.15.0 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 AppIndicator line is the one that surprises people, because it came from Fedora’s own repos. The base fedora repo for 45 still carries Dash to Dock 105 and AppIndicator 64, and both declare shell versions only up to 50. Fedora’s updates repo now has Dash to Dock 110 and AppIndicator 66, built with GNOME 51 in their metadata.json, so if you use the RPM versions a plain sudo dnf upgrade after the upgrade brings both back. You can see both builds side by side:

dnf repoquery --available gnome-shell-extension-dash-to-dock gnome-shell-extension-appindicator --qf '%{name}-%{evr} %{repoid}\n'

On our Fedora 45 VM the query listed both builds of each extension, the older one from fedora and the GNOME 51 one from updates:

We unpacked the metadata.json from both pairs to be sure: the updates builds list shell versions 45 to 51, the base repo builds stop at 50. DNF always prefers the higher version, so you never have to name the repo. For extensions installed from the website, 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)

Start with the repo list, because it tells you where your updates will come from.

dnf repo list | grep -E 'testing|rpmfusion'

On our rerun against the final repos, Fedora’s own updates-testing stayed off. RPM Fusion’s came up on, and that’s by design. The upgrade installs rpmfusion-free-release-45-0.2 and its nonfree twin, which enable rpmfusion-free-updates-testing and rpmfusion-nonfree-updates-testing and leave the stable -updates repos disabled. Leave that split as it is, because the stable side has nothing in it yet. The checks below were run on the upgraded VM on November 3, 2026:

Read it from the top. The free-fedora-45 metalink resolves, but all 64 mirror URLs it returned (each host is listed once per protocol) pointed at RPM Fusion’s development/45 tree, because releases/45 still answers 404. The stable updates/45 tree exists and returns 200, yet both -updates repos report 0 packages. Everything newer than the base set lives in -updates-testing: on the same VM ffmpeg-9.0.2-3.fc45 came from rpmfusion-free-updates-testing while the base repo had 9.0.2-1, and akmod-nvidia resolved from rpmfusion-nonfree. Switching RPM Fusion to its stable updates repos today would cut you off from every fix it ships and gain you nothing.

The first dnf upgrade after the reboot proves the point. It wanted exactly two packages, and both came from the testing repos:

sudo dnf upgrade --refresh

Let them in. The 45-0.3 build only moves RPM Fusion’s repo files to /usr/share/dnf5/repos.d and keeps the same testing-on split. The testing split is temporary: a later release package switches you to the stable -updates repos, and you follow it automatically as long as you have no override of your own:

Package                                Arch   Version  Repository                             Size
Upgrading:
 rpmfusion-free-release                noarch 0:45-0.3 rpmfusion-free-updates-testing      5.6 KiB
   replacing rpmfusion-free-release    noarch 0:45-0.2 rpmfusion-free                      5.6 KiB
 rpmfusion-nonfree-release             noarch 0:45-0.3 rpmfusion-nonfree-updates-testing   5.8 KiB
   replacing rpmfusion-nonfree-release noarch 0:45-0.2 rpmfusion-nonfree                   5.7 KiB

If you already flipped RPM Fusion to its stable repos with dnf config-manager setopt, for example after an older version of this guide, the setting sits in /etc/dnf/repos.override.d/99-config_manager.repo and survives release package updates. Drop those four keys and the release package’s own defaults come back:

sudo dnf config-manager unsetopt rpmfusion-free-updates-testing.enabled rpmfusion-nonfree-updates-testing.enabled rpmfusion-free-updates.enabled rpmfusion-nonfree-updates.enabled
dnf repo list | grep rpmfusion

We switched and switched back on the lab VM. After the unsetopt, the list showed the two base repos and the two -updates-testing repos again, and the override file was left with only its header. Fedora’s own updates-testing is a different matter. If your list shows it, it was turned on by hand or carried over from an early install, and the Server in our first run wanted 112 packages from it. Switch it off with sudo dnf config-manager setopt updates-testing.enabled=0 unless you want Fedora fixes before they reach the stable updates repo. The things to do after installing Fedora 45 guide gives the same advice for fresh installs.

Remove orphans and look for leftovers

Preview what DNF considers unneeded before removing anything:

sudo dnf autoremove --assumeno

On the rerun VM it flagged three small libraries. The September Server flagged eight (9 MiB), mostly old fwupd plugin dependencies, so the list depends on what the box had installed:

Removing:
 qrencode-libs      x86_64 0:4.1.1-13.fc45     fedora     164.7 KiB
 sudo-python-plugin x86_64 0:1.9.17-18.p2.fc45 updates    104.0 KiB
 yajl               x86_64 0:2.1.0-41.fc45     fedora      81.7 KiB

Transaction Summary:
 Removing:           3 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 both the Server and the rerun VM, and find turned up no .rpmnew files. dnf list --extras came back empty on the Server. On the rerun it listed one package, pgdg-fedora-repo, because the PGDG repo that would carry its Fedora 45 build still returns 404. Packages from a vendor repo with no Fedora 45 tree are what --extras lists, so read it as a to-do list for the vendor overrides below. If you do get .rpmnew files, sudo dnf install rpmconf && sudo rpmconf -a walks you through merging them.

Point lagging vendor repos back at a working tree

HashiCorp, PGDG and VirtualBox packages keep working on Fedora 45 with their Fedora 44 builds, but those repos fail every refresh and you get no vendor updates. Until the vendor publishes a Fedora 45 tree, point the repo at its Fedora 44 tree with an override. We did this for HashiCorp on the rerun VM, the repo loaded again, and terraform installed from it.

sudo dnf config-manager setopt hashicorp.baseurl='https://rpm.releases.hashicorp.com/fedora/44/$basearch/stable'
sudo dnf makecache --refresh --repo=hashicorp

Once curl -s -o /dev/null -w '%{http_code}\n' https://rpm.releases.hashicorp.com/fedora/45/x86_64/stable/repodata/repomd.xml returns 200, remove the override so the repo follows $releasever again, then sync only that vendor’s packages:

sudo dnf config-manager unsetopt hashicorp.baseurl
sudo dnf distro-sync --refresh --repo=hashicorp

Docker CE no longer needs this. Its Fedora 45 tree carries all seven packages, buildx and the new docker-model-plugin included, so if you pointed docker-ce-stable at fedora/44 earlier, remove the override with sudo dnf config-manager unsetopt docker-ce-stable.baseurl. The Docker on Fedora guide has the full setup.

One Docker leftover deserves a look. The October version of our third-party repo 404 guide added a second repo, docker-ce-f44-plugins, pinned to the Fedora 44 tree and limited to buildx. We rebuilt that setup on a Fedora 44 VM and previewed the upgrade with dnf distro-sync --releasever=45 --assumeno. Buildx still moved to 0.38.1-1.fc45 from docker-ce-stable, replacing the fc44 build, so the old repo does not block the upgrade. It does stay enabled afterwards, still pointing at fedora/44, and it will start failing refreshes the day Docker retires that tree. Check whether you have it:

ls /etc/yum.repos.d/ | grep docker

Our rebuilt VM listed both files:

docker-ce-f44-plugins.repo
docker-ce.repo

Only docker-ce.repo belongs there. If the plugins file shows up, follow the section on retiring the scoped Fedora 44 buildx repo in the refreshed 404 guide: it deletes the file and moves buildx onto the fc45 build. After we removed it, dnf repo list showed docker-ce-stable as the only Docker repo.

The override pattern above works for PGDG, 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. The rerun VM matched it, with only vendor files (Docker, HashiCorp, PGDG, CUDA, VirtualBox and RPM Fusion) left in /etc/yum.repos.d. Third-party repo files still go there, although the newest rpmfusion-*-release builds move RPM Fusion’s own files to /usr/share/dnf5/repos.d as well. 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, and check that rpm -q kernel-core still lists that kernel. The rerun VM kept boot entries for two Fedora 44 kernels the upgrade had already removed, so an entry alone proves nothing. 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

Those kernel paths come from the September runs, where both rollbacks below were tested. Your newest Fedora 44 kernel will carry a later build number, so copy the path from your own grubby output rather than from here.

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. On November 3, 2026 that was HashiCorp, every PGDG repo and VirtualBox. It’s 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 feeds and the third-party vendors have got when you run the upgrade. This is what the final-repo rerun showed on November 3, 2026, and what to look at on your own machine:

Item	On the final-repo rerun	What to check
RELEASE_TYPE in os-release	stable	development means an old fedora-release build; sudo dnf upgrade fixes it
Fedora updates-testing	Off	dnf repo list; switch it off for stable-only updates
RPM Fusion	45-0.2 release packages, every metalink URL on development/45 (releases/45 is 404), -updates off and empty, packages from -updates-testing	Leave the testing repos on; undo any old setopt with unsetopt
Docker CE	Full Fedora 45 tree, buildx, compose and model plugins included	Remove any old fedora/44 baseurl override and any leftover docker-ce-f44-plugins.repo
HashiCorp, PGDG, VirtualBox	404 for Fedora 45	curl the vendor URL, keep the fedora/44 override until it returns 200
NVIDIA CUDA	No fedora45 tree; repo file pinned to fedora44	Nothing breaks, you stay on the Fedora 44 builds
GNOME Software banner	Feed listed 45 as Under Development on November 3	The collections curl check, then the gsettings key if needed
GNOME Shell	gnome-shell-51.1 in the Fedora 45 repos	gnome-shell --version, then extension support for that version
Fedora-packaged Dash to Dock and AppIndicator	110 and 66 with GNOME 51 in updates; the fedora repo builds (105, 64) stop at GNOME 50	sudo dnf upgrade after the first boot
Downgrades in the transaction	6 packages (14 on the September Server)	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.