Fedora 45 has shipped its third and final release candidate, RC-1.3, as the last media the Quality team needs to clear before Thursday's Go/No-Go vote. The release has already slipped twice, moving from an October 20 target to a current goal of November 3, 2026. Two accepted blockers tied to headline features, an oo7 account-migration failure and a Stratis encrypted-pool boot problem, are the main remaining hurdle, though most testing has come back green. If RC-1.3 passes cleanly on October 29, the stable Fedora 45 ships on schedule; if not, the deadline slips again.
Fedora 45 ships its final release candidate ahead of a Thursday go/no-go vote
Fedora 45 now has one clean shot at clearing the release bar. Release Candidate 1.3 shipped today (compose Fedora-45-20261028.0, version 45-1.3), and it's the exact media the Quality team needs to pass Thursday's Final Go/No-Go meeting. Pass cleanly, and the stable build ships November 3. Don't, and the clock keeps running.
This is the third time the date has moved. Fedora 45 was originally slated for October 20. Then it slipped to October 27. Now it's pointed at November 3, 2026.
The QA notice is terse, which is standard for this phase. "According to the schedule, Fedora 45 Candidate RC-1.3 is now available for testing. Please help us complete all the validation testing," reads the official posting. Simple enough. The real work happens on the test-result pages, where every RC-priority case must pass before the build gets certified.
A release three slips behind schedule
Fedora 45's road to stability has been rougher than recent cycles. The beta dropped September 15, and since then the team has hit two NO-GOs. At the first one, there was no suitable RC media yet, so the October 20 date died and a fresh target of October 27 was set. A week later, open blocker bugs blocked a clean vote, pushing the target to November 3.
Two bugs are accepted right now, and both hit headline features. That's precisely the kind of thing you don't want heading into a release vote.
The first is in oo7 (bug 2560819): after upgrading from Fedora 44 to 45, CreateItem(replace=true) fails to replace Online Accounts migrated from gnome-keyring. The second is in stratisd (bug 2543511), where an encrypted Stratis pool won't boot because /dev/stratis/fedorapool/root doesn't exist.
Those aren't random failures. oo7 is now Fedora 45's default desktop secret service, and Stratis storage is a brand-new Anaconda option. Both bugs live in upgrade-path territory or encrypted-storage boot scenarios, the classic spot release validation is supposed to catch.
Two more bugs sit in the proposed bucket. There's an SSH passphrase unlock problem after upgrade, plus an openssh proposal about a selinux-policy update breaking port forwarding. That openssh pull took home three negative votes and hasn't been accepted, so it's not a hard blocker yet. Keep in mind that the situation shifts by the minute, so head here to watch the live tracker before the vote.
It's worth remembering that the previous Go/No-Go had a very different blocker list, an eMudhra mitigation gap, an oversized Server AArch64 image, LVM auto-activation failing after a LUKS upgrade, KDE Discover pulling outdated RPMs from the F44 repo. The team has made clear headway on several of those since.
Mostly green, with one size-threshold annoyance
Testing has been largely green so far. Installation, image sanity, PXE boot, storage devices, and virtualization all pass. Even Fedora Media Writer holds up across Fedora 43 through 45, Windows, and macOS.
One red flag shows up, though it's more of a nuisance than a showstopper. The Mediakit ISO size sanity test flags several images for exceeding their configured caps. The Everything boot aarch64 image sits at about 1.43 GB against a 1.3 GB ceiling, and a batch of Spins and Labs images get flagged too. It's a size-threshold problem, not a functional failure, the actual installation tests for those images passed fine, and QA typically reconciles these by hand rather than treating them as hard blockers.
Security Lab results are still pending, which is normal this early in the cycle.
A big feature set carrying into the finish line
Fedora 45 is carrying a substantial change set into this final stretch, and a chunk of it is the reason for the headaches.
Security is the loudest theme. RPM signature verification is now required by default, so unsigned packages get blocked straight out of the box. That's a win for supply-chain trust, but it also means custom third-party repos need proper signing before they install. DNF5's vendor-change behavior is locked down by default, and ptrace access gets restricted system-wide, with automatic relaxation when dev or debugging toolchains are present to keep Fedora usable for the crowd that actually needs those privileges.
The desktop gains a new secret service, oo7, replacing GNOME Keyring and KWallet for that role. Atomic desktops like Silverblue and Kinoite get a modernized installer with web-based remote flows and image-builder disk images.
Server and installer changes bring Stratis into Anaconda, so you can install directly onto Stratis-managed storage. Fedora CoreOS gets systemd-oomd and zram swap by default. Then there's the usual version soup: GNOME 51 "A Coruña" on Workstation, KDE Plasma 6.7 on the KDE edition, and the Linux kernel at 7.2. The toollist runs long and includes GCC 16.2, glibc 2.44, Python 3.15, OpenSSL 4.0, MariaDB 12.3, MySQL 9.7.
Two smaller moves are worth a look. kmscon becomes the default virtual console, retiring the legacy in-kernel VT. And Fedora 45 formally targets 99% package build reproducibility.
A fair trade-off, mostly
It's a lot of change for something that is essentially a release candidate. RC iterations are supposed to stabilize, not introduce features, and several of these, the RPM signature enforcement, the stateless /usr layout, the ptrace restriction, are exactly the kind of thing that bites users who lean on custom setups. The oo7 and Stratis bugs both prove it: the new features work fine until an upgrade path trips them.
Fedora's role as the bleeding-edge testbed is the whole reason any of this matters, though. Those stricter signature checks, DNF5 defaults, userspace consoles, and reproducible-build targets act as early signals for where RHEL and the rest of Linux eventually land. The aggressive toolchain refresh gives developers newer compilers and libraries months before more conservative distros catch up. It's a reasonable trade-off, most of the time. Pushing cutting-edge software fast is rewarding, but it's also what makes fixed deadlines so much harder to hold.
If you want to help move things along
The path is straightforward. Download an ISO, disk image, cloud image, or container from the official pages or the Koji compose. Existing Fedora 44 users can skip a clean install and go straight through the DNF system-upgrade path. Then run the RC test cases from the individual result pages and post results on the summary page.
You can also lean on the relval tool if you'd rather automate.
dnf install relval relval report-results
File bugs in Bugzilla for anything that breaks, and jump into the #quality Matrix channel or the test@ mailing list to talk it through. Every RC-priority case has to pass, so a single well-documented failure can actually decide the vote.
The Go/No-Go is Thursday, October 29 at 17:00 UTC in the #fedora-meeting Matrix room. A virtual Release Party is planned for October 30 if the date holds. Keep an eye on the blocker tracker and the OpenQA stats if you want to watch the numbers roll in as the meeting approaches.
Head here to download the release.
