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”
EndSection

10 Likes

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 https://github.com/QubesOS/qubes-issues/issues/6411).

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

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: https://www.reddit.com/r/Qubes/comments/blioei/what_is_the_best_way_to_run_commands_or_software/

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
13.
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.

sys-usb
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.

sys-firewall
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