Fedora 45 has several system-level changes that need testing on real hardware. The first test day up is GNOME 51, starting on 17 August, with more events planned for RPM 6.1, installation media and others. You can participate with a VM for most tests; some hardware-specific testing is more useful on a real machine.
Details are contained in this article.
Fedora 45 is bringing several changes that deserve testing beyond CI and automated test suites. Here are some of the bigger ones:
- RPM 6.1: update to 6.1, enforced signature checking, and DNF repo configs relocating to /usr.
- OpenSSL 4.0 — a major version bump that could affect anything doing TLS.
- Boot and live media are being rebuilt from scratch with image-builder. This changes how the images are produced, so we want to make sure they still boot and install correctly across a range of hardware and virtualization setups.
- kmscon replaces the kernel VT console (fbcon) as the default.
- Python 3.15, GRUB EFI for Confidential Computing, and more.
Why we need community testing
Automated tests catch regressions in known scenarios, but they won’t tell us if the new boot.iso works on your particular laptop, or if enforced RPM signature checking breaks a workflow nobody on the team thought of. We need people trying this on real machines and in real scenarios.
That’s what test days are for. A few days focused on a specific change, developers on Matrix to help debug, and anyone can show up and run through the test cases. You don’t need to be a Fedora QA expert. If you can install Fedora, reproduce a problem and report what happened, you can help.
What we’re planning for F45
At our July 20 Quality meeting (transcript), we went through the ChangeSet and picked out the changes that would benefit most from community testing. That turned into a planning ticket on Forge with individual tickets for each event.
GNOME 51 Desktop — August 17-21 is the first test day this cycle and it’s happening right now . Desktop, graphics, peripherals, core applications. If you’re reading this in time, jump in. (#GNOME_51_Desktop)
I18n test week —September 7-13 input methods, locales, keyboard layouts. . (#924)
RPM 6.1 — NSS support for user/group lookups is back, queries work again during transactions, new macro modifiers for packagers, and better rpmkeys verification output. Looks like a smooth update, but RPM touches everything — worth making sure nothing slipped through. (#917)
Installation media — boot.iso and live images, physical hardware, VMs. Try booting the new images on whatever hardware you have. Does the installer work? Does the live environment behave? (#918)
KDE — likely KDE 6.7. (#922)
Cockpit — it’s been years since the last Cockpit test day. (#920)
GRUB EFI / Confidential Computing — relevant mainly to specific hardware and VM environments. (#919)
The list isn’t final. We’re still looking at kmscon, OpenSSL 4.0, CoreOS, and Kernel 7.2. Keep an eye on testdays.fedoraproject.org for the current schedule.
What kind of testing helps most
Try upgrading your system to the latest packages. Boot the new boot.iso on physical hardware. Test suspend/resume, Wi-Fi, external displays, NVIDIA/AMD/Intel graphics, or whatever hardware you actually use. Each test day has a wiki page with specific test cases, but your own daily workflows are often where the interesting bugs hide.
You need a Fedora Account to report results. Pick a test day from the schedule, follow the wiki instructions, report through the test day app, and if you find something odd, come talk to us on Matrix in #test-day:fedoraproject.org.
The test day app itself is open source at quality/testdays-web on Forge. If something about it bugs you or you have an idea, file a ticket.
Propose a test day
This doesn’t all have to come from us. If you maintain a package with a big change in F45, or you see something in the ChangeSet that you think needs broader testing — propose a test day. Create a ticket at forge.fedoraproject.org/quality/tickets, tag it “test days”, and tell us what you’d like to test. You don’t need test cases or wiki pages ready. The QA team will help with that.
Testing beyond test days
Test days are focused events around specific changes, but testing Fedora is something you can do any day. fedora-easy-karma is a CLI tool that picks up testing updates already installed on your system and lets you submit karma to Bodhi right from your terminal. See the installation instructions to get started. Like the test day app, it’s an open source project hosted on Forge — feel free to report issues or suggest features.
Links
- Test day schedule and results
- Fedora 45 ChangeSet
- F45 test day planning ticket
- Test Days wiki
- Matrix: #test-day:fedoraproject.org
- Mailing list: test@lists.fedoraproject.org
Catch you in #test-day on Matrix.
Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own.
I’m the author of this article. If you know of an F45 change that should get a test day, let us know – open a ticket at Making sure you're not a bot! tickets and tag it “test days”. The QA team will help set it up. Don’t worry about creating too many tickets – we’re happy to see them.
It would be great if the project would make Silverblue/Kinolite a primary testing target!
The immutable nature makes testing these new versions on real hardware outside a VM far safer for the tester as they can pin/unpin working releases and switch back and forth with just a reboot.
I missed the f44 testing as I couldn’t rebase due to fedora-cisco-openh264 not being built yet. I look forward to f45!
Hey there. I have never been through a test day before. Is there some primer on how this is meant to work? Particularly looking forward to the boot/live media testing, kernel, and stuff to do with the KDE Plasma desktop environment.
Does the scheduling mean there is one day to do both the testing and reporting issues and there is a close date for issues?
A few other questions:
Another thing worth noting, by the time Fedora 45 is due for release, Plasma 6.8 would have been released.
@ngompa can probably answer this.
I’ve got F45 Workstation loaded up on one of my laptops this morning to play around with thugs this week.
No. It never got submitted because the groundwork is not in place.
Hello Bob,
Test days usually run for several days, not just one.
You can test and report results anytime during that window or later after test days is also fine. The ones with confirmed dates are listed at testdays.fedoraproject.org.
Many of the others are still being planned and only exist as Forge tickets for now and dates will be set later. There’s no hard deadline for reporting, any bugs you find go to Bugzilla as usual.
added comment about plasma 6.8 during f45: Making sure you're not a bot!
The systemd-boot vs GRUB question is an upstream/Fedora engineering topic.
systemd-boot is NOT the default and not officially supported as a bootloader in Fedora. If you want to raise it, fedora-devel mailing list (devel@lists.fedoraproject.org) or Fedora Discussion (discussion.fedoraproject.org) would be the right place.
That’s a good point about Silverblue/Kinoite - the rebase workflow does make it safer for testing on real hardware. Some of us on the QA team already use it, also for testing.
If you know people who want to help test but don’t want to risk breaking their setup, Fedora Atomic Desktops could be the answer. its worth putting together a guide on how to use it for test day participation.
If you want to take this further, open a ticket at Making sure you're not a bot! and tag it “test days”.
We can discuss using Atomic Desktops for test days there, or bring it up at our Monday QA meeting at Matrix.
Once Fedora 45 is officially released, will I be able to switch to it directly without having to reinstall?
Yes, there are methods for upgrading Fedora Linux from one release to another without having to reinstall: