[GUIDE] One-Stop Post for Framework 13, Intel on Qubes

This is based on a post I made on the Qubes OS forums. However, as I am unable to update the original after a certain time, I wanted to post a solved method for getting the kinks out of setup.

This was tested on Qubes 4.1.2 and is also known to work on Fedora, which dom0 is based on, by default in Qubes.


  • Requires disabling Secure Boot in the BIOS
  • Requires setting time and date in BIOS to match UTC/GMT

If there is something missing from the section below, it is assumed to be working:

State During and Immediately After Installation

  • Screen tearing/slow display refresh rate (depends on how “busy” the window manager is) (see fix below)
  • Brightness hotkeys not working (see fix below)
  • Suspend/resume completely broken (does not come back from apparent low-power state and must be power-cycled) (see fix below)
  • Terrible battery life (see improvement below)


Screen tearing

From dom0:

sudo qubes-dom0-update
sudo qubes-dom0-update kernel-latest

Brightness Keys, Suspend/Resume, Battery Life

From dom0 - feel free to use nano, if preferred:

sudo vim /etc/default/grub

Add the following to the end of

  • Add mem_sleep_default=deep (fixes issues with suspend/resume)
  • Add module_blacklist=hid_sensor_hub (fixes issue with brightness keys)
  • Add nvme.noacpi=1 (improves battery life and power consumption)

Your /etc/default/grub file should resemble the following:

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-6868706d-c28d-4871-9cd4-03b156ca9a4f rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rd.driver.pre=btrfs rhgb quiet"
GRUB_CMDLINE_XEN_DEFAULT="console=none dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096"
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes.hide_all_usb mem_sleep_default=deep module_blacklist=hid_sensor_hub nvme.noacpi=1"
  • Apply the GRUB config changes (from dom0):

Note, the path below will change in Qubes 4.2 (which is not yet a stable release as of this post)

sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg
sudo dracut -f
  • Reboot
  • Verify the arg shows up and is applied (from dom0):
sudo cat /etc/proc/
placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-39f8de13-ee6d-46fb-9f15-975f32c850c8 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rd.driver.pre=btrfs rhgb quiet rd.qubes.hide_all_usb mem_sleep_default=deep
  • Done

Nice. I’m also running Qubes but 4.2. I was seeing intense slowness when using the 4.1 installer, and even after it was installed. Not sure why but it was unbearably slow. Reinstalled with 4.2 and had none of the performance issues that I saw with 4.1. Maybe it was the screen tearing? Not sure but moving the cursor was extremely slow to refresh or move around. Everything seemed slow and delayed.

I’m going to try adapting your fixes to 4.2. Any luck with the fingerprint reader? It seems like it will work based on the sys-usb seeing the device apparently fine.

I think I tried the battery life fix and the mem_sleep_default but it didn’t seem to make a difference on my first attempt. Will give it another go.

Edit: Framework 13 Intel i5-1340P hardware for reference.


Don’t forget that the GRUB config location is definitely different on 4.2. I looked for the purposes of this guide where it is, but I did not find it.

I have not tried the fingerprint reader. I’m not even sure where to configure that in Qubes.

100%, it was the screen tearing. I went through the installation process many times and the screen tearing did not happen on each attempt, but it went away immediately, every time when I followed the steps above. Now, it runs fantastically. I will not recommend 4.2 to anyone at the moment, as it is unreleased, and on a ThinkPad I tested on, the OS froze randomly all the time for absolutely no reason, even on the disk encryption screen sometimes. Therefore, I am staying away from it until they can claim it to be “stable.” Which, 4.1 didn’t fit that description until 4.1.2 in my own testing.

I’ll update the thread when I get a chance to try it.

It seems you could either use it with the fingerprint app directly in the sys-usb service VM or pass the device through to a different VM where the fingerprint app would be authenticating you, possibly the vault VM. From what I saw you can use the fprint app, but haven’t seen any methods on getting it working with Qubes for dom0 authentication so far.

I know that the RC4.2 version is a release candidate but I haven’t had issues with it other than the suspend/resume. At least the screen tearing was fixed with the more recent kernel version starting immediately with the installer. I’ve had no issues with the disk encryption or the OS freezing. But the great thing about it being a RC version is you can help the devs get to a stable release by contributing. I’ll be submitting my HCL soon with notes after I’ve tried more things.

Wanted to drop an update. I followed almost all of the same steps except for the Qubes RC4.2 GRUB config. Instead of your line for the grub2-mkconfig I used this:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo dracut -f

Per the Qubes documentation here to reference the updated location:


After this I rebooted. It looks like the three fixes are working from my testing:

  • Suspend/resume works by hitting the framework power button, selecting suspend, hitting the button again and it resumes flawlessly. I can also now close the lid, and reopen it successfully whereas before it would never resume properly.
  • The brightness keys now work, I can brighten or darken successfully.
  • I noticed the power consumption and fans are not struggling as much to keep cool. It seems as though the CPU and battery are under less thermal load and generally seems to perform more efficiently already under the same workloads.

I was definitely on edge during the reboot hoping that I didn’t totally ruin my GRUB config but it is working great for these three fixes. Thanks!!!

Edit: Oh I did notice one other thing, I do not see any file corresponding to /etc/proc/, what file specifically are you catting there? I reviewed the dmesg to see that the lines were read in from the Kernel command line on boot. Not sure where else to check but the testing shows positive results for all three fixes.

1 Like