Qubes OS 4.2.0-rc2 is available for testing

this is strange, it should be changed to fc37

I think I found the issue, maybe related that 4.2 is currently in RC2.

I changed the global settings to use regular updates instead of testing/unstable dom0 updates, I’m doing the process again and now it’s downloading a lot of fedora 37 packages, so it seems to be going well now.

edit: I’m now on 4.2-RC2 after upgrading from 4.1 :slight_smile: I had to disable the extra unstable/testing repos and it worked following the official guide.

1 Like

Upgrade doesn’t work:
—Errors during downloading metadata for repository ‘qubes-dom0-cached’:

  • Curl error (37): Couldn’t read a file:// file for file:///var/lib/qubes/updates/repodata/repomd.xml [Couldn’t open file /var/lib/qubes/updates/repodata/repomd.xml]
    Error: Failed to download metadata for repo ‘qubes-dom0-cached’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

___Error canonicalizing /var/tmp/qubes-updates-tmpg2wc01kd.UNTRUSTED/qubes-release-4.2-0.3.fc32.noarch.rpm

___CalledProcessError: Command ‘[‘qrexec-client-vm’, ‘dom0’, ‘qubes.FeaturesRequest’]’ returned non-zero exit status 1.

After trying to fix these, Whonix:

How do you set clipboard expiration? In the global settings manager, in the clipboard tab, I find nothing related to this new feature. :thinking:

This looks exactly the same issue I had when using dom0 testing security fixes and dom0 unstable updates.

This statement should be expanded, as it’s not clear where PipeWire support is: Just the fedora template? Debian one as well? Pipewire in dom0?

Before in place upgrade Qubes 4.1 to 4.2 Whonix users should make sure they upgraded Whonix-16 to Whonix-17

When still running Whonix-16 the upgrade to Qubes 4.2 will fail.


But Whonix 17 isn’t available on Qubes 4.1, so how can a user on Qubes 4.1 upgrade to Whonix 17 before upgrading to Qubes 4.2? @adrelanos?

If I`m not mistaken - after looking at the issues on github - 4.2 rc2 will not boot with Seabios (without CSM/Legacy boot). Not sure if installing 4.1.2 and upgrading would work as a workaround.

I am not aware of this. That might be a Qubes bug if Qubes-Whonix has this amount of undue power which it shouldn’t have in the threat model. If so, a bug would need to reported to Qubes upstream on Issues · QubesOS/qubes-issues · GitHub.

I tend to think this is most likely user error and not a Qubes bug.

Are templates build for Qubes R4.1 compatible with Qubes R4.2? @marmarek

  • If yes, and I presume so, I don’t see how that could cause any issues.
  • If no, then after upgrading Qubes R4.1 to Qubes R4.2, users who wish to upgrade dom0 or Templates over Whonix would have a problem.

Probably not needed as per above.


  1. Release Upgrade Whonix 16 to Whonix 17
  2. apply the same procedure that one would use to upgrade a Debian 12 (bookworm) Template from Qubes 4.1 to 4.2 to the Qubes-Whonix Templates

Might have a pretty good chance.

1 Like

When attempting the in-place-update, I was blocked on Stage 2.
I got a qubes.ReceiveUpdates error with returned non-zero exit status 1
which result to the canonicalizing error.

No security or unstable repo enabled.

journalctl report:

dom0 qubes.ReceiveUpdates+-sys-firewall-dvm[34312]: Error canonicalizing file: No key available!
dom0 qubes.ReceiveUpdates+-sys-firewall-dvm[34312]: Error canonicalizing /var/tmp/qubes-updates-tmp2ejy9fkh.UNTRUSTED/qubes-release-4.2-0.3.fc32.noarch.rpm

I had to manually add the 4.2 key (in dom0):

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4.2-primary

and then, I was able to perform Stage 2 update.
No (blocking) errors from all other stages.

I’m trying to update in-place my desktop to 4.2 but I got this problem… :sweat_smile:

Before dom0 install new packages, it asks to shutdown all VMs, if you say No it aborts, if you say yes it continues but stop sys-usb, and you are left with a system on which you can’t do anything except using the power button…

Would it be ok to keep sys-usb running during the update using --keep? Could it be the default? (or at least add a warning), a step before it was asking to shutdown VMs but not the system VMs. The last message wasn’t clear enough IMO

Perhaps your sys-usb qube name is not ‘sys-usb’ ? If so, it should be run with -u or --usb.

See help for details: qubes-dist-upgrade.sh --help

It’s named sys-usb.

Ok, after the pre-boot upgrade, after I restarted, I got a prompt fur the LUKS passphrase, and then I’m stuck indefinitely on the plymouth screen.

Not sure how to debug that, I removed the plymouth from the command line, I see a lot of stuff displayed on the tty but nothing significant. I saw a message about lightdm starting correctly, but that’s all.

I bricked my Qubes OS and I have no idea how to fix it now :joy_cat: I did the dom0 snapshot, but I can’t access a Qubes OS root console to recover.

edit: I opened an issue Qubes OS stopped booting after pre-reboot in-place 4.1 to 4.2-RC2 upgrade · Issue #8480 · QubesOS/qubes-issues · GitHub

qubes-tunnel is not available yet for r4.2.0-rc2 - not a huge surprise I guess. Look forward to its inclusion later.

I guess this is a good reminder to turn autostart on sys-usb OFF before doing anything like this. That way your system may freeze up but at least on reboot sys-usb won’t start.

Just a quick question for those who are testing Q4.2:
Since dom0 got upgraded to Fedora 37 and uses Xfce, can you confirm that it’s Xfce 4.16 and that in the PowerManager there is some kind of option for night mode (blue light filter) based on color profiles?

If not, then I guess I’ll have to use redshift…

xfce is 4.16, so far i have not discovered a dedicated night mode, still using good old Blue Light Filter in XFCE (Redshift)

Qube Manager Dark Mode (built-in method) and so on.


Thank you. According to Xfce release manager Simon Steinbeiss on his blog this was part of the development goals:

It should be either in Power Manager or “settings daemon”, unless they ended up dropping that feature after all.