Qubes OS 4.2.0-rc4 is available for testing

We’re pleased to announce that the fourth release candidate (RC) for Qubes OS 4.2.0 is now available for testing. The ISO and associated verification files are available on the downloads page.

Main changes from RC3 to RC4

For an overview of major changes from Qubes 4.1 to 4.2, please see the Qubes OS 4.2.0 release notes.

When is the stable release?

That depends on the number of bugs discovered in this RC and their severity. As explained in our release schedule documentation, our usual process after issuing a new RC is to collect bug reports, triage the bugs, and fix them. This usually takes around five weeks, depending on the bugs discovered. If warranted, we then issue a new RC that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with an RC that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many RCs will be needed before a stable release), but we tend to get a clearer picture of this with each successive RC, which we share in this section in each RC announcement. Here is the latest update:

At this point, we are hopeful that RC4 will be the final RC.

Testing Qubes 4.2.0-rc4

Thank you to everyone who tested the previous Qubes 4.2.0 RCs! Due to your efforts, this new RC includes fixes for several bugs that were present in the previous RCs.

If you’re willing to test this new RC, you can help us improve the eventual stable release by reporting any bugs you encounter. We encourage experienced users to join the testing team.

A full list of issues affecting Qubes 4.2.0 is available here. We strongly recommend updating Qubes OS immediately after installation in order to apply all available bug fixes.

Upgrading to Qubes 4.2.0-rc4

If you’re currently running any Qubes 4.2.0 RC, you can upgrade to the latest RC by updating normally. However, please note that there have been some recent template changes, which are detailed in the Qubes OS 4.2.0 release notes.

If you’re currently on Qubes 4.1 and wish to test 4.2, please see how to upgrade to Qubes 4.2, which details both clean installation and in-place upgrade options. As always, we strongly recommend making a full backup beforehand.

Reminder: new signing key for Qubes OS 4.2

As a reminder, we published the following special announcement in Qubes Canary 032 on 2022-09-14:

We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.

As always, we encourage you to authenticate this canary by verifying its PGP signatures. Specific instructions are also included in the canary announcement.

As with all Qubes signing keys, we also encourage you to authenticate the new Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) as well as on the downloads page under the Qubes OS 4.2.0-rc4 ISO.

What is a release candidate?

A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. RCs are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases and the version scheme in our documentation.

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2023/10/13/qubes-os-4-2-0-rc4-available-for-testing/

404 Not Found

I guess everybody went to the town of Zloty to celebrate. The website is going to be fixed by next year. Try the download:

Getting smarter every day!



Seriously, don’t forget [https://ftp.qubes-os.org/iso//pub/qubes/iso/Qubes-R4.2.0-rc4-x86_64.iso.asc] to verify the signature…


Be careful with following the instructions to enable testing when updating from RC3 to RC4, it left my system unable to boot.

I did notice xenlib reported an error from ldconfig while updating.

1 Like

Should be fixed now.

@marmarek, is enabling current-testing supposed to be required for in-place upgrades from one RC version to another? It seems it was required for RC2->RC3 but now it sounds like it’s causing problems for RC3->RC4.

nothing wrong to report when upgrading from rc3 to rc4 on my system.
(well, I just updated minutes ago, but at least nothing wrong with rebooting Qubes)

maybe there is a command to upgrade only the (main feature of new rc) release without enabling all (packages of) testing repo:
(untested and probably not working to fully upgrade to new rc release)

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-release qubes-release-notes

When I wrote this comment, I was probably a bit hurried to not see my rc2 not being updated to rc3 (according to the number displayed in Qube Manager).
I then enabled the current-testing repo and successfully upgraded to rc3.
I then concluded that this repo was necessary.

But in fact, it was only necessary when the forum post was published.
If we refer to this update issue (the one of rc2 to rc3):

The package qubes-release was in testing at the time of the forum post annoucing the new rc release, but reached the stable repo 7 days later.
(note that this package is only to see the version number in Qube Manager, you could already been running an rcX version (or almost) without this package).

I guess the message about enabling the testing repo should be reformulated.
Something like: If you want to update to the new RC release right now, you need to enable the testing repository, otherwise wait some few days that the new RC release reach the stable repository.
(as mentioned above, it’s about the number displayed in Qube Manager, you may already have all the packages that make the RC4 release, RC4 release (or almost), even if Qube Manager doesn’t display RC4 as version number).

1 Like

What problem you hit? Is there some some issue on github about it?

Yes, something like this. Release (candidate) is a snapshot of latest packages at a given time, when we consider it ready. Those package follows also normal current-testing → stable flow, so they will hit stable repo at some time (sooner than later), if aren’t there already.
So, if you want exactly what is include in RC4 now, they yes, you need to enable current-testing repo. But otherwise you can also wait a few days and eventually you will get all the updates via stable repo too.

libxen failed to update/install, it was the only package that failed. When I restarted the system after the update, it just kept crashing during boot. I can’t find a similar issue on GitHub.

I tried the old kernel and it didn’t change anything, so I just reinstalled RC4 from iso and restored my backup.

I had a ratio of 62.0 with RC3 torrent, let’s get it higher with RC4! :partying_face:


I also noticed this, seems that the older version’s clean up script was failing to complete. But I think the newer version should have been installed successfully. And unfortunately I’m not having the boot problem as yours.

Config after install hangs during template installation. 7950X.

Could you report your issue on Issues · QubesOS/qubes-issues · GitHub to give it a chance to be fixed?

1 Like

Installing on my system running legacy boot went smoothly - so far no problems.

I am just wondering why the standard templates Fedora and Debian have been switched from their vanilla versions to the xfce versions Fedora-38-xfce and Debian-12-xfce. As far as I can see, this is documented nowhere.

This obviously doesn’t replace documentation, but hopefully can give you some context @GWeck:


Had a nightmare of a time fresh installing Qubes (first prob half a decade.) Left me without a working system for a couple of days while I kept coming back in spare time to try get it going.

Similar to Hardware reset during installation and boot of R4.2 on Ryzen 9 7950X · Issue #8322 · QubesOS/qubes-issues · GitHub rc4 was giving me a few different experiences depending on (random??)

  • First install attempt was getting stuck at step 2 template configuring. Would hang forever on debian. Then fedora. Then whonix, and so on. Forcing the machine off and back on would get me back to the same point except one template further down the list of templates it had to configure. Until it eventually got through it (with install error at the end). But things were broken inside and I wasn’t gonna struggle through that. Not all the templates were there either, etc etc
  • Attempting to install standard kernel vs kernel-latest via installer yielded the differing outcome. But my further attempts at reinstalling ranged from black screen on step 2, end of step 2 crashes at network configuration, and variations. Happened every time time.

At this point I discovered that git issue and thought I’d try the advice

Workaround is to add qubes.skip_autostart option to the linux kernel boot parameters at any boot after installation, then unmap this controller from sys-usb once system is up.

on the half completed install I gave up on with no idea what to try next. Doing this resumed the final stages of the setup. Straight past the setup/configuration without a sweat.
That was all that was needed to solve the problem. I didn’t have any usb device passthrough issues with sys-usb after the installer. They’re all still attached to sys-usb right now. It’s just the installer that is bugged.

I fresh installed rc2 when it came out and had zero issue. So something terribly painful happened to break things between rc2 and rc4. Hope this helps someone.

Edit: So I’ve been updating kernels in my working environment and discovered what the problem is. The kernel-latest (6.4.8-1) shipped with 4.2rc4 must be completely wrecked for Ryzen, I assume. When I install it and reboot, I get no usb or networking. Everything breaks. Can’t even get networking going at all. When I remove that and install current-testing kernel-latest (6.5.6-2), it works great and as expected.

I confirm that kernel latest is what hanged for me in my previous post. The regular kernel worked ok besides the usb reset bug.

Try current-testing kernel-latest (6.5.6-2)?

what is the version number for this?

and also this one?