A vendor repo with no Fedora 45 tree does not stop dnf. It prints “Usable URL not found”, loads every other repo and carries on, so the failure surfaces one command later as “No match for argument: terraform”, or worse, as dnf swapping your PostgreSQL server for a different build in the middle of an unrelated install. Find the broken repo before you install anything from it.
Most third-party repo files build their URL from $releasever, so on Fedora 45 they ask for a /45/ directory that Docker, Oracle, HashiCorp and the PostgreSQL project publish on their own schedule. NVIDIA hardcodes the release in its repo file instead, which fails the same way. Below is the fix that worked per vendor. Pinning to Fedora 44 is not always safe, and two vendors prove it. We re-ran every vendor repo row on 3 November 2026 against the final Fedora 45 repos, on a fresh install with SELinux enforcing and Secure Boot on, and on a box upgraded from Fedora 44.
Third-party repo status on Fedora 45
The big change since our October run is Docker: its Fedora 45 tree now carries the full package set, buildx included. Every vendor row below comes from one Fedora 45 VM where we installed real packages from each repo instead of trusting a curl of the metadata; the release-agnostic row was only probed this time:
| Repo | Fedora 45 tree | What breaks | Fix that worked | Checked |
|---|---|---|---|---|
| Docker CE | Full tree (HTTP 200): 7 packages, all fc45. The documented install takes six of them: docker-ce and docker-ce-cli 29.9.2, containerd.io 2.4.2, docker-buildx-plugin 0.38.1, docker-compose-plugin 5.7.0 and docker-ce-rootless-extras | Nothing. An upgrade from 44 moves every Docker package to its fc45 build | None. Drop the scoped Fedora 44 buildx repo if you added it | 3 Nov 2026 |
| HashiCorp | 404 | No match for argument: terraform | Pin the repo to the 44 tree with a dnf5 override | 3 Nov 2026 |
| Oracle VirtualBox | 404 | Pinned to 44: nothing provides libvpx.so.9()(64bit) | RPM Fusion VirtualBox with a signed akmod | 3 Nov 2026 |
| NVIDIA CUDA | No fedora45 tree (404); the repo file is hardcoded to fedora44 | Nothing, because the file never asks for 45 | Install from the fedora44 repo, driver packages excluded | 3 Nov 2026 |
| PGDG PostgreSQL | 404 for every stable version (14 to 18) and for common; F-45 repo RPM 404; testing tree present | Pinned to 44: nothing provides libperl.so.5.42()(64bit) | Repo RPM from F-44, then the PGDG testing tree for 45 | 3 Nov 2026 |
| RPM Fusion | releases/45 404; the metalink resolves to development/45 | Nothing. Release package 45-0.2 leaves the -updates repos disabled and empty and serves packages from -updates-testing, where 45-0.3 already waits | None needed | 3 Nov 2026 |
| VS Code, GitHub CLI, Tailscale | One tree for all Fedora releases | Nothing | None needed | Installed 4 Oct, probed 3 Nov 2026 |
The release-agnostic repos at the bottom use one URL for every Fedora release, which is why they never 404. Anything with $releasever in the base URL depends on the build calendar each vendor keeps, so treat this table as dated evidence, not a promise. The HashiCorp, PGDG and RPM Fusion rows are the ones most likely to change next, and the undo table near the end tells you how to spot it on your own machine.
Finding the repo that fails
Fedora ships skip_if_unavailable=True in /usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf. That’s why a dead repo is a warning and not an error, and why it’s so easy to miss. Confirm the setting on your machine:
dnf --dump-main-config | grep -E "^skip_if_unavailable"Fedora 45 reports it enabled:
skip_if_unavailable = 1Refresh the metadata and keep only the repo name that sits above each failure. The grep -v drops the raw “Status code: 404” lines, which repeat once per mirror attempt:
sudo dnf makecache --refresh 2>&1 | grep -vE "Status code" | grep -B1 "Usable URL not found" | grep -v -- "--"With the vendor repos added the way each vendor documents, eight repos had no Fedora 45 tree on our box. Six of them are the PGDG stable repos, because the PGDG repo RPM enables PostgreSQL 14 through 18 plus a common repo:
Fedora 45 - x86_64 - VirtualBox 100% | 8.7 KiB/s | 27.6 KiB | 00m03s
>>> Usable URL not found
PostgreSQL 18 for Fedora 45 - x86_64 100% | 211.0 B/s | 584.0 B | 00m03s
>>> Usable URL not found
PostgreSQL 17 for Fedora 45 - x86_64 100% | 209.0 B/s | 584.0 B | 00m03s
>>> Usable URL not found
PostgreSQL 16 for Fedora 45 - x86_64 100% | 226.0 B/s | 584.0 B | 00m03s
>>> Usable URL not found
PostgreSQL 15 for Fedora 45 - x86_64 100% | 348.0 B/s | 584.0 B | 00m02s
>>> Usable URL not found
PostgreSQL 14 for Fedora 45 - x86_64 100% | 361.0 B/s | 584.0 B | 00m02s
>>> Usable URL not found
PostgreSQL common RPMs for Fedora 45 - 100% | 406.0 B/s | 584.0 B | 00m01s
>>> Usable URL not found
Hashicorp Stable - x86_64 ???% | 620.0 B/s | 314.0 B | 00m01s
>>> Usable URL not foundDocker is missing from that list, which is the first sign its row changed. Those are display names, though, and every fix below needs the repo ID. Map them:
dnf repo list --enabled | grep -iE "virtualbox|hashicorp|pgdg|docker"The first column is the ID:
docker-ce-stable Docker CE Stable - x86_64
hashicorp Hashicorp Stable - x86_64
pgdg14 PostgreSQL 14 for Fedora 45 - x86_64
pgdg15 PostgreSQL 15 for Fedora 45 - x86_64
pgdg16 PostgreSQL 16 for Fedora 45 - x86_64
pgdg17 PostgreSQL 17 for Fedora 45 - x86_64
pgdg18 PostgreSQL 18 for Fedora 45 - x86_64
pgdg-common PostgreSQL common RPMs for Fedora 45 - x86_64
virtualbox Fedora 45 - x86_64 - VirtualBoxBefore pinning anything, ask the vendor which release directories exist. This loop probes the HashiCorp tree for 45, 44 and 43:
for v in 45 44 43; do printf "%s %s\n" $v $(curl -s -o /dev/null -w "%{http_code}" https://rpm.releases.hashicorp.com/fedora/$v/x86_64/stable/repodata/repomd.xml); doneA 200 means that tree has metadata. Fedora 44 is still the newest one HashiCorp publishes:
45 404
44 200
43 200Swap the URL for any other vendor. The repodata/repomd.xml path at the end stays the same for every yum-style repo, and the same diagnosis in the terminal looks like this:
A repo that answers 200 for 45 is not automatically complete. Our October run proved that with Docker, so the next section checks the contents of the tree as well as its existence.
Some stale packages come from Fedora’s own repos
Not every Fedora 45 package problem is a third-party 404. Two popular GNOME extensions that Fedora packages itself get marked OUT OF DATE by GNOME when they come from the wrong repo, as our Workstation checklist found. No repo is missing here. The base fedora repo, frozen at release, carries Dash to Dock 105 and AppIndicator 64, while the updates repo now ships Dash to Dock 110 and AppIndicator 66. Ask dnf which builds each repo holds:
dnf repoquery --qf "%{name} %{version}-%{release} %{repoid}\n" gnome-shell-extension-dash-to-dock gnome-shell-extension-appindicator 2>/dev/null | sortWe unpacked each RPM’s metadata.json to check the supported shells. The fedora builds stop at GNOME 50, and the updates builds add GNOME 51, which is the shell Fedora 45 runs. An install on a box with the updates repo enabled picks the new builds without any pin:
The fix here is sudo dnf upgrade --refresh before installing extensions, never a repo override. If you disabled updates on a slow connection, turn it back on. Enabling the extensions after a log out and checking their state is covered in the things to do after installing Fedora 45 guide.
Docker CE: the Fedora 45 tree now carries buildx
In October, Docker’s Fedora 45 tree held five packages and no docker-buildx-plugin, so the documented install failed with “No match for argument: docker-buildx-plugin”. That gap is closed. Add the repo the way Docker documents it:
sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repoList the newest build of every package Docker now ships for Fedora 45:
dnf repoquery --repo=docker-ce-stable --latest-limit=1 --qf "%{name} %{version}-%{release}\n" 2>/dev/null | sortSeven packages, every one tagged fc45, with buildx and the model plugin back in the set:
containerd.io 2.4.2-3.fc45
docker-buildx-plugin 0.38.1-1.fc45
docker-ce 29.9.2-1.fc45
docker-ce-cli 29.9.2-1.fc45
docker-ce-rootless-extras 29.9.2-1.fc45
docker-compose-plugin 5.7.0-1.fc45
docker-model-plugin 1.2.9-1.fc45The documented install command now works as written, with no second repo:
sudo dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginStart the daemon and check that the plugins answer:
sudo systemctl enable --now docker
sudo docker buildx version; sudo docker compose versionBoth plugins report the Fedora 45 builds:
github.com/docker/buildx v0.38.1 0dbe87f36ed472fe36b6796c3f70b4210a731fc5
Docker Compose version v5.7.0The repo listing and the installed builds, captured on the lab box:
A version string proves little on its own, so we went further. A docker buildx build from a fedora-minimal:45 base produced an image that printed built-on-45 when run, and an nginx service brought up with docker compose up -d answered HTTP/1.1 200 OK on port 8080. Non-root access, SELinux bind mounts and firewall rules are covered in the Docker on Fedora guide. To push the images you build to a self-hosted registry, the private Docker registry setup on Fedora uses these same Docker CE packages on its client and can run the registry container on them too.
One trap is still live. Do not install Fedora’s own docker-buildx package next to Docker CE. It requires Fedora’s docker-cli, which conflicts with docker-ce-cli, and dnf refuses unless you let it remove the Docker CE CLI:
- package docker-buildx-0.37.1-1.fc45.x86_64 from fedora requires docker-cli, but none of the providers can be installed
- package docker-buildx-0.38.0-1.fc45.x86_64 from updates requires docker-cli, but none of the providers can be installed
- installed package docker-ce-cli-1:29.9.2-1.fc45.x86_64 conflicts with docker-ce-cli provided by docker-cli-29.7.2-1.fc45.x86_64 from fedoraThe name is the giveaway. Docker CE’s plugin is docker-buildx-plugin, while Fedora’s is docker-buildx, and only the first one belongs on a Docker CE host.
Upgrading from Fedora 44 with Docker CE installed
The upgrade path needs no Docker fix either. We installed Docker CE on a Fedora 44 VM from the stock docker-ce.repo, which gave docker-ce-29.9.2-1.fc44 and docker-buildx-plugin-0.38.1-1.fc44, then ran the system upgrade with no override of any kind:
sudo dnf -y system-upgrade download --releasever=45The transaction pulled each Docker package from docker-ce-stable and swapped it for the same version rebuilt for 45 (trimmed to two of the six Docker lines):
docker-buildx-plugin x86_64 0:0.38.1-1.fc45 docker-ce-stable 72.4 MiB
replacing docker-buildx-plugin x86_64 0:0.38.1-1.fc44 docker-ce-stable 72.4 MiB
docker-ce x86_64 3:29.9.2-1.fc45 docker-ce-stable 111.2 MiB
replacing docker-ce x86_64 3:29.9.2-1.fc44 docker-ce-stable 111.2 MiBThe same download step logged “Usable URL not found” for VirtualBox, all six PGDG repos and HashiCorp, and still finished with Complete!. After sudo dnf5 offline reboot, the box came back on Fedora 45 with every Docker package on an fc45 build and hello-world running:
That terminal also answers two questions the next sections deal with. NVIDIA’s repo file still names fedora44 after the upgrade, and RPM Fusion lands on its testing repos. The full upgrade walkthrough, with the database and Python fixes it needs, is in our Fedora 44 to 45 upgrade guide.
Retiring the scoped Fedora 44 buildx repo
If you followed the October version of this guide, your box has a docker-ce-f44-plugins repo limited to docker-buildx-plugin, and buildx installed from it carries an fc44 tag. It still works, but it’s now the wrong source. Confirm the 45 tree has the plugin before you remove anything:
dnf repoquery --repo=docker-ce-stable docker-buildx-plugin 2>/dev/null | grep fc45Two Fedora 45 builds came back on our box:
docker-buildx-plugin-0:0.38.0-1.fc45.x86_64
docker-buildx-plugin-0:0.38.1-1.fc45.x86_64Delete the scoped repo file and let dnf move the plugin to the 45 build:
sudo rm /etc/yum.repos.d/docker-ce-f44-plugins.repo
sudo dnf -y upgrade --refresh docker-buildx-plugindnf replaced the fc44 package from the old scoped repo with the fc45 one from Docker’s stable repo, and rpm -q docker-buildx-plugin then printed docker-buildx-plugin-0.38.1-1.fc45.x86_64:
Leaving the old repo in place is not dangerous today, because the .fc45 release tag sorts above .fc44 and the 45 build wins on every upgrade. It is still a repo pointing at an older release that nobody remembers adding, and that is exactly how the next upgrade picks up a stray package. Remove it.
HashiCorp (Terraform, Packer): a pin to the 44 tree
HashiCorp still has no Fedora 45 tree at all. HashiCorp’s docs fetch the repo file with wget and tee; the dnf5 equivalent writes the same file:
sudo dnf config-manager addrepo --from-repofile=https://rpm.releases.hashicorp.com/fedora/hashicorp.repoThe install then fails with nothing more than a missing package:
sudo dnf -y install terraform 2>&1 | grep -vE "Status code: 404" | tail -6The repo loaded empty:
>>> Usable URL not found
Repositories loaded.
Failed to resolve the transaction:
No match for argument: terraform
You can try to add to command line:
--skip-unavailable to skip unavailable packagesDo not edit /etc/yum.repos.d/hashicorp.repo by hand. dnf5 can override a single key of one repo, and it records the change in its own file where you can see it and undo it later:
sudo dnf config-manager setopt hashicorp.baseurl=https://rpm.releases.hashicorp.com/fedora/44/\$basearch/stableThe override lands in /etc/dnf/repos.override.d/99-config_manager.repo:
# Generated by libdnf5.
# Do not modify this file manually, use dnf5 config-manager instead.
[hashicorp]
baseurl=https://rpm.releases.hashicorp.com/fedora/44/$basearch/stableInstall from the pinned tree:
sudo dnf -y install terraform packerConfirm both binaries run:
terraform version | head -1; packer version | head -1; rpm -q terraform packerBoth work on Fedora 45:
Terraform v1.17.1
Packer v1.16.2
terraform-1.17.1-1.x86_64
packer-1.16.2-1.x86_64The override file, the versions and the linkage check, captured on the lab box:
HashiCorp’s pin is safe because ldd /usr/bin/terraform says “not a dynamic executable”, so nothing in the binary depends on a Fedora 45 library. Hold every pin to the same test before you trust it:
- The vendor’s 45 tree returns 404 and its 44 tree returns 200.
- The pinned packages are static binaries, or link only against sonames Fedora 45 still ships.
- The pin lives in
/etc/dnf/repos.override.d/, never in a hand-edited.repofile.
VirtualBox and PGDG both fail the second line, and the next sections show what that looks like. Full Terraform and OpenTofu setup lives in the Terraform on Fedora guide.
VirtualBox: RPM Fusion instead of a pin
The Oracle repo 404s on Fedora 45 in the same way as the HashiCorp one. If you followed Oracle’s instructions, this repo file is already on the box; if you never added it, skip to the RPM Fusion part of this section:
sudo dnf config-manager addrepo --from-repofile https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repoProbe Oracle’s 45 and 44 directories:
for v in 45 44; do printf "%s %s\n" $v $(curl -s -o /dev/null -w "%{http_code}" http://download.virtualbox.org/virtualbox/rpm/fedora/$v/x86_64/repodata/repomd.xml); doneOnly the 44 tree answers:
45 404
44 200The obvious fix fails here, and the way it fails is worth seeing. Pin the virtualbox repo to the 44 tree. The Oracle repo file sets repo_gpgcheck=1, so run one makecache for that repo first: dnf asks to import Oracle’s key there, and without it the next command fails on “repomd.xml GPG signature verification error: Signing key not found” instead of showing the real problem.
sudo dnf config-manager setopt virtualbox.enabled=1 virtualbox.baseurl=http://download.virtualbox.org/virtualbox/rpm/fedora/44/\$basearch
sudo dnf makecache --repo=virtualboxNow ask dnf what it would install:
sudo dnf install --assumeno VirtualBox-7.2 2>&1 | tail -7Every build in the Oracle tree needs a library Fedora 45 no longer ships:
- nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.22_175245_fedora40-1.x86_64 from virtualbox
- nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.2_170484_fedora40-1.x86_64 from virtualbox
- nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.4_170995_fedora40-1.x86_64 from virtualbox
- nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.6_172322_fedora40-1.x86_64 from virtualbox
- nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.8_173730_fedora40-1.x86_64 from virtualbox
You can try to add to command line:
--skip-broken to skip uninstallable packagesNote the fedora40 in every package name, including the new 7.2.22 build Oracle added since October: the builds in Oracle’s 44 directory are made on Fedora 40. Fedora 45 ships libvpx 1.17.0, which provides libvpx.so.12 only. No pin can fix a missing soname.
Undo that pin and switch the Oracle repo off. Pinned, it loads and produces only these dependency errors. Unpinned, it 404s on every dnf run:
sudo dnf config-manager unsetopt virtualbox.baseurl
sudo dnf config-manager setopt virtualbox.enabled=0RPM Fusion builds VirtualBox against Fedora 45 itself. Enable the free repo (the RPM Fusion setup explains the free and nonfree split):
sudo dnf -y install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpmOn a Secure Boot machine, create the akmods signing key before the akmod is installed. Our October run did it the other way round, and the first build came out unsigned because the key didn’t exist yet. The commands come from RPM Fusion’s Secure Boot howto, which also lists kmodtool and openssl; the order is our recommendation from that failure:
sudo dnf -y install akmods mokutil
sudo kmodgenca -aThe akmod builds against kernel-devel for the running kernel, and the Fedora repos keep only the release build and the newest update of kernel-devel. If kernel-devel-$(uname -r) fails with “No match for argument”, run sudo dnf upgrade --refresh and reboot into the new kernel first. Then install VirtualBox, its akmod and the headers:
sudo dnf -y install VirtualBox akmod-VirtualBox kernel-devel-$(uname -r)The akmod package starts the module build in the background when the install finishes. Run akmods in the foreground so you know the build is done before you load anything:
sudo akmods --kernels $(uname -r)The module is built and signed with the new key, yet the kernel still refuses it:
That is the expected state, not a broken build. modinfo -F signer vboxdrv names the akmods key, and mokutil --test-key says that key “is not enrolled”, so the firmware has no reason to trust it yet. Queue it for MOK enrollment. You set a one-time password here and type it again in the blue MokManager screen on the next boot:
sudo mokutil --import /etc/pki/akmods/certs/public_key.derReboot and press a key during the short countdown when shim offers MOK management. Choose Enroll MOK, Continue and Yes, enter that password, then pick Reboot. The NVIDIA driver guide has screenshots of each MokManager screen. Back in Fedora, confirm the modules load with Secure Boot still on:
mokutil --sb-state; lsmod | grep -E "^vbox"; systemctl is-active vboxdrv; VBoxManage --versionMokManager needs a keypress at the console, which our November lab could not send, so this output is from the October run of the same sequence on Fedora 45 with RPM Fusion’s 7.2.18 build. All three modules loaded and a test VM registered and deleted cleanly:
SecureBoot enabled
vboxnetadp 32768 0
vboxnetflt 49152 0
vboxdrv 774144 2 vboxnetadp,vboxnetflt
active
7.2.18_RPMFUSIONr175117Do not switch Secure Boot off to make the error go away. One enrollment covers every later akmod rebuild signed with this key. If a kernel module is not a hard requirement for you, KVM needs none of this: see the KVM and virt-manager guide. The VirtualBox install guide covers the vboxusers group and the Oracle Extension Pack, and the Vagrant with VirtualBox guide builds on this setup.
CUDA from the fedora44 repo
NVIDIA doesn’t use $releasever. Its repo file names the release outright, and there is still no fedora45 directory:
for r in fedora45 fedora44; do printf "%s %s\n" $r $(curl -s -o /dev/null -w "%{http_code}" https://developer.download.nvidia.com/compute/cuda/repos/$r/x86_64/repodata/repomd.xml); doneThe probe returned fedora45 404 and fedora44 200. The repo file hardcodes baseurl=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64, so it never asks for a 45 tree and never 404s, and on our upgraded box it kept loading through the whole 44 to 45 upgrade. The flip side is that nothing will move you to a fedora45 repo when NVIDIA publishes one; the undo table covers that. Add the fedora44 repo file:
sudo dnf config-manager addrepo --from-repofile=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64/cuda-fedora44.repoThat repo also carries NVIDIA’s own driver packages. If your GPU driver comes from RPM Fusion, which is the path we tested, hide them from this repo the way RPM Fusion’s CUDA howto does. The quotes keep your shell from expanding the globs:
sudo dnf config-manager setopt "cuda-fedora44-$(uname -m).exclude=nvidia-driver*,cuda-drivers*,nvidia-modprobe,nvidia-persistenced,nvidia-settings,nvidia-libXNVCtrl*,nvidia-xconfig,nvidia-open,nvidia-imex,nvidia-kmod-common,libnvidia-fbc,kmod-nvidia-*-dkms,nvidia-fs*,nvidia-gds*,xorg-x11-nvidia*"Before the exclude, a dnf repoquery on this repo listed nvidia-driver and nvidia-open 615.71.10 plus cuda-drivers 610.57.04. After it, the same query returned only the two cuda-nvcc toolkit packages we asked about.
Compiler support decides whether CUDA works here at all. Fedora 45 ships GCC 16, and nvcc refuses host compilers newer than it knows about. Install only the compiler, the runtime headers and the C++ front end:
sudo dnf -y install cuda-nvcc-13-4 cuda-cudart-devel-13-4 gcc-c++CUDA 13.4 accepts GCC 16, because its host_config.h only errors out on __GNUC__ > 16. Prove it with a minimal kernel. Open a file:
nano hello.cuPaste a kernel that does nothing and a host function that prints one line:
#include <cstdio>
__global__ void k(){}
int main(){k<<<1,1>>>(); printf("compiled\n");}Compile it with the default host compiler, no -allow-unsupported-compiler:
export PATH=/usr/local/cuda-13.4/bin:$PATH
nvcc hello.cu -o hello; echo nvcc_rc=$?; ls -l helloThe compiler exited cleanly and wrote the binary:
nvcc_rc=0
-rwxr-xr-x. 1 mercy mercy 1079568 Nov 3 12:57 helloThe probe, the filtered repo query, the GCC limit line and the compile, in one terminal:
Older toolkits in the same repo carry their own GCC limit, so check the __GNUC__ line in /usr/local/cuda-*/targets/x86_64-linux/include/crt/host_config.h before you pin a CUDA version below 13.4. Our lab VM has no GPU, so we did not install the driver packages from this repo and cannot vouch for them on Fedora 45. The CUDA toolkit on Fedora guide covers the full toolkit, and the RPM Fusion driver path in the Fedora NVIDIA guide is the one we trust on this release. Keep the exclude in place for that setup.
PGDG PostgreSQL without losing your server
The install command from the PostgreSQL project uses rpm -E %fedora, and the F-45 repo RPM still does not exist:
sudo dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/F-$(rpm -E %fedora)-x86_64/pgdg-fedora-repo-latest.noarch.rpmdnf stops at “Failed to download files” with a Librepo “Status code: 404” error for the F-45-x86_64 path. The F-44 repo RPM installs fine, because it only drops .repo files that use $releasever:
sudo dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/F-44-x86_64/pgdg-fedora-repo-latest.noarch.rpmProbe the four trees that matter before you choose a fix:
for p in 18/fedora/fedora-45-x86_64 common/fedora/fedora-45-x86_64 testing/18/fedora/fedora-45-x86_64 testing/common/fedora/fedora-45-x86_64; do printf "%s %s\n" $(curl -s -o /dev/null -w "%{http_code}" https://download.postgresql.org/pub/repos/yum/$p/repodata/repomd.xml) $p; doneThe stable trees are still missing and the testing trees are not:
404 18/fedora/fedora-45-x86_64
404 common/fedora/fedora-45-x86_64
200 testing/18/fedora/fedora-45-x86_64
200 testing/common/fedora/fedora-45-x86_64Pinning pgdg18 to the fedora-44 tree looks like it works at first, because the server and contrib packages resolve. Anything linked to Perl does not. Fedora 45 ships perl-libs 5.44.0, which provides libperl.so.5.44, and the Fedora 44 PGDG build of PL/Perl wants the older soname. We asked for that exact build with the pin applied on the command line:
sudo dnf install --assumeno --setopt=pgdg18.enabled=1 --setopt=pgdg18.baseurl=https://download.postgresql.org/pub/repos/yum/18/fedora/fedora-44-x86_64 --setopt=pgdg18-updates-testing.enabled=0 --setopt=skip_broken=0 --repo=pgdg18 --repo=fedora --repo=updates postgresql18-plperl-18.6-4PGDG.f44dnf cannot satisfy it (output trimmed to the problem lines):
Problem: conflicting requests
- nothing provides libperl.so.5.42()(64bit) needed by postgresql18-plperl-18.6-4PGDG.f44.x86_64 from pgdg18
- nothing provides perl(:MODULE_COMPAT_5.42.3) needed by postgresql18-plperl-18.6-4PGDG.f44.x86_64 from pgdg18It’s the same soname problem VirtualBox hit with libvpx, and with PGDG 18 already installed, a plain dnf install postgresql18-plperl on that pin is worse than an error. dnf skipped the broken Fedora 44 package and proposed Fedora’s own postgresql-plperl, replacing the PGDG server, client and contrib packages, which is the trap described below. Switch to the testing repos and turn the dead stable ones off, all in one override:
sudo dnf config-manager setopt pgdg-common-testing.enabled=1 pgdg18-updates-testing.enabled=1 pgdg-common.enabled=0 pgdg18.enabled=0 pgdg17.enabled=0 pgdg16.enabled=0 pgdg15.enabled=0 pgdg14.enabled=0Install the server and contrib modules, initialise the cluster, and start it:
sudo dnf -y install postgresql18-server postgresql18-contrib
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18List what landed:
rpm -qa "postgresql*" | sortEvery package is a PGDG build for Fedora 45 (the f45 tag):
postgresql18-18.6-4PGDG.f45.x86_64
postgresql18-contrib-18.6-4PGDG.f45.x86_64
postgresql18-libs-18.6-4PGDG.f45.x86_64
postgresql18-server-18.6-4PGDG.f45.x86_64A contrib extension proves the server and contrib builds match:
sudo -u postgres psql -c "CREATE EXTENSION pg_trgm;" -c "SELECT extname, extversion FROM pg_extension WHERE extname = 'pg_trgm';"The extension is created and reports its version:
CREATE EXTENSION
extname | extversion
---------+------------
pg_trgm | 1.6
(1 row)A matching pg_trgm version means the contrib modules came from the same PGDG testing build as the server, which is the state the next trap destroys.
The failure mode: dnf replaces the PGDG server with Fedora’s
Keep those testing repos enabled for as long as the server is installed. We switched them off for one command, with PGDG 18 running, and asked for one more extension package:
sudo dnf install --assumeno --setopt=pgdg18-updates-testing.enabled=0 --setopt=pgdg-common-testing.enabled=0 postgresql18-plpython3dnf found no PGDG build of it. The Fedora postgresql-plpython3 package provides that name, and Fedora’s postgresql-server both provides and obsoletes postgresql18-server. dnf took them:
Read the “replacing” lines. One -y would have swapped the PGDG 18.6 server, client and contrib packages for the Fedora 18.3 builds, and the damage is immediate. The PGDG server package has a %preun scriptlet (rpm -q --scripts postgresql18-server shows it) that runs systemctl disable and systemctl stop postgresql-18.service on removal, so your database goes down inside that same transaction. The Fedora server ships postgresql.service with PGDATA=/var/lib/pgsql/data, while your cluster lives in /var/lib/pgsql/18/data. Read the transaction summary on every PostgreSQL install. The PostgreSQL on Fedora guide covers the Fedora-packaged route if you would rather not depend on the PGDG testing tree.
With the testing repos enabled, a full sudo dnf upgrade --assumeno on the same box proposed no PostgreSQL change at all. The trap only opens when the PGDG repos that hold your installed builds go away. These are testing builds, with the same 18.6 version as PGDG’s stable Fedora 44 builds, but the PostgreSQL project has not promoted them yet. Put this on a dev box now and on production once the stable Fedora 45 tree exists.
RPM Fusion on Fedora 45: the development tree behind the metalink
RPM Fusion has no releases/45 tree yet, but nothing breaks, because its repo file reaches the packages through a metalink rather than a fixed path. If you skipped the VirtualBox section, install both release packages now (dnf reports the free one as already installed otherwise), then look at where the metalink points:
sudo dnf -y install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
dnf repo info rpmfusion-free 2>/dev/null | grep -E "Metalink|Base URL"The release package is rpmfusion-free-release-45-0.2, and the base URL the metalink hands out ends in development/45/Everything/x86_64/os/:
The URL still serves rpmfusion-*-release-45-0.2. Its free-fedora-45 metalink resolves fine, but the mirror it hands out serves the development/45 tree, because releases/45 still answers 404 on RPM Fusion’s own server. Which repos that package switches on matters just as much. On our box dnf repo list --all showed this state right after the install:
rpmfusion-freeandrpmfusion-nonfreeare enabled, and the free metalink resolves todevelopment/45.rpmfusion-free-updates-testingandrpmfusion-nonfree-updates-testingare enabled.rpmfusion-free-updatesandrpmfusion-nonfree-updatesare disabled.
The disabled pair looks like the thing to fix, so we counted what is in them before touching anything. This loop enables each stable updates repo for one query only:
for r in rpmfusion-free-updates rpmfusion-nonfree-updates; do printf "%-28s %s packages\n" $r $(dnf repoquery -q --disablerepo="*" --enablerepo=$r --qf "%{name}\n" 2>/dev/null | wc -l); doneBoth came back empty. A second query shows which repo answers for the packages people actually install from RPM Fusion, plus the release packages themselves:
dnf repoquery -q --qf "%{name} %{version}-%{release} %{repoid}\n" --latest-limit=1 ffmpeg mesa-va-drivers-freeworld akmod-nvidia rpmfusion-free-release rpmfusion-nonfree-release 2>/dev/nullOur run on the final Fedora 45, with both 45-0.2 release packages installed, returned zero packages for each -updates repo and these sources for the rest:
So the stable -updates repos are disabled and empty, and the packages are served from the base repos and -updates-testing: ffmpeg 9.0.2 came from rpmfusion-free-updates-testing, while the freeworld Mesa drivers and akmod-nvidia resolved from the base repos. Switching to the stable repos would gain you nothing but an empty repo, so leave the layout as the release package set it. The first upgrade after install offers a newer release package from the testing repo itself:
sudo dnf upgrade --refresh --assumenoOn our upgraded box that was the whole RPM Fusion transaction:
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 KiBInstalling 45-0.3 changed nothing about which repos are on. dnf repo list still showed rpmfusion-free-updates-testing and rpmfusion-nonfree-updates-testing enabled with both -updates repos off, and the only visible difference is that the 45-0.3 build installs its .repo files under /usr/share/dnf5/repos.d/. Look there if you go hunting for the file. The same behaviour shows up in our Fedora 45 post-install checklist. Don’t disable them by hand: VirtualBox above came from the development tree through exactly this setup. The release packages update through these same testing repos, so a regular sudo dnf upgrade picks up whatever repo layout RPM Fusion publishes next.
Undoing each workaround when the vendor catches up
Every fix above is temporary, and Docker shows the cleanup is real work. Leave a pin in place after the vendor ships Fedora 45 builds and you keep installing packages built for an older release. The signal to undo differs per vendor:
| Vendor | Undo when | Undo |
|---|---|---|
| Docker CE | Already true on 3 Nov 2026: dnf repoquery --repo=docker-ce-stable docker-buildx-plugin prints .fc45 builds | sudo rm /etc/yum.repos.d/docker-ce-f44-plugins.repo, then sudo dnf upgrade --refresh docker-buildx-plugin |
| HashiCorp | The probe loop from the diagnosis section returns 200 for 45 | sudo dnf config-manager unsetopt hashicorp.baseurl |
| PGDG | The probe returns 200 for both 18/fedora/fedora-45-x86_64 and common/fedora/fedora-45-x86_64 | sudo dnf config-manager setopt pgdg-common.enabled=1 pgdg18.enabled=1 pgdg-common-testing.enabled=0 pgdg18-updates-testing.enabled=0 |
| Oracle VirtualBox | Oracle publishes a 45 tree built against libvpx 1.17 | Remove the RPM Fusion VirtualBox and akmod-VirtualBox packages first, then sudo dnf config-manager unsetopt virtualbox.enabled |
| NVIDIA CUDA | A fedora45 repo appears | Remove cuda-fedora44.repo, run sudo dnf config-manager unsetopt cuda-fedora44-x86_64.exclude, then add the fedora45 repo file and set the same exclude on its repo ID (dnf repo list shows it) |
We ran the HashiCorp undo on the lab box. dnf repo info hashicorp went straight back to the $releasever URL, https://rpm.releases.hashicorp.com/fedora/45/x86_64/stable, which still 404s, so we put the pin back. Do not run the PGDG undo before PGDG publishes the stable 45 tree, or you’re back in the replacement trap above.
Upgrading from Fedora 44 rather than installing fresh? Check the 45 tree of each vendor with the probe loop before you start the Fedora 44 to 45 upgrade. Every repo that builds its URL from $releasever starts asking for the 45 directory as soon as the upgrade runs. Vendor .rpm files you download and install by hand are a separate problem from repo 404s, covered in the NOKEY fix.
Repo audit checklist for a Fedora 45 box
Run this list after any vendor repo change, and again after the next Fedora upgrade. Each line is a condition that should hold on a clean machine:
sudo dnf makecache --refreshprints no “Usable URL not found” line for any enabled repo./etc/yum.repos.d/holds nodocker-ce-f44-plugins.repo, andrpm -q docker-buildx-pluginprints an.fc45.x86_64build./etc/dnf/repos.override.d/99-config_manager.repolists only the pins you can name a reason for: HashiCorp to 44, the disabled Oracle repo, the CUDA exclude and the PGDG testing switch.- The Oracle
virtualboxrepo is disabled while VirtualBox comes from RPM Fusion. modinfo -F signer vboxdrvnames your akmods key, andmokutil --sb-statestill reports Secure Boot enabled.pgdg18-updates-testingandpgdg-common-testingstay enabled for as long as PGDG 18 is installed.- Fedora’s
docker-buildxandmoby-enginepackages are absent from any Docker CE host.
On our lab box, the final sudo dnf makecache --refresh after all of the fixes above counted zero “Usable URL not found” lines. That is the state to aim for, and the first item on this list is the one to re-run whenever a vendor changes its repos.
