Guide to Running Qubes R4.1

Hello everyone, I’ve successfully installed Qubes 4.1 on my Framework Laptop and publish this post from a disposable qube. I should warn that this guide is subject to further revision and that Qubes 4.1 is prerelease software and as such does not have the same security and stability guarantees as official stable releases.

The Qubes-20210731-kernel-latest-x86_64.iso was sourced from this Qubes community post and verified as described in How to verify the cryptographic hash values of Qubes ISO. It should be noted that the iso isn’t signed by any release key or any key signed by the Qubes Master Signing Key but instead by fepitre-bot.

The hash of the installation media and later the installed Qubes OS must be added to the BIOS to satisfy secure boot. The media installs and boots Qubes successfully though the fan does spin up and the laptop becomes warm as the templates are installed and configured.
It should be noted that by default the sys-net qube is set to use the 5.12.14-1.fc32.qubes kernel. I have not been able to get the AX210 wifi card working under this kernel and as such the kernel for sys-net should be changed to 5.10.54-1.fc32.qubes in Qubes Manager. Shut down all qubes that depend on this as a netvm and then restart sys-net. The wifi card can be cajoled to work via renaming or removing /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm.xz and reinserting the iwlwifi and iwlmvm kernel modules.

Open a terminal in sys-net

Navigate to firmware directory

cd /lib/firmware/

Rename problematic pnvm file so it doesn’t load

sudo mv iwlwifi-ty-a0-gf-a0.pnvm.xz renamed.iwlwifi-ty-a0-gf-a0.pnvm.xz

Remove iwlwifi and iwlmvm kernel modules

sudo modprobe -r iwlmvm && sudo modprobe -r iwlwifi

Reinsert those kernel modules

sudo modprobe iwlwifi && sudo modprobe iwlmvm

The NetworkManager applet in the Application tray should refresh and show wifi networks you can connect to. The first attempt to connect to a network will fail and display disconnected and remove the list of networks. To resolve this reinsert the kernel modules as above and the applet will refresh and successfully connect.

Refresh NetworkManager

Remove the kernel modules again.

sudo modprobe -r iwlmvm && sudo modprobe -r iwlwifi

Reinsert them again.

sudo modprobe iwlwifi && sudo modprobe iwlmvm

Some final notes as sys-net is either configured by the user at install as an AppVM or as a DisposableVM these fixes will not persist past reboot of sys-net or Qubes itself. In order to more permanently address this issue the commands to rename the iwlwifi-ty-a0-gf-a0.pnvm.xz should be executed in the Fedora-34 TemplateVM and then shutdown.

Open a terminal in dom0

Run gnome terminal in fedora-34 TemplateVM

qvm-run -a fedora-34 gnome-terminal

Enter all following commands in the TemplateVM terminal

cd /lib/firmware/

sudo mv iwlwifi-ty-a0-gf-a0.pnvm.xz renamed.iwlwifi-ty-a0-gf-a0.pnvm.xz

sudo poweroff

My own experience is with a dispVM version of sys-net and as such I have to reinsert the kernel modules and connect to wifi manually every boot.

Commands that were helpful for information gathering/troubleshooting

See messages about wifi firmware and how it loads

sudo dmesg | grep iwlwifi

See messages about NetworkManager and why connections fail

sudo journalctl -u NetworkManager

Restart NetworkManager

sudo systemctl restart NetworkManager

Edit 1
In order to fix screen tearing I added a configuration file as described in this community post and the Qubes Gui Configuration doc. I also reformatted some of the earlier instructions to clarify why and what commands should be entered into terminals.

Open a terminal in dom0

Navigate to directory where the file will be written

cd /etc/X11/xorg.conf.d/

Write the file

sudo nano 20-intel.conf

Type what’s below into the file

Section “Device”
Identifier “Intel Graphics”
Driver “intel”
Option “TearFree” “true”


nice post! I haven’t played with qubes yet (still a live kali image guy or TAILS guy) but I’ve been meaning to and now seems like a grand time. Thanks!

Thank you for this reply,
I have just made my way back to framework after getting their email about running Linux.

I did post some time back about Qubes being able to run on the Framework laptop. The reply was that the Tigerlake processor was not supported by Qubes (I note that the git link in that post is now blank

So do I take from this post that the latest qubes (yes, I see it pre-release) will work with Framework? If so, I’m buying. I was hanging off looking at the latest Purism but that company has problems, so it if pleasing to hear that qubes may work with a bit of tweaking which should hopefully improve, or even be offered by Framework.

Thanks for the post.

I’m not saying it won’t work, but the link you mentioned isn’t blank to me but leads to an issue that is still not closed, so my guess would be that it may still cause problems.

I really wanted to install Qubes on this laptop, and was quite disappointed that official release wouldn’t even boot the installation media.
I can’t run a beta because I actually use this for work, however, it does give me hope that in the future Frame.Work will have this option.

I installed the beta knowing I was taking a risk. So far, I’ve been happy with it. It preforms well and even plays YouTube videos. My only complaint is that it doesn’t do more to warn of a low battery. I get about 3 hours of battery life and then it will suddenly shut down (a proper O.S. shutdown, not just a power cut).

1 Like

has anyone gotten this running well on expansion card? I got it to boot a few times until i unplugged and now cannot find it bios boot menu or nada. I am trying to fix grub on the main os but cannot figure it out. Any help would be appreciated

1 Like

I was able to add the modprobe commands (remove the modules, then re-add them) to /rw/config/rc.local to avoid needing to run them each time I started my computer.

discovered via this thread:

How are folks dealing with scaling issues? I tried the scaling on dom0 but it’s not affecting vms.

I successfully installed Qubes 4.1 (R4.1) on my new Framework. Here’s
the configuration of the Framework.
CPU: Intel® Core™ i7-1165G7
Storage: 2TB - WD_BLACK™ SN750 NVMe™
Memory: 64GB (2 x 32GB) DDR4-3200
WiFi: Atheros QCNFA222

Note the WiFi card is not one
offered by Framework. It was scrounged from my Librem 13, which was
falling apart and barely usable.
The WiFi card I had purchased from Framework was not recognized, which
is why I switched WiFi cards

WiFi: Intel® Wi-Fi 6E AX210 No vPro®

I installed from a USB stick ISO

I shut down the framework laptop.
Tap F2 repeatedly to enter BIOS.
Then I disabled secure boot and enabled restoring secure boot to factory settings.
Under “Security” tab
“Enforce Secure Boot” => disabled
F10 brings up “Exit Saving Changes”, choose “Yes”
Then I shutdown and booted while tapping F12.
Then I was able to select my boot device loaded with QubesOS ISO.

I let Qubes take over the entire SSD, just as I had with my old Librem
Qubes OS with Xfce
Mostly, I used default settings.

After rebooting into Qubes, the installation continues.
I used fedora-34 as the default template during setup.
I changed the default template later.
But only after sys-usb was set up to use fedora, not Debian.
This was critical for me.
sys-usb did not work well for me using debian-11-dvm template.
I regularly saw “” device available, with these messages:
Device is available
Device removed

This device really had an empty name. I used a USB Dell DisplayLink
for Ethernet access, while restoring my Qubes. Under Debian sys-usb,
the device was only available for about an hour, not long enough to
complete the restoration. The DisplayLink first was removed from
sys-net. And, eventually, sys-usb device shut down.

With fedora dvms for sys-usb, sys-net and sys-firewall, I successfully
restored my largest Qube overnight.

WiFi and NetworkManager are working fine.

This morning, I noticed that my sys-usb was not running. Even though
sys-usb is supposed to start automatically on boot. After
manually starting sys-usb, everything seems fine. I can attach devices
to Qubes.

I found sys-firewall had turned red and with a spinning red circle
I stopped and started sys-firewall,
including shutting down all Qubes using sys-firewall. Everything seems
better after.

My previous Qubes installation did not use dvms for sys-firewall and
sys-usb. It had been upgrade from 3.x, which did not have this option.
I am not using a dvm for sys-net. Only because the installation made
this setup slightly easier.

Are the dvms responsible for problems with sys-firewall and sys-usb,
or is it something else?

I have had a couple of my Qubes get stuck while starting. After
killing them and starting them, everything was fine.

I successfully used zoom with the camera, but used phone for sound.

I’m still working on suspend/resume.

1 Like

Following b/c having resume issues. How is Bluetooth for you?

NM resume/suspend fixed with simply following last suggestion in Suspend/resume troubleshooting | Qubes OS

Specifically adding mem_sleep_default=deep to grub

Also disabled hyperthreading in bios

Resume does not work for me either.
I saw something which suggested that this is being worked on.
Perhaps on github
I have not used bluetooth, and I do see warnings against it in Qubes, for example:

Thanks for the suggestion @Mdaly001
Unfortunately the troubleshooting did not work for me.
I tried both the blacklist and the grub.
I used exactly the same wifi card, an Atheros, on my qubes installation for my old Librem 13, no modification needed.

Here is the Qubes tracking issue for full support of Intel Tiger Lake Processors, including suspend/resume.

I’m using Qubes R4.1 on my Framework, and it’s working great!
Here’s some jot notes from my install/setup process, including the problems I found and their solutions


Hello, all! I too have Qubes 4.1 setup and running fairly well on my framework, with two notable exceptions: 1. Battery life and suspend are terrible and susepend doesn’t seem to work. 2. The AX210 card no longer works for me with the workaround for the 5.10 kernel in sys-net. Has anyone found another way of getting that Wifi card to work? Also, WHY doesn’t it work in the first place since it seems to works in every other linux distro I have tried and read about with updated kernel? It seems like there must be an issue with Xen virtualization detecting interfering with it somehow.

I got a gen 12 framework with the non-vpro AX210 wifi card. I tried putting qubes R4.1.1 on it.

Out of the box with kernel 5.15 the mouse lags terribly, and the GUI refreshes are choppy (you can see the window render from top to bottom, and there are tears). This was noticeable on the install media. The wifi did not work out of box, so had to connect a ethernet-usb adapter. After updating to kernel-latest in dom0 (5.18), the mouse lag issue is gone, but the GUI still looks a little bit laggy (text I type in sometimes get tears, and doesn’t show up immediately; components in system menus have tears). The thing with the GUI artifacts is, if I play youtube video in firefox, all the GUI lag is gone. So, I suspect it is a settings issue, somewhere.

Could not get the wifi to work even with the 5.18 kernel. The driver blob should be there, the name even matches the one Intel publishes on their site. However, it just wouldn’t load properly. Fwiw when I installed ubuntu 22.04 later (what I am on now), I had the same issue (lspci lists AX210 but driver isn’t loaded so network manager just doesn’t see the wifi device), but I found out there’s a backport-iwlwifi-dkms package which fixed it. That package should be available in Debian too, but by then I wasn’t running qubes, so I couldn’t experiment with it.

Suspend does not work. The machine just never wakes up. I found on qubes forum something about Xen 4.14 not supporting s0ix sleep in tiger lake, so presumably that carries over to alder lake? Haven’t really bothered doing more digging into the chipset framework uses or verifying the Xen issue. I tried the thing in some old qubes forum thread about turning off hyperthreading. Nope, it does nothing.

For me the no wifi thing was a deal breaker. No suspend would have been really irritating but okay for say 80% of the time when I use the laptop as a desktop replacement, all plugged in. It is really a pity that qubes (due to Xen and probably other factors) doesn’t work on the newest hardware ootb. I find it ridiculous that people keep recommending 10 year old laptops like the X230 to run qubes on.

Hi wilson

Thanks for sharing your Qubes experience. My batch 3 framework isn’t here yet but I’m really interested in using Qubes.

If the wifi was the primary deal breaker and you don’t need 6Ghz support, you could get an older intel wifi card like the 9260 for <$15 and use it until the ax210 is better supported.

1 Like

I’m running Qubes on an 11th gen Framework Laptop, and have been for some months. I cannot get Suspend to work probably because of the Xen issue you mentioned, but I can also clarify that the AX2xx card series does not work because of a separate Xen issue, so I am using an older card (really any other card will likely work), but I did see a post a couple days ago that there is a Xen patch that seems to work, but has not been added to the source upstream yet, I believe. The firmware exists in QubesOS and is technically loaded, but something in the Xen timeouts breaks it without that patch. I am not running that patch by the way, I haven’t gotten around to trying that yet.

On a separate note, QubesOS support the 11th Gen Framework fairly well across the board, aside from suspend and the ax2xx card series (and I don’t know about the fingerprint reader since I don’t use it), but definitely be sure you are an experienced Linux user (XFCE is a plus since that’s the default DE) before plunging into that OS, because it has been challenging so far to get many things to work exactly as I want.