Fedora 45 breaks more shell habits than desktop ones. A plain rpm -i on a package whose key is not imported now fails instead of warning, /etc/yum.repos.d/ ships empty, the virtual consoles run kmscon instead of the kernel framebuffer console, and unprivileged ptrace is off until a debugger is installed. GNOME 51 and Podman 6 are the headline features, but the admin-facing changes are the ones that will trip scripts and old tutorials.
This rundown of what is new in Fedora 45 comes from the lab rather than the press release. Every change that can be exercised on a VM was checked on fresh Server and Workstation installs, on a Fedora 44 VM upgraded in place with dnf system-upgrade, and on two identical cloud VMs (one Fedora 44, one Fedora 45) measured side by side for boot time and memory. The rest (installer options, network and provisioning changes, upstream desktop features) is taken from the change pages and upstream release notes, and says so. Where the shipped behaviour differs from the change proposal, the measured behaviour wins and the difference is called out. The official list lives on the Fedora 45 ChangeSet. I went back over the versions, dates and headline changes in November 2026 on a Fedora 45 VM synced to the stable repos, and the findings below still hold.
What is new in Fedora 45: component versions against Fedora 44
The version table below was pulled with dnf repoquery against the stable repos of both releases on the same day in November 2026, from a fully updated Fedora 45 VM. Fedora 44 keeps receiving rebases, so several “new” components are already on a patched Fedora 44 box. Kernel 7.2.15 and Plasma 6.8.2 both landed on Fedora 44 through updates, which means neither is a reason to upgrade on its own.
| Component | Fedora 44 (current updates) | Fedora 45 |
|---|---|---|
| Linux kernel | 7.2.15 | 7.2.15 |
| GNOME Shell | 50.6 | 51.1 |
| KDE Plasma | 6.8.2 | 6.8.2 |
| systemd | 259.10 | 262.1 |
| RPM | 6.0.2 | 6.1.0 |
| glibc / GCC | 2.43 / 16.2.1 | 2.44 / 16.2.1 |
| LLVM | 22.1.8 | 23.1.4 |
| Python | 3.14.8 | 3.15.0 |
| Go / Perl / Ruby | 1.26.10 / 5.42.3 / 4.0.9 | 1.27.3 / 5.44.0 / 4.0.9 |
| OpenSSL | 3.5.9 | 4.0.3 |
| OpenSSH | 10.2p1 | 10.5p1 |
| Podman | 5.8.9 | 6.1.3 |
| MySQL (mysql-server) | 8.4.10 | 9.7.2 |
| MariaDB (mariadb-server) | 11.8.8 | 12.3.2 |
| LibreOffice | 26.2.6 | 26.8.2 |
| NetworkManager / firewalld | 1.56.1 / 2.4.4 | 1.58.1 / 2.5.2 |
The real delta is the toolchain and runtime layer (glibc 2.44, LLVM 23, Python 3.15, Go 1.27, OpenSSL 4.0), the database defaults, systemd 262 and RPM 6.1. Ruby is the one runtime where both releases now ship the same upstream version. You can check the headline versions on your own machine in a few seconds with these four commands:
grep -E '^(PRETTY_NAME|SUPPORT_END)=' /etc/os-release
uname -r
dnf -q repoquery --latest-limit 1 --qf '%{name} %{evr}\n' gnome-shell plasma-workspace systemd podman python3
dnf repo list --all | grep -w updates-testingHere’s what they printed on our updated VM. The last command also shows that a system on the current fedora-repos package has updates-testing switched off:
If /etc/os-release on your box still says Prerelease or shows an earlier SUPPORT_END, the fedora-release packages haven’t been updated yet. A plain sudo dnf upgrade --refresh brings them in line, which is exactly what happened on the VM above.
Fedora 45 release date and support window
The Fedora 45 schedule lists November 3, 2026 as the current final target date. The release missed its October 20 and October 27 targets, and the final 45-1.4 images are already on the Fedora mirrors. Support runs to December 8, 2027: that’s the end-of-life date on the schedule, and it’s the SUPPORT_END value in /etc/os-release once the final fedora-release packages are installed.
| Milestone | Date |
|---|---|
| Branched from Rawhide | 2026-08-11 |
| Final freeze | 2026-10-20 to 2026-11-03 |
| Final target date | 2026-11-03 (next fallback 2026-11-10) |
| Fedora 43 end of life | 2026-12-16 |
| Fedora 45 end of life | 2027-12-08 |
Fedora 43 reaches end of life on December 16, about six weeks after the Fedora 45 target date, so anything still on 43 has a short window. You can go straight from 43 to 45, because dnf system-upgrade supports skipping one release; just run sudo remove-retired-packages 43 afterwards, as Fedora’s upgrade docs ask. The Fedora 44 to 45 upgrade guide covers the GUI route, the CLI route and rollback. If you installed Fedora 45 early, run a normal update: the early fedora-release packages carried an earlier SUPPORT_END of 2027-11-24, and the final ones moved it to December 8. The Fedora 45 Server and Workstation install guide has download commands that find the right mirror tree on their own, plus the signature check for both editions.
1. rpm refuses packages it cannot verify
This is the change most likely to break an existing script. RPM’s %_pkgverify_level moved from digest to all, so rpm -i now requires a valid signature from an imported key. On Fedora 44 the same command printed a NOKEY warning and installed anyway. On Fedora 45 it stops. The ways around it that keep signature checking on are in how to fix the NOKEY signature error on Fedora.
The test case was the RPM Fusion release package, which is signed with a key that a fresh system has not imported yet. The first line confirms the new default:
rpm --eval %_pkgverify_levelFedora 45 prints all (Fedora 44 prints digest). Installing the package with rpm directly:
sudo rpm -ivh rpmfusion-free-release-45.noarch.rpmThe transaction is rejected at the verify stage and rpm exits 1:
warning: rpmfusion-free-release-45.noarch.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY
Verifying... ########################################
Preparing... ########################################
package rpmfusion-free-release-45-0.2.noarch does not verify: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEYThe same run in the terminal, next to the new default:
Installing the same local file with dnf worked without a prompt or an error on the same box. That is convenient, but it also means dnf did not check the signature of the local file: dnf enforces signatures for repositories, not for a file path you hand it. Use this route only for a source you already trust, such as a vendor’s release RPM that installs its repo and key; from then on, packages from that repo are verified normally:
sudo dnf install ./rpmfusion-free-release-45.noarch.rpmFor a single unsigned package that must go in through rpm, --nosignature skips the check (tested, it installs). To put the whole host back on the old behaviour, the change proposal documents a macro override. On the test box it flipped the level back to digest and the same rpm install went through. It weakens every rpm transaction on the host, so reserve it for build machines:
echo '%_pkgverify_level digest' | sudo tee /etc/rpm/macros.verifyA related packaging change, %openpgpverify, moves source-tarball signature checks in spec files from GnuPG to Sequoia. It only affects packagers.
2. Repository files moved from /etc to /usr
Fedora’s own .repo files now live in /usr/share/dnf5/repos.d/ and the signing keys in /usr/share/pki/rpm-gpg/. /etc/yum.repos.d/ and /etc/pki/rpm-gpg/ still exist, but ship empty. The relocation change keeps /etc for administrator overrides and third-party repos, which is exactly how it behaved in testing: installing RPM Fusion dropped its three files into /etc/yum.repos.d/ as before.
ls /etc/yum.repos.d/ /usr/share/dnf5/repos.d/The /etc directory is empty; the four Fedora repo files sit under /usr:
/etc/yum.repos.d/:
/usr/share/dnf5/repos.d/:
fedora-cisco-openh264.repo
fedora.repo
fedora-updates.repo
fedora-updates-testing.repoDo not edit the files under /usr; package updates overwrite them. Toggle repos with dnf config-manager, which writes a drop-in to /etc/dnf/repos.override.d/. Our VM, installed from an early image with updates-testing on, came up with it off once the current fedora-repos package arrived: that package ships updates-testing disabled, and with nothing under /etc overriding it, the change took effect. If dnf repo list still shows updates-testing enabled on your machine, this is the command to switch it off:
sudo dnf config-manager setopt updates-testing.enabled=0
cat /etc/dnf/repos.override.d/99-config_manager.repoThe override file dnf5 generated:
# Generated by libdnf5.
# Do not modify this file manually, use dnf5 config-manager instead.
[updates-testing]
enabled=0Taken together on a fresh Server install:
The move also changed where repo signing keys live, which breaks one old habit:
Error: “import read failed(2)” on rpm –import
Older tutorials import the Fedora key from /etc/pki/rpm-gpg/. On Fedora 45 that file does not exist and rpm prints:
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-45-x86_64: import read failed(2).Point the command at the new location instead. It exits 0:
sudo rpm --import /usr/share/pki/rpm-gpg/RPM-GPG-KEY-fedora-45-x86_64The same applies to any script that greps or seds /etc/yum.repos.d/fedora.repo. The change page also states that DNF 4 and yum no longer work as the system package manager, so dnf5 is the only supported front end. The dnf5 cheat sheet covers the command changes.
3. kmscon replaces the framebuffer console
The text consoles on tty1 to tty6 are now served by kmscon, a userspace terminal on top of KMS, through [email protected]. [email protected] is an alias for it. It is in the @core group, so Server, Cloud and minimal installs get it as well as the desktops. On a fresh Server install the unit is enabled by preset and uses under 18 MiB:
systemctl status kmsconvt@tty1 --no-pager -n0A login on tty1 now reports /dev/pts/0 from tty, because kmscon is a terminal emulator rather than a kernel VT:
That has practical consequences, all listed on the kmscon change page. setfont and loadkeys no longer change the console, gpm does not work, and startx from a console needs kmscon-launch-gui startx. kmscon takes its keyboard layout from localectl by default, so sudo localectl set-x11-keymap de remains the normal way to change it. Fonts, and any layout override, go in /etc/kmscon/kmscon.conf. Only an example file ships:
sudo cp /etc/kmscon/kmscon.conf.example /etc/kmscon/kmscon.conf
sudo vim /etc/kmscon/kmscon.confThe keys that matter are commented out in the example. Uncomment and set them, for example:
font-name=Hack Nerd Font
font-size=18
xkb-layout=deAccording to the change owners, installation, boot and the LUKS passphrase prompt are unaffected because fbcon stays compiled into the kernel. If kmscon fails to start, the unit falls back to a plain getty. Two console bugs were reported against the Fedora 45 desktops during testing. reboot and poweroff on a desktop install asked regular users for authentication because SELinux treated the kmscon session as non-local; systemctl reboot worked around it, and the fix is already in updates. Switched keyboard layouts were also not applied on the Workstation console in our install.
4. ptrace is restricted until you install a debugger
Fedora 45 turns on the kernel’s Yama restriction (kernel.yama.ptrace_scope = 1), so an unprivileged process can only trace its own children. Fedora 44 and older shipped elfutils-default-yama-scope on every system, which set the scope to 0. That package is now yama-ptrace-enable, and nothing installs it by default. strace pulls it in as a weak dependency; gdb does not, because it still recommends the old default-yama-scope name that no package provides any more. Root is not affected.
On a fresh Server install, attaching to one of your own processes with PTRACE_ATTACH fails with Operation not permitted. Installing strace flips the scope immediately, with no reboot:
sudo dnf install strace
sysctl kernel.yama.ptrace_scopednf pulls in yama-ptrace-enable as a weak dependency, and the sysctl now reads 0, so strace -p attaches:
Upgraded systems follow the same rule. The Fedora 44 VM that was upgraded had no debugger installed, so the upgrade replaced elfutils-default-yama-scope and the scope came up as 1 after the reboot. Profilers and tools built from source that attach to running PIDs will hit EPERM until something installs yama-ptrace-enable. Installing that one package is the clean fix. gdb users need it explicitly (sudo dnf install yama-ptrace-enable), and because it is only a weak dependency of strace, hosts with install_weak_deps=False, common on minimal and container-build images, stay at scope 1 even after installing strace. Background is on the ptrace change page.
5. Podman 6 drops slirp4netns, cgroups v1 and BoltDB
Podman 6 is a major release with CLI and API breaks. Its defaults on a fresh Fedora 45 install are SQLite for the database, netavark for networking, cgroups v2 and pasta for rootless networking. Asking for the removed network backend fails outright:
podman run --rm --network slirp4netns docker.io/library/alpine trueThe error names the replacement, and Podman 6.1.3 from the current stable repos prints exactly the same line:
Error: slirp4netns support has been removed, use --network=pasta instead; for existing containers, run `podman system migrate`Version, backends and the rejected flag on the test box:
For upgrades, the database backend is the one to check first. Podman 6 can no longer read BoltDB, and the Podman 6 change page says to migrate to SQLite before upgrading. Hosts that have run containers since before SQLite became the default are the ones at risk. Check on Fedora 44 while it is still running Podman 5:
podman info --format '{{.Host.DatabaseBackend}}'The test VM reported sqlite, and its rootless nginx container (started under Podman 5.8.7 on Fedora 44) came back under Podman 6.1.1 with podman start web and served HTTP 200. The iptables backend in netavark and cgroups v1 support are gone too, so hosts that still pin either need changes before the upgrade. For containers run as systemd services, the Podman Quadlet guide covers the unit setup, and fixing Podman after a Fedora upgrade covers the errors that do show up.
6. GNOME 51 on Workstation, and oo7 takes over secrets
GNOME 51 went final upstream on September 16, and Fedora 45 Workstation ships it. The Fedora 45 stable repos already carry GNOME 51.1. On our Workstation VM, running GNOME 51.0, the Settings About page reads “GNOME Shell Version” and no longer has a Windowing System row, since GNOME has been Wayland-only since GNOME 50:
Upstream highlights from the GNOME 51 release notes:
- Reworked frame scheduling in Mutter and fewer buffer copies during screencasts.
- Monitor brightness is saved across reboots, and the Mutter changelog adds Night Light on hardware without gamma LUTs.
- The login screen can choose between authentication methods, including web login.
- Settings adds auto-rotate, an option to disable the touchpad while a mouse is connected, and a new fingerprint enrollment screen. WEP Wi-Fi support is gone.
- Remote Login supports socket-activated SSH, and Remote Desktop gains smartcard redirection and Kerberos login.
- Maps downloads offline areas and shows live transit departures; Papers adds drawn signatures.
- Mutter dropped the legacy NVIDIA driver interfaces and now uses only the standard graphics interfaces.
To see which GNOME build you’re on, run gnome-shell --version. A fully updated Fedora 45 desktop should report 51.1 or later.
The secrets change needs a precise description, because the press coverage oversimplifies it. The oo7 change replaces GNOME Keyring as the Secret Service provider and migrates existing keyrings automatically. The part that trips people up is that both daemons stay installed. On our Workstation VM, gnome-keyring-daemon owned org.freedesktop.secrets until the GNOME 51.0 update pulled in oo7-daemon and pam_oo7. Both packages are now in the Fedora 45 stable repos, as a snapshot taken after the 0.7.0 beta, next to gnome-keyring 51.1. After a fresh login, busctl showed oo7 owning the bus name:
gnome-keyring-daemon --login still starts from PAM alongside it. In the package groups, pam_oo7 is part of the Xfce, LXDE, COSMIC, Budgie, Sway and MiracleWM desktops. The KDE edition is not in that list, and the final repos return the same six groups. The upstream GNOME 51.0 session notes include a fix for “oo7-daemon.service never starts by default”, so a machine still on a GNOME build older than 51.0 may show mixed results. Run busctl --user status org.freedesktop.secrets after logging in to see which daemon you actually have.
7. KDE Plasma 6.8 and the other desktops
The KDE edition ships Plasma 6.8, and the stable repos carry 6.8.2. The Plasma 6.8.0 release landed on October 14 with a few changes you’ll notice straight away:
- A built-in dwell clicker sends a click when the pointer stops moving, so you don’t need an extra app for it.
- The remote desktop server adapts to slow networks and adds an exclusive mode plus two-way clipboard sync.
- Spectacle can record system audio and your microphone together in one screen recording.
- System Monitor lets you pin a process to chosen CPUs, and it shows VRAM load as a percentage.
- NVIDIA GPUs get triple buffering by default in KWin, and a new
kscreenctltool manages displays from the command line.
Fedora 44 received the same Plasma 6.8.2 through its updates, so a Plasma user on a patched 44 box already has all of this. The bigger story is X11: Plasma 6.8 retires X11 sessions upstream, with X11-only apps left to XWayland. Fedora 45 still lists plasma-workspace-x11 and kwin-x11, but they’re the old 6.7.5 builds that never moved to 6.8. They only require plasma-workspace >= 6.7.5, so dnf will happily resolve them against Plasma 6.8.2, yet upstream no longer supports that mix and we didn’t test whether the session starts. If you still depend on X11, the KDE Plasma X11 to Wayland guide walks through the switch.
The other desktops are all on the final mirror. MiracleWM ships as a live spin, and the mirror finally uses the Atomic brand names for its directories and ISOs: the Fedora 44 Onyx/ and Sericea/ trees are now Budgie-Atomic/ and Sway-Atomic/, next to Silverblue, Kinoite and COSMIC Atomic. An earlier COSMIC spin build we tried booted to a text console because kmscon and cosmic-greeter competed for the DRM device. If the final image does the same on your hardware, the workaround is on Fedora’s Common Issues board.
8. Installer changes: Stratis, Atomic desktops and remote install
Server and Everything still use the GTK Anaconda. Workstation and KDE keep the Anaconda Web UI, and the Atomic desktop ISOs (Silverblue, Kinoite and the rest) now use it too. The Atomic ISOs also gain remote installation: boot with inst.webui.remote and finish the install from a browser on another machine, authenticated with a PIN. They are now built with image-builder rather than lorax.
Stratis storage is now an Anaconda target, with new kickstart commands and a Stratis autopart type. In the Web UI it is only reachable through the Cockpit storage editor, not guided partitioning. Storage defaults are unchanged, confirmed from the installer profiles and on the lab installs: Btrfs with zstd:1 compression on Workstation, XFS on LVM with a 15 GiB root cap on Server, and no encryption by default. BIOS boot is still supported, and i686 multilib packages are still shipped.
9. Security, auth and kernel housekeeping
authselect dropped the nis profile. Fedora 44 lists local, nis, sssd and winbind. On Fedora 45 the list stops at three, and selecting NIS fails:
sudo authselect select nisauthselect cannot find the profile:
[error] Unable to get profile information [2]: No such file or directoryA few other changes show up in admin work:
- chpasswd and newusers use PAM, so bulk password changes now go through the system PAM stack and its password-quality and history modules. Because chpasswd runs as root, whether a weak password is rejected or only warned about depends on
enforce_for_rootin the PAM policy; the change page warns that scripts may fail. - The kernel crypto userspace API (AF_ALG) is deprecated. Upstream 7.2 removed AIO and old-style driver support and dropped zero-copy for skcipher and aead. The Fedora 45 kernel still builds
CONFIG_CRYPTO_USER_API, but phase 1 restricts the API to known applications: iwd, cryptsetup’s TrueCrypt/VeraCrypt mode and libkcapi keep working, while unknown third-party users are the ones that may break. - NetworkManager enables IPv6-mostly support by default, so it acts on the DHCPv4 “IPv6-only preferred” option (RFC 8925) when a network offers it.
- Ignition accepts Butane YAML directly at first boot, with no separate transpile step.
- Setuptools 83 no longer ships
pkg_resources. Withpython3-setuptoolsinstalled,import pkg_resourcesstill raisesModuleNotFoundError. Code that still needs it can use the deprecatedpython3-setuptools80compat package the change provides.
The kernel itself is 7.2 on both releases, so the 7.2 changes apply to an updated Fedora 44 too. The ones admins will notice are cache-aware scheduling, the fairer DRM GPU scheduler, MGLRU reclaim fixes, near-zero swap metadata overhead, Btrfs large folios by default and XFS zoned-device support leaving experimental. The Fedora hardening guide and the SELinux survival notes still apply as written.
10. Databases and language runtimes
The unversioned mysql-server package now installs MySQL 9.7 (Fedora 44: 8.4 LTS), and mariadb-server installs MariaDB 12.3 (Fedora 44: 11.8). Both are major jumps. Dump and restore, or run the upgrade tooling, before letting a system upgrade replace a production database. PostgreSQL stays on 18 as the default. The postgresql16, postgresql17 and postgresql19 (beta) packages are available side by side.
Node.js no longer has an officially preferred stream. The unversioned nodejs package is now a metapackage that depends on nodejs22. nodejs24 and nodejs26 install side by side, so pin the versioned name in automation. Python 3.15, Go 1.27, Perl 5.44, Lua 5.5, Pandas 3, Rails 8.1 and the GCC 16.2 / glibc 2.44 / binutils 2.47 toolchain round out the developer stack. python-dateutil is deprecated. The language runtimes guide covers the per-language setup.
11. Upgrading from Fedora 44 to 45
The upgrade test ran on a Fedora 44 cloud VM (2 vCPU, 4 GiB RAM) with rootless Podman, a running nginx container and RPM Fusion enabled. Fully update Fedora 44 first, then download the new release:
sudo dnf upgrade --refresh
sudo dnf system-upgrade download --releasever=45The transaction was 12 installs, 525 upgrades, 2 removals (an old 6.19 kernel) and 1 downgrade (libsecret), with 354 MiB to download. It finished in 114 seconds and imported the RPM Fusion 45 key on the way. Apply it with an offline reboot:
sudo dnf offline rebootThe offline transaction plus reboot took 109 seconds until SSH answered on Fedora 45. The upgrade pulled in kmscon as a new @core member and replaced fedora-repos. The unmodified Fedora repo files disappeared from /etc/yum.repos.d/, and only RPM Fusion’s three files were left there. The change page is explicit that edited fedora*.repo files stay in /etc and override the /usr copies entirely, so check that directory after upgrading any host where someone changed a mirror or a priority:
The step-by-step Fedora 45 upgrade guide has the full pre-flight checklist and a rollback path. Once you’re on 45, the Fedora 45 post-install checklist picks up from there.
Error: “can’t create keyring lock on /usr/lib/sysimage/rpm/.keyring.lock”
On the upgraded VM, every rpm query run as a regular user printed this line first, although the query itself still succeeded:
error: can't create keyring lock on /usr/lib/sysimage/rpm/.keyring.lock (No such file or directory)Fresh Fedora 45 installs ship an empty .keyring.lock in /usr/lib/sysimage/rpm/. Upgraded systems lack it, and a normal user cannot create it. Any rpm command run once as root creates the file, and the message is gone from then on:
sudo rpmkeys --listOne more upgrade note: on our machines RPM Fusion’s Fedora 45 release package enabled its updates-testing repos too, the same way Fedora’s own repos were set up, so check dnf repo list after the upgrade.
Fedora 44 vs Fedora 45 on identical VMs
Two clones with the same shape (q35, OVMF, 2 vCPU, 4 GiB, 20 GiB Btrfs on ZFS-backed storage) were built from the official Fedora 44 and Fedora 45 Cloud Base images, fully updated, and cold-booted three times each. These numbers come from the September lab round and weren’t re-measured for this update. Memory was read 150 seconds after boot with nobody logged in on the console.
| Metric (median of 3 boots) | Fedora 44 | Fedora 45 | Delta |
|---|---|---|---|
systemd-analyze total | 6.48 s | 7.02 s | +0.53 s |
Memory used (free -m) | 405 MiB | 497 MiB | +92 MiB |
| AnonPages (process memory) | 42 MiB | 42 MiB | flat |
| Unevictable | 0 MiB | 95 MiB | +95 MiB |
| Installed RPMs | 539 | 541 | +2 |
| Upgraded 44 to 45 VM, boot total (single boot) | n/a | 6.98 s | n/a |
Boot time moved by about half a second, spread across initrd and userspace. The top of systemd-analyze blame is device units on both releases, each roughly 0.3 s slower on Fedora 45, and no service stands out. The memory increase is not in any service: anonymous memory is identical, the largest processes are within a few MiB of each other (systemd-resolved is actually 4 MiB smaller on 45), and stopping kmscon moved the figure by only 4 MiB. The whole difference is 95 MiB of unevictable pages charged to the root cgroup, which appeared on the fresh Fedora 45 image and on the upgraded VM alike. On a 4 GiB VM that is about 2.3 percent of RAM. It matters on 1 GiB cloud instances and not on a desktop, but it is the number to watch in /proc/meminfo after kernel updates.
