Qubes OS 4.2.0-rc2 is available for testing

We’re pleased to announce that the second release candidate (RC) for Qubes OS 4.2.0 is now available for testing. Qubes 4.2.0-rc2 is available on the downloads page.

What’s new in Qubes 4.2.0-rc2?

  • Dom0 upgraded to Fedora 37
  • Xen updated to version 4.17
  • Default Debian template upgraded to Debian 12
  • Default Fedora and Debian templates use Xfce instead of GNOME
  • SELinux support in Fedora templates
  • Several GUI applications rewritten, including:
    • Applications Menu
    • Qubes Global Settings
    • Create New Qube
    • Qubes Update
  • Unified grub.cfg location for both UEFI and legacy boot
  • PipeWire support
  • fwupd integration for firmware updates
  • Optional automatic clipboard clearing
  • Official packages built using Qubes Builder v2
  • Split GPG and Split SSH management in Qubes Global Settings

Please see the Qubes OS 4.2.0 release notes for details.

When is the stable release?

That depends on the number of bugs discovered in this release candidate and their severity. As explained in our release schedule documentation, our usual process after issuing a new release candidate 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 release candidate that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with a release candidate 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 release candidates will be needed before a stable release), but we tend to get a clearer picture of this with each successive release candidate, which we’ll share in this section in future release candidate announcements. The feedback we receive on this release candidate will determine whether another one is required.

Testing Qubes 4.2.0-rc2

Thank you to everyone who tested 4.2.0-rc1! Due to your efforts, this new release candidate includes fixes for several bugs that were present in the first release candidate.

If you’re willing to test this new release candidate, 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-rc2

In-place upgrades from Qubes 4.1 to Qubes 4.2 are now implemented and ready for testing! As always, we strongly recommend making a full backup beforehand.

Current Qubes 4.2.0-rc1 systems should be updated normally, but please note that some templates have changed from the first release candidate. These changes are listed above.

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-rc2 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. Release candidates 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.

What is a minor release?

The Qubes OS Project uses the semantic versioning standard. Version numbers are written as ... Hence, releases that increment the second value are known as “minor releases.” Minor releases generally include new features, improvements, and bug fixes that are backward-compatible with earlier versions of the same major release. See our supported releases for a comprehensive list of major and minor releases and our version scheme documentation for more information about how Qubes OS releases are versioned.


This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/
5 Likes

Looking forward to get “Valentina” App Menu as the new default :heart_eyes:

Thank you @ninavizz :pray:

2 Likes

Same issue I reported with rc1 Qubes OS 4.2.0-rc1 is available for testing - #2 by solene , there is no seed for the torrent download :frowning:

Should have a server seeding it now.

2 Likes

Cool! Thanks, I was also setting up a server, but it’s not seeding for some reasons… :frowning:

edit: it’s working with 2 seeders now \o/

EDIT: I went too fast, I installed the upgrade tool while I thought it was actually doing the upgrade :crazy_face:

everything is fine :ok_hand:

Original message:

sudo qubes-dom0-update -y qubes-dist-upgrade didn’t do much on a 4.1 installation.

This installed qubes-dist-upgrade-4.1.1-1.fc32.noarch and nothing more. How do I upgrade from 4.1 to 4.2-rc2?

I tried using the ISO but once booting it, I can’t find an upgrade option.

Is it expected that the upgrade is blocked by whonix? (found Fedora-38-based management qube causes Salt errors when updating certain templates: `Failed to return clean data... ModuleNotFoundError: No module named 'urllib3.util.ssl_match_hostname'` · Issue #8440 · QubesOS/qubes-issues · GitHub)

[solene@dom0 ~]$ sudo qubes-dist-upgrade --all-pre-reboot
WARNING: /!\ MAKE SURE YOU HAVE MADE A BACKUP OF ALL YOUR VMs AND dom0 DATA /!\
-> Launch upgrade process? [y/N] y
---> Allow shutdown of unnecessary VM (use --keep-running to exclude some): Communication T WWW sys-vpn vault? [y/N] y
---> (STAGE 1) Do you want to make a dom0 snapshot? [y/N] n
---> (STAGE 1) Updating dom0...
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
No updates available
---> (STAGE 1) Updating Templates VMs and StandaloneVMs...
whonix-ws-16: ERROR (exit code 20, details in /var/log/qubes/mgmt-whonix-ws-16.log)
whonix-gw-16: ERROR (exit code 20, details in /var/log/qubes/mgmt-whonix-gw-16.log)
fedora-38: OK
fedora-37: OK

There is this in mgmt-whonix-ws-16.log (same error for gw-16)

2023-08-29 15:15:06,510 calling 'state.sls update.qubes-vm'...
2023-08-29 15:17:53,234 output: whonix-ws-16:
2023-08-29 15:17:53,236 output:     ----------
2023-08-29 15:17:53,236 output:     _error:
2023-08-29 15:17:53,237 output:         Failed to return clean data
2023-08-29 15:17:53,237 output:     retcode:
2023-08-29 15:17:53,237 output:         1
2023-08-29 15:17:53,237 output:     stderr:
2023-08-29 15:17:53,237 output:         Traceback (most recent call last):
2023-08-29 15:17:53,237 output:           File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in <module>
2023-08-29 15:17:53,238 output:             salt_call()
2023-08-29 15:17:53,239 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 438, in salt_call
2023-08-29 15:17:53,239 output:             import salt.cli.call
2023-08-29 15:17:53,239 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in <module>
2023-08-29 15:17:53,240 output:             import salt.cli.caller
2023-08-29 15:17:53,241 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in <module>
2023-08-29 15:17:53,241 output:             import salt.channel.client
2023-08-29 15:17:53,241 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in <module>
2023-08-29 15:17:53,241 output:             import salt.crypt
2023-08-29 15:17:53,242 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in <module>
2023-08-29 15:17:53,242 output:             import salt.payload
2023-08-29 15:17:53,242 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in <module>
2023-08-29 15:17:53,242 output:             import salt.loader.context
2023-08-29 15:17:53,242 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 23, in <module>
2023-08-29 15:17:53,242 output:             import salt.utils.event
2023-08-29 15:17:53,244 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/event.py", line 67, in <module>
2023-08-29 15:17:53,244 output:             import salt.ext.tornado.iostream
2023-08-29 15:17:53,244 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/iostream.py", line 42, in <module>
2023-08-29 15:17:53,244 output:             import urllib3.util.ssl_match_hostname
2023-08-29 15:17:53,244 output:         ModuleNotFoundError: No module named 'urllib3.util.ssl_match_hostname'
2023-08-29 15:17:53,245 output:         [ERROR   ] An un-handled exception was caught by Salt's global exception handler:
2023-08-29 15:17:53,245 output:         ModuleNotFoundError: No module named 'urllib3.util.ssl_match_hostname'
2023-08-29 15:17:53,245 output:         Traceback (most recent call last):
2023-08-29 15:17:53,245 output:           File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in <module>
2023-08-29 15:17:53,245 output:             salt_call()
2023-08-29 15:17:53,245 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 438, in salt_call
2023-08-29 15:17:53,246 output:             import salt.cli.call
2023-08-29 15:17:53,246 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in <module>
2023-08-29 15:17:53,246 output:             import salt.cli.caller
2023-08-29 15:17:53,246 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in <module>
2023-08-29 15:17:53,246 output:             import salt.channel.client
2023-08-29 15:17:53,246 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in <module>
2023-08-29 15:17:53,246 output:             import salt.crypt
2023-08-29 15:17:53,246 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in <module>
2023-08-29 15:17:53,246 output:             import salt.payload
2023-08-29 15:17:53,246 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in <module>
2023-08-29 15:17:53,249 output:             import salt.loader.context
2023-08-29 15:17:53,249 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 23, in <module>
2023-08-29 15:17:53,249 output:             import salt.utils.event
2023-08-29 15:17:53,249 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/event.py", line 67, in <module>
2023-08-29 15:17:53,251 output:             import salt.ext.tornado.iostream
2023-08-29 15:17:53,252 output:           File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/iostream.py", line 42, in <module>
2023-08-29 15:17:53,252 output:             import urllib3.util.ssl_match_hostname
2023-08-29 15:17:53,252 output:         ModuleNotFoundError: No module named 'urllib3.util.ssl_match_hostname'
2023-08-29 15:17:53,252 output:     stdout:
2023-08-29 15:17:53,252 output: /usr/lib/python3.11/site-packages/salt/utils/http.py:8: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13
2023-08-29 15:17:53,254 output:   import cgi
2023-08-29 15:17:53,254 output: /usr/lib/python3.11/site-packages/salt/utils/jinja.py:9: DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
2023-08-29 15:17:53,254 output:   import pipes
2023-08-29 15:17:53,254 exit code: 20

Since whonix-16 is based on debian-11, it’s expected if your mgmt VM is using fedora-38. Switch to debian-11 (or 12) or enable current-testing in the fedora-38 template to install the latest salt version.

This kind of instructions / check should be either in the upgrade guide or in the upgrade script.

I deleted my whonix VMs because I don’t use them, but expect it to make troubles for many users relying on tor.

This is a temporary issue and it will be fixed soon. This is a salt issue as you can see in the github post you linked to earlier. Once the new salt package is in the stable repository, everyone using fedora-38 for the mgmt VM will be able to upgrade.

Edit:

It’s in the stable repository now:

2 Likes

does it look right for STAGE 5?

this

---> (STAGE 5) Cleaning up salt
Error on ext_pillar interface qvm_prefs is expected
local:
    True
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable

in between information

[WARNING ] top_file_merging_strategy is set to 'merge' and multiple top files were found. Merging order is not deterministic, it may be desirable to either set top_file_merging_strategy to 'same' or use the 'env_order' configuration parameter to specify the merging order.
local:
    ----------
    beacons:
    clouds:
    engines:
    executors:
    grains:
        - grains.boot_mode
        - grains.pci_devs
        - grains.redefined_dom0_grains
        - grains.whonix
    log_handlers:
    matchers:
    modules:
        - modules.debug
        - modules.ext_module_qvm
        - modules.module_utils
        - modules.qubes
        - modules.qubes_dom0_update
        - modules.topd
    output:
    pillar:
        - pillar.qvm_prefs
    proxymodules:
    renderers:
    returners:
    sdb:
    serializers:
    states:
        - states.debug
        - states.ext_state_qvm
        - states.status
    thorium:
    utils:
        - utils.__init__
        - utils.fileinfo
        - utils.matcher
        - utils.nulltype
        - utils.pathinfo
        - utils.pathutils
        - utils.qubes_utils
        - utils.toputils

and this error? (i didn’t make a dom0 snapshot because I made a backup before)

---> (STAGE 5) Adjusting default kernel
Changing default kernel from 6.1.43-1.fc32 to 6.1.43-1.fc32
  Failed to find logical volume "qubes_dom0/Qubes41UpgradeBackup"

After rebooting, /etc/qubes-release shows 4.1.2 :sweat_smile:

It states that :

But yest, I was also scared by those error :stuck_out_tongue:

Oh, I’ve read it as

“Error on ext_pillar”, “interface qvm_prefs is expected”

but still, there is an error at the end, and I’m still on 4.1 :frowning:

1 Like

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.