Purism Librem 14 v1

I will make a more thorough post about this and some may not be 4.1 specific but for Purism Librem 14:

  • constant charging/discharging alerts/notifications when computer into power (and yes i have followed all the instructions on forums for fixing this on 4.0 - the only workaround is to completely disable power notifications in dom0)

  • wifi radio is missing when resume from standby

  • 3.5mm does not work


for some reason occasionally on startup sys-net and sys-firewall does not run and requires manual start …this i noticed started with rc4.

Many people on Purism forums say that their Librem 14 with Qubes works flawlessly. I guess you should ask there and troubleshoot your problems.

Could you also upload the HCL report for Qubes 4.1?

For charging and discharging behavior make sure you have latest EC firmware installed on the laptop and librem-ec-acpi-dkms installed in dom0. Then you can even change start/stop charging thresholds.

For wifi after wake up you probably need add correct modules in sys-net /rw/config/suspend-module-blacklist
I’m not sure which exactly, but some of these (Others, what modules work best for you?):


For audio jack make sure you have installed lastest corebot or pureboot firmware. Automatic switching when you plugin headphones does not work (hopefully in in future releases of firmware), so you have to manually change Output device in audio mixer.


done this and the problem persists. this is for 4.1 it may work for 4.0.

On 4.1 it does not work is all i can say i have tested it thoroughly

i will check it out

Also I need to add to the list working an external monitor over the single USB-C PD port on Librem 14 does not work. Only HDMI.

Everything i wrote was about 4.1.

I ended up with only ath9k in suspend-module-blacklist.

Would you be able to submit the HCL report here? It should help us to update the list of recommended laptops.



  • Wi-Fi
  • Ethernet
  • MicroSD-card reader
  • Webcam
  • Microphones
  • Speakers
  • Touchpad
  • All USB ports
  • Headphone jack (requires that you manually change it as output, no microphone input)
  • Suspend (not tested thoroughly)
  • Brightness and Volume keys
  • HDMI port

Not tested

  • Bluetooth
  • Hibernation

Recommended tweaks
Installing librem-ec-acpi-dkms kernel module
EQ profile for speakers (PulseEffects)
Automatic script for Wi-Fi killswitch
Ensuring that the kernel module xen-acpi-processor is loaded
Enabling Trim


Qubes-HCL-Purism-librem_14-20220308-192518.yml (847 Bytes)


So microphone input does not work for you either?

What about external display over USB-C (the right hand side usb-c port)

Microphone input via headphone jack is not yet implemented and is an upcoming feature that will be provided via firmware update.

DP over USB-C on the other hand is bit more tricky and the reason that I didn’t mention it at all is because it depends on the devices that you own (in this case most likely; a USB-C monitor, hub or dock).
What I can tell is that if your current monitor/dock/hub works with Librem 14 in Linux distros such as Ubuntu or Fedora it will also work with Qubes OS.
My Dell monitor DP over USB-C works on the right side USB-C port as intended, delivering power (USB PD) and getting an image but I have had issues with USB-C docks. This is most likely caused by the Librem 14’s USB chip that handles protocols like DP over USB-C as other laptops I have had did not have issues.

1 Like

Which version of Qubes did you install in the Librem 14?
Which version of the EC firmware are you using? (use sudo purism_ectool info to get the EC version and see this post to upgrade)

Qubes OS 4.1. I’m using the latest stable EC firmware (Librem-EC v1.5 (2021-10-28_5fdd1e51)).

Try to follow these instructions but I stuck at

sudo dkms build librem_ec_acpi/1.0

it returns

Error! echo
Your kernel headers for kernel 5.10.90-1.fc.32.qubes.x86_64 cannot be found at
/lib/modules/5.10.90-1.fc32.qubes.x86_64/build or /lib/modules/5.10.90-1.fc32.qubes.x86_64/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.

Did you @bungali face the same issue?

How would the --kernelsourcedir command look like?

I did not face this issue, but I would recommend updating dom0 as newest stable kernel is 5.10.96. Rebooting might also help.

Ok, thanks I will try to upgrade the dom0 kernel.

My Wifi doesn’t work in any condition (switched on before boot…) I guess it requires this dkms tweak first. Can you confirm?

WiFi should work without any tweaks as long as you add the WiFi card to sys-net devices.

  • updated kernel to latest version 5.10.96-1.fc32 (had to do a “Enable updates for qubes without known available updates” ?!, anyways)

followed your the recommended tweaks

  • dkms installation done and verified

  • automatic script for wi-fi killswitch: Here, when I check the systemctl status killswitch.service it returns:

killswitch.service - Killswitch fix for L14
Loaded: bad-setting (Reason: Unit killswitch.service has a bad unit file setting.)
Active: inactive (dead)
... ... dom0 systemd[1]: killswitch.service: killswitch.service: Cannot add dependency job, ignoring: Unit killswitch.service has a bad unit file setting.
... ... dom0 systemd[1]: /etc/systemd/system/killswitch.service:7: Unbalanced quoting, ignoring: "usr/bin/sh -c '\"
... ... dom0 systemd[1]: killswitch.service: Unit configuration has fatal error, unit will not be started.

I have already reboot my notebook two times with wi-fi on.

I made following observation:
My wi-fi light is currently off even if it is switched to the right position. It is on during boot but when QOS is booted it is off.
My sys-usb is displaying a usb-device(!) when the wi-fi killswitch is switch on:
sys-usb:2-3 - 13d3_3487
When I switch off the wi-fi killswitch this usb device disappears (pop up notification: device removed). So, it is somehow seen as USB device not as wi-fi.

When I do a qvm-pci it shows me the

dom0:01_00.0    Network controller: Qualcom Atheros AR9462 Wireless Network Adapter

Any suggestion to fix my wi-fi issue?

1 Like

status update:

I did a manual pass-through How to use PCI devices | Qubes OS and a reboot. Now, wi-fi connection works even after reboot but two issues remain:

  • when doing a wi-fi killswitch off and one again (when everything is booted) wi-fi do not recover.

  • wi-fi LED light is always off right after LUKS decryption / QOS booting

… keep you posted.

Librem 14 actually removes power completely from the Wi-Fi card when killswitch is in off position and this is why Wi-Fi killswitch needs to be on when Qubes OS is booting as boot phase is when PCIe devices are detected by Qubes OS. If you switch the killswitch to off position after boot you need to reboot to enable Wi-Fi again.
Wi-Fi LED is on when there is traffic not when its “on” and receiving power.

The automatic killswitch script only detects if the Wi-Fi card is present during boot and attaches it to sys-net if it is. If Wi-Fi card is not present, script detaches it from sys-net, this occurs only when Wi-Fi card is already assigned to sys-net.
You may want to add more lines like Before=qubes-vm@sys-net.service for other VM’s that may start during boot and require sys-net (such as sys-firewall).

1 Like

You may have type error in the script, output should look like:

● killswitch.service - Killswitch fix for L14
     Loaded: loaded (/etc/systemd/system/killswitch.service; enabled; vendor preset: disabled)
     Active: inactive (dead) since Sat 2022-03-12 12:26:55 EET; 24min ago
    Process: 2509 ExecStart=/usr/bin/sh -c  if qvm-pci | grep -q dom0:01_00.0 ; then      qvm-pci attach sys-net dom0:01_00.0 --persistent || true ; else      qvm-pci detach sys-net dom0:01_00.0 || true ; fi (code=exited, status=0/SUCCESS)
   Main PID: 2509 (code=exited, status=0/SUCCESS)
        CPU: 223ms

Mar 12 12:26:46 dom0 systemd[1]: Starting Killswitch fix for L14...
Mar 12 12:26:55 dom0 sh[4870]: 'device 01_00.0 of class pci not attached to sys-net'
Mar 12 12:26:55 dom0 systemd[1]: killswitch.service: Succeeded.
Mar 12 12:26:55 dom0 systemd[1]: Finished Killswitch fix for L14.

Qubes-HCL-Purism-librem_14-20220312-173555.yml (847 Bytes)
Here is my HCL report