Qubes OS 4.2.0-rc3 is available for testing

We’re pleased to announce that the third 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.

Explanation for the early RC

We announced RC2 approximately one week ago. Normally, RC2 would have been tested for approximately five weeks before we announced RC3. However, RC2 contained several bugs (listed below), some of which prevented certain users from testing it. These bugs have been fixed in RC3. We’ve decided to release RC3 early, as an exception to our usual policy, in order to get these fixes out as quickly as possible so that more users can test 4.2 for longer before the eventual stable release.

Main changes from RC2 to RC3

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.

At this point, we can say that there will be at least one more RC after this one.

Testing Qubes 4.2.0-rc3

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-rc3

If you’re currently running any Qubes 4.2.0 RC, you can upgrade to the latest RC by enabling the current-testing repo in dom0, then 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-rc3 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/09/03/qubes-os-4-2-0-rc3-available-for-testing/
7 Likes

It says: PipeWire support (#6358).

But the issue is open and the purposes of commits are not clear, some of them on contrary disable pipewire-related stuff. It is not obvious what is the current situation with pipewire and pulseaudio in the R4.2.

  • Is there any documentation about the current situation?
  • What should user use in dom0 and what in templates in R4.2?
  • If pipewire then does it have problems with sys-audio and audio qube approach? Or should user still stick to pulseaudio manually solving the packaging conflicts as it is in R4.1?
  • If pipewire in dom0, than will it work with existing user’s templates (e.g. migrated from backup) that use pulseaudio?
2 Likes

Connecting Display triggers Displaymanager in all running DomU · Issue #8485 · QubesOS/qubes-issues · GitHub testing is fun.

How can we test the new clipboard cleaning feature?

And +1 for the pipewire questions

And cool, there was some seeding on the torrent this time :partying_face: I’ve put a server seeding it too to hlep.

3 Likes

https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping

To enable automatic wiping of the clipboard after a minute use qvm-service:
qvm-service --enable VMNAME gui-agent-clipboard-wipe

You could also manually add it in the service tab of the qube setting.

The “1 minute” is not (yet?) customizable.
https://github.com/QubesOS/qubes-gui-agent-linux/blob/main/gui-agent/vmside.c#L57

If you want to change it, I guess you have to compile the gui-agent. :slight_smile:

thanks! Is it possible to enable it for all qubes by default?

CSM needed to be enabled in the BIOS for install. Other than that, it appears to be working VERY well. Excellent!

How do you configure split-ssh from the GUI?

I found a pretty nasty bug, I wonder if someone is able to trigger it? On 3 Qubes OS 4.2-RC3, only the one with the fresh install had this issue, but maybe it’s unrelated to upgrade vs fresh install :woman_shrugging:

1 Like

Another issue that would be welcome to confirm with other devices. Attached USB audio devices don’t have sound, except if you change their profile using some tool like pavucontrol. I have this issues on all my Qubes OS 4.2 computers, with 3 different devices.

It would be nice to mention that [qubes-dom0-current-testing] need to be enabled to update to one RC to the other one (e.g. rc2 to rc3).
(Qubes OS Global Config > Updates > Enable all testing updates).

It may sound obvious for some, but not for others.

Btw, the unstable repo update are missing in this Updates tab.
It maybe on purpose …

5 Likes

tanks for sharing, that’s not really obvious to me :sweat_smile:

Oh, I didn’t know that. My mistake. Thank you for pointing it out. I’ve added the missing step:

1 Like

Network password not persistent using persistent Debian sys-XYZ service Qubes with a fresh 4.2.0-rc3 installation (tried multiple times and failed every time). I’ll submit a bug report if this isn’t something else I’m missing.

could you check your wifi device is always seen as the same device?

For instance, sometimes mine is wls6 and sometimes wls7, and network manager will associate that device to the wifi network… it’s not new in 4.2

Maybe somebody who uses R4.2 can install qbittorrent inside fedora-38 and check if the icon on a taskbar is a generic cube/lock or a proper one?

Installation inside template fedora-38:
sudo dnf install qbittorrent

I want to bump this issue for R4.2.

For me it looks like qbittorrent icon colored using the AppVM color, everything looks good. Worked fine in 4.1 before too.

1 Like

So, on Fedora 38 and R4.1 it works fine for you, the icon on the taskbar in default XFCE is not a generic cube?

If that is true, I should look into my templates based on Fedora-38-minimal, maybe the issue is there.

ah, I only checked the systray, let me check again the other icons

so, with my red torrent qube based on fedora-38 template:

  • new Qube xfce menu: red qbittorent icon is there
  • old applications menu: red qbittorrent icon
  • xfce panel: red qube
  • xfce systray: red qbittorrent icon
  • alt+tab: red qube
1 Like