Purism Librem 14 v1

User Support HCL Reports
54

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

55

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?

56

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

57
  • 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
58

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.

59

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
60

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

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

2 Likes
62

Thank you @dallas87 for your HCL report, which is online now.

1 Like
63

Thank you @bungali for your HCL report, which is online now.

1 Like
64

From the posts in this thread, I see the following issues reported with R4.1 (maybe even in general)

This does NOT sound to me like the criteria “Graphics, networking, audio & suspend work without troubleshooting” is fulfilled. Are these all new issues with R4.1 or were those issues also present in R4.0?

65

I cannot comment on R4.0 vs. R4.1 but for R4.1:

  • Graphics: Only a kind of graphical delay when entering the LUKS password and the terminal looks a bit weird during LUKS boot. I do not see it critical but yes purism should get it fixed.

  • Networking: Only the hardware killswitch on/off requires a tweak¹. I also would not define it as critical since I guess if you would perform the same action with an external wifi hardware (unmount & mount) you will face the same issue. tbd

  • Audio: Works without any issue on my device. But I did not make a detailed audio performance check. Volume control works and the sound is clear.

  • Suspend (to RAM): Maybe this could depend on the active GB you send to your available RAM. I had no issues. Sleep and weak up worked.

¹ I still could not fix it but others did it with a pci reconnection script.

2 Likes
66

Thank you @whoami, I will restore the Purism Librem 14 v1 to the community recommended list then.

1 Like
67

Remarks

Everything that was working on QubesOS R4.0 is working on QubesOS R4.1, and I am loving the update! I love that the Qui-Domains application now includes the option to open a file manager in any running qube. I love the new qube icons and the visual direction that QubesOS is going. And I love the immense speed improvements that I am experiencing (though that could be in part due to installing QubesOS R4.1 on a newer, faster, and larger SSD and leaving more empty space available on it). Where qubes would take up to 12 seconds to boot on my previous R4.0 installation on my older drive, qubes now boot in 3 to 5 seconds, and my Qubes Manager takes 1 to 2 seconds to load as opposed to the 30 seconds or more on my previous installation.

The only issue that I have seen is that there are visual glitches of the mouse cursor when moving it across a button or other item that causes the cursor to change appearance (such as the border of a window, in which the regular mouse cursor arrow becomes a window resize arrow). And there are also some visual glitches that others have mentioned when on the Luks decryption screen.

However, I need to make a correction on my original post at the top of this thread. When I tested that the headphone jack worked, I made a Signal call. I could hear the person on the other end, and they could hear me, so I concluded that everything was working as expected. Well it seems that I was wrong. The headphones were being used for audio output, but the laptop microphones were being used for audio input. And I have now seen posts like this:

Sorry for the error everyone. @Sven, could you correct my original post to replace this:

  • 3.5mm Headphone Jack (Output and Input)

with this:

  • 3.5mm Headphone Jack (Output and Input) ← Correction

Thank you.

Attachments

Qubes-HCL-Purism-Librem_14-20220316-033600.yml (846 Bytes)

3 Likes
68

Thank you for your valuable contribution! I edited your post and also mentioned that the latest report is here.

1 Like
69

Thank you @dom0, your new report is online now!

2 Likes
70

I am thinking about buying a Librem 14 specifically for Qubes. I would like to use the Librem14 mostly between two locations in a kind of “docking station” setup where I connect preferably only a minimum number of cables. I would like to be able to keep my desktop with the open windows running when connecting to the external monitor + periphery (no reboot of the entire system). Does this work? I saw that the Librem 14 has a USB-C port that supports Display port. Does this work for hot swap? Does Power Delivery work together with the other USB-C features? What about Ethernet network and HID via USB-C?

Can anybody recommend a docking station that works w/ Librem 14 + Qubes? Preferable, it would have DisplayPort w/ MST to support 2 monitors (not strict on this, just nice to have), Ethernet, USB for HID and Power Delivery.

Peter

71
2 Likes
72

Remarks

Function buttons do not work after suspend.
No suspend on lid close.
Pureboot issues after any Qube Update.

layout:
‘hcl’
type:
‘laptop’
hvm:
‘yes’
iommu:
‘yes’
slat:
‘yes’
tpm:
‘’
remap:
‘yes’
brand: |
Purism
model: |
Librem 14
bios: |
4.16-8-gf88975265a
cpu: |
Intel(R) Core™ i7-10710U CPU @ 1.10GHz
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:9b51]
chipset-short: |
FIXME
gpu: |
Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])

gpu-short: |
FIXME
network: |
Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
65410
scsi: |

usb: |
1
versions:

  • works:
    ‘FIXME:yes|no|partial’
    qubes: |
    R4.1
    xen: |
    4.14.5
    kernel: |
    5.15.57-1
    remark: |
    FIXME
    credit: |
    FIXAUTHOR
    link: |
    FIXLINK
1 Like
73

Thank you @kenosen for this report, which is online now.

Can you please be a bit more descriptive – what do you see? …what do you expect?