The Qubes team just dropped the first candidate for version 4.3.1, packing in essential security patches and upgrading the default Fedora template to forty three since the older release already hit end of life. Testing this build properly means running a clean install rather than an in place upgrade, which actually exercises the installer routines that often hide stubborn bugs. Users restoring older backups should watch for a known quirk where templates might still point at outdated repository mirrors until they manually update their sources. If testers keep things stable over the next couple of weeks, expect the official release to drop before long.

Qubes OS 4.3.1 Release Candidate Brings Fedora 43 and Critical Security Patches

The Qubes team just dropped the first release candidate for Qubes OS 4.3.1, and it is time to start stress testing the update before it hits stable. This patch release bundles all the security fixes and bug squashing that happened since version 4.3.0 went live. Testing this build properly means checking how the new Fedora template handles daily workloads and verifying that the installation routine actually works without breaking existing workflows.

Why This Update Matters

The headline change here is the default Fedora template jumping to version forty three, which makes sense since Fedora forty two already reached end of life. Running an outdated base system inside a security focused OS defeats the whole purpose of compartmentalization. The rest of the changelog reads like a standard maintenance sweep, but that is exactly what keeps virtual machines from randomly dropping network connections or refusing to mount shared folders after a kernel update. Anyone who has spent hours chasing down a broken AppVM knows that patch releases are usually where the real stability lives.

How to Test Qubes OS 4.3.1 Properly

The official recommendation points toward a clean installation rather than an in place upgrade, and there is a solid reason for that choice. A fresh install forces the testing process through the actual installer routines, disk partitioning logic, and initial template downloads. An in place upgrade mostly just applies the same updates that would already be sitting in the update manager of a fully patched forty three point zero system. That approach leaves the installation pipeline completely untested, which is exactly where hidden bugs tend to hide. Before grabbing the ISO, making a full backup of the dom0 configuration and all critical VM data remains non negotiable. Running the installer on a spare drive or in a virtual machine first saves hours of recovery work if something goes sideways during boot.

Known Issues to Watch For

The release notes flag one specific problem that affects people migrating from older builds. Templates restored from backups created before version forty three might still point at the old repository mirrors instead of updating automatically. This does not break fresh installations, but it will cause package managers to throw errors until the sources list gets corrected manually. Anyone planning to restore a working environment should check issue number eighty seven zero one in the tracker before assuming everything syncs correctly. The development team expects to push the stable version within two weeks if no critical flaws surface during this testing window.

Qubes OS 4.3.1-rc1 is available for testing

The first release candidate (RC) for Qubes OS 4.3.1 is now available for testing. This patch release aims to consolidate all the security patches, bug fixes, and other updates that have occurred since the release of Qubes 4.3.0.

Qubes OS 4.3.1-rc1 is available for testing

Grab the ISO, run it through its paces, and report anything that breaks. The more eyes on this build, the fewer headaches show up when the final release drops.