Guide to installing Qubes on System76 Darter Pro

86 views
Skip to first unread message

olive...@gmail.com

unread,
Jul 21, 2020, 1:46:40 PM7/21/20
to qubes-users
Hi,

I thought it would be useful to others out there to share my experience in getting Qubes R4.0.3 up and running on a System76 Darter Pro (darp6) laptop. The installation worked seamlessly, but quite a lot of work was needed to get Qubes fully functional.

1) Replace the wifi card

The installed wifi card (Intel Wireless-AC 9560) does not work with Qubes R4.0.3 + Xen 4.13.1 due to some sort of Xen/Qubes bug, see this thread. Buy an Intel Wireless-AC 9260 card and install it following the instructions in the system76 Darter Pro manual.

Instead of buying a new Wifi card, you can try applying the patch outlined in the thread linked to above and compiling your own kernel, but I have not tried that. I unsuccessfully tried newer kernels and multiple iwlwifi firmware versions, and in the end just bought a new wifi card

2) Ethernet no-strict-reset

The sys-net Qube will fail on start ("Unable to reset PCI device"). In Qube Manager, under sys-net settings, go to the Devices tab, and Configure strict reset for PCI devices. Then apply the no-strict-reset policy to 26:00.1 Ethernet Controller Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller.

3) Upgrade the dom0 kernel to enable keyboard function keys

The system76 keyboard mappings (LED backlight control, etc) don't work with the default kernel (4.19.94). Now that you have internet access, install the latest stable kernel (5.6.16), which includes the system76 drivers, in dom0:

dom0$ sudo qubes-dom0-update kernel-latest

4) Use latest kernel for sys-net

While you're at it, install the latest stable VM kernel and configure the sys-net VM to use it.

dom0$ sudo qubes-dom0-update kernel-latest-qubes-vm

I'm not sure this is strictly necessary, but it works fine.

5) Make screen turn back on after suspend

At this point, the laptop will not recover after closing the lid and suspending it; when you open the lid, the laptop appears to leave the suspend mode (the LEDs on the front flash in the normal operating pattern), but the screen remains blank and you are forced to turn the laptop off by holding the power button. This is caused by the Thunderbolt port, for some reason. You need to remove the thunderbolt module from dom0 before suspend and reload it after resuming.

In theory, you should be able to do this by creating a file in /lib/systemd/system-sleep.

dom0$ sudo vim /lib/systemd/system-sleep/thunderbolt.sleep

  #!/bin/sh
  if [ "${1}" == "pre" ]; then
    sudo rmmod thunderbolt
  elif [ "${1}" == "post" ]; then
    sudo modprobe thunderbolt
  fi


dom0$ sudo chmod +x thunderbolt.sleep

I find this to be unreliable, however -- sometimes it isn't called. Instead, I rmmod thunderbolt in dom0 after booting the laptop, and then only load it when needed. Any suggestions for a better way of doing this?

6) Make wifi come back after suspend

To make the wifi connection come back after suspend / resume, add iwlmvm and iwlwifi (on separate lines) to /rw/config/suspend-module-blacklist in the sys-net vm. This will remove the modules from the kernel before suspend, and reload them after restore.

I haven't tested bluetooth or the built-in microphone and camera. Feel free to chime in if you have this laptop or have any suggestions.

Oliver

Oliver

unread,
Jul 23, 2020, 7:22:20 AM7/23/20
to qubes...@googlegroups.com

If you want to automatically remove and reload a module on suspend/resume in an appVM, you should add them to  /rw/config/suspend-module-blacklist

Is there a mechanism for doing the same thing in dom0? I have tried creating an appropriate script in /lib/systemd/system-sleep, but it is frustratingly inconsistent.

80% of the time it behaves as expected - the offending module is unloaded before suspend and reloaded after resuming - but the rest of the time it either does not unload it pre-suspend, or does not reload it after resuming.

Oliver


Oliver

unread,
Jul 24, 2020, 6:47:20 AM7/24/20
to qubes...@googlegroups.com
The solution outlined in step 5 above actually works fine -- the
inconsistent results were because I'd failed to remove an earlier
unsuccessful approach that sometimes interfered with the script.


Reply all
Reply to author
Forward
0 new messages