Fedora 44 Candidate RC-1.2 Available Now!

Project Discussion
, , , , , ,
1

THIS IS A RELEASE CANDIDATE ANNOUNCEMENT, not a release announcement. Please read on if you wish to help test Fedora 44 ahead of release.

According to the schedule, Fedora 44 Candidate RC-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see the release validation test plan.

Test coverage information for the current release can be seen here.

You can see all results, find testing instructions and image download locations, and enter results on the Summary page.

The individual test result pages are:

All Beta and Final priority test cases for each of these test pages must pass in order to meet the Final Release Criteria.

Help is available on the Fedora Quality chat channel, the Fedora Quality tag on Discourse, or on the test list.

See also Current Blocker and Freeze Exception bugs.

2 Likes
2

A specific call for testing, here: it’d be great if folks with hardware they can do test installs on could do an encrypted install and check whether graphics work at passphrase entry. We have a couple of proposed blocker bugs reporting problems at this stage, one on a Dell XPS 13 Plus where “the LUKS passphrase screen looks OK until I start typing the password, then the Plymouth screen disappears and the screen start flickering with a sort of blank screen”, one on Thinkpad X1 Carbon Gen 13 where the display is just blank. It’d be good to get a sense of whether other folks are seeing similar issues. It’d also be useful to know if the same problem happens on F42 / F43, if you do have an issue.

3

I tested on a F43 (older hardware) with fastboot. This gave me the black screen with non blinking cursor on top left corner. I’m also not using encryption of disks. It’s an existing setup. While I use a external installation (USB3 SSD WD-GREEN) F44 it works with fastboot. This information might help to isolate the issue. I would say this users should test without fastboot and versifier if they can install newer firmware for the disks they use, to reuse fast-boot.

My findings are based on that post!

Since the failure was transient and resolved by a reboot, the most likely cause is a race condition during boot. The kernel or initramfs may have attempted to mount the root filesystem before the NVMe/SATA disk driver or the device subsystem was fully ready. This kind of failure is sporadic and hard to reproduce, especially on modern hardware with fast boot.