Qubes OS 4.2 Signed Weekly Builds


New ISOs for 4.2 can be found through Issues · fepitre/updates-status-iso · GitHub. ISOs are built like @marmarek said, in a dedicated build machine like how the official ones are done. They can be downloaded at Index of /qubes/iso-testing/ and I’ve uploaded the dedicated signing key https://qubes.notset.fr/iso-testing/qubes-weekly-builds-signing-key.asc

Best regards,



I tried to install today’s version, but with no success:

  • Normally, I am running legacy BIOS, but the ISO file is formatted with GPT, so the test machine has to be switched to UEFI because otherwise, it is not able to read the installation media.

  • The installer forces installation as a UEFI system; there is no way to specify legacy BIOS. Since the target disk already has an MBR filesystem, this may cause problems.

  • After part 1 of the installation, reboot crashes by GRUB going into rescue mode, complaining unknown file system, or, with a slightly different BIOS setup, the system complains that there is no operating system to load.

Is there any way to use the ISO on a legacy BIOS system?

1 Like

The ISO has (among other things) GPT headers to boot as UEFI, but it has also MBR for legacy boot and ISO9660 for booting from DVD (both legacy and UEFI). If you boot installation via UEFI, it will also want installing target system as UEFI, but booting as legacy should work just fine.
Installing in legacy mode works just fine in openQA, but that’s mostly inside a KVM; most tests on physical machines there are using UEFI, and there is also one with Heads, but it has its own boot protocol (based on kexec), so also not a pure legacy boot.

What error specifically you get? Maybe if your BIOS sees both UEFI and legacy, it chooses UEFI (and pretend it didn’t see legacy)? There are usually several firmware settings for the boot mode, maybe you need not only enable legacy boot, but also set to not try UEFI?

1 Like

When trying to boot from the ISO in legacy BIOS mode, the computer (an HP EliteBook 840 G4) does not see the installation USB stick. After converting the USB stick from GPT to MBR, the USB stick is recognized but booting leads to the message This is not a bootable disk ....

Here’s how my partitioning tool (under Windows) sees the USB-Stick:

For the target disk, a SAMSUNG Portable SSD T5, formatted as MBR), I tried all options offered by the BIOS of my machine: legacy BIOS alone, UEFI alone, and both activated, probably selecting UEFI automatically. Each variation leads to one of the errors mentioned above, i.e. GRUB rescue mode with unknown filesystem (with legacy BIOS selected) or BootDevice Not Found (with UEFI selected).

And this is the target disk after part 1 of the installation:

I hope this helps a bit.

1 Like

Currently, I have to boot the installation USB stick via UEFI, and then the target selection step forces me to create the Qubes media as UEFI, too. This problem could possibly be solved if this step allowed to create a Qubes disk with legacy BIOS, even if the installer was started from a UEFI stick. Such a feature could also be useful to create a Qubes disk for some other machine.

Just to make sure: I used the ISO from Index of /qubes/iso/, published by @fepitre.

1 Like

I tried now with the newest ISO (Qubes-4.2.202302220603-x86_64.iso - no change: if the system runs on legacy BIOS without UEFI, it does not see the installation media.

1 Like

Quick question:
Is there a reason, that the Qubes-4.2.202302220603-x86_64.log gives

$ curl http://mirror.notset.fr/qubes/iso/Qubes-4.2.202302220603-x86_64.log
<head><title>403 Forbidden</title></head>
<center><h1>403 Forbidden</h1></center>


It’s a mistake - none of the 4.2 build log files are accessible. whereas
the 4.1 builds are.
Some mistake in the script I suspect - @fepitre ?

1 Like

What are the changes between 4.1 and 4.2?

1 Like

Fixed. Sorry, some wrong permissions on my web server :slight_smile:


The main changes I’m looking forward to, are

  • fedora-37 for dom0
  • xen-4.17

– I’m still trying to get Qubes running on a “new” Lenovo T14 Gen 3 (Ryzen™ 5 PRO 6650U and AMD Radeon™ 660M GPU) … and I’ve seen some hints/comments, that this update might solve some of my issues. :crossed_fingers:


Ok, I can reproduce the issue.


Created Installation image doesn't boot in legacy mode on some systems · Issue #8058 · QubesOS/qubes-issues · GitHub for this.

Has Xen been updated to 4-17 for these test builds? Is there a place I can keep track of when the changes are implemented?


You can also see feptire’s isos’ build logs, such as this one for info about the iso’s components’ versions.


There was a similar 4.2 thread here with that question. Someone responded with a clip from an Qubes event, where they talk about different things including the ones new in 4.2.

You can try find it on youtube or here, whichever is easier for you.

Thanks for the info.

This unbootable installation is created if the target disk is an MBR disk containing already some partition and if this partition is kept in the target selection and configuration step during installation. This led me now to a configuration that could be booted into part 2 of the installation:

  • Change the partition type of the target disk from MBR to GPT.

  • Enable UEFI and disable legacy boot on the target system.

  • Install Qubes OS R4.2, selecting a UEFI configuration during target disk configuration.

After running part 2 of the installation, Qubes R4.2 is entered, but, so far, I was not able to boot into it again. The system again shows the BootDevice Not Found error.

But the following option may help to avoid some problems: If the installer allows creating a legacy BIOS installation of Qubes R4.2 if the selected target disk is already formatted as an MBR disk and not allowed to be erased, the resulting system should be bootable from legacy BIOS - even if the installation itself is running on a UEFI system.

What do you think of that possibility?

See also a comment on the issue #8038.

1 Like

havent try with bios and mbr but i use 4.2 for about a week in usb ssd, change everything to testing repo (dom0 and vm), disable security testing (dom0), and everything is good, only found that qubes qube manager is bug (cant be opened) but everything is fine (i use qubes-prefs to setup things)

I checked now with the same ISO, but different hardware (ASUSTeK Z170M-E D3 motherboard with American Megatrends 2602 BIOS, Intel Core i% 6600 processor, and NVIDIA GeForce GT530 graphics controller). With this configuration, Qubes R4.2 can be installed as intended and keeps running after a reboot. The system disk, which is the same MBR preformatted disk with an existing partition, can be attached to the HP EliteBook 840 G4 after installation of Qubes and is running there.

So it is definitively a matter of the BIOS - HP not recognizing the media, but ASUSTeK doing so. This is plausible as this notebook was specially designed to be used with Windows 10 - but does not run with that system due to driver incompatibility. UEFI is just a wonderful thing!

So I just found another hole to fall into … :grin:

1 Like