Purism Librem 14 v1

[Sven]

	Purism Librem 14 v1
Recommended CPU	i7-10710U
Display	14" fullHD
Max. memory	64GB (2 slots)
USB controllers	1
Coreboot	yes
Heads	optional
Intel ME	disabled
Qubes OS pre-installed	optional
Developer tested	no
Certified	no
Optional	Anti-interdiction, HW key
HCL reports	4xR4.0, 3xR4.1

History

Date	Author	Change
5/26/22	@fsflover	updated link to Qubes preinstalled option. New link. Old link.
3/15/22	@fsflover	updated link to the HCL reports
9/1/21	@fsflover	added link to the HCL reports
9/1/21	@Sven	renamed “additional” to “optional” as those features need to be explicitly ordered and are not included by default; added this history table
8/31/21	@fsflover	added display/resolution, additional features and renamed me_cleaner to “Intel ME” and changed value to “disabled”
8/23/21	@Sven	initial version

[dom0]

Edit by @fsflover: This is a report for Qubes 4.0. For the latest version see below.

---

Remarks

I made a lengthy review and comparison post on the Purism forums here, and please keep in mind that I have only been using Qubes for a few years and am not an expert.

When I received my Librem 14, I verified that everything worked out of the box running the preinstalled OS (PureOS) on the preinstalled SSD. I then removed that SSD and installed my 1TB NVME SSD with Qubes 4.0 that I had been using on my Librem 13 for the past few years. I can confirm that everything worked without needing any additional configuration.

There is only one thing that did not work as intended, both on Qubes and on PureOS. I have it set to switch off the display when the laptop lid is closed, but the display does not actually switch off. This is solved by manually lowering the display brightness to zero using the keyboard key before closing the laptop lid and then manually raising the display brightness after opening the laptop lid.

So I would say that, Yes, Qubes worked out of the box on my Librem 14v1 without the need for any configuration.

Confirmed Working:

• coreboot

• Wifi (2.4 GHz and 5 GHz networks)

• Ethernet

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

• microSD Card Slot

• All USB ports (data transfer)

• USB-C port (power dilivery - only supported on the right side port by design)

• WebCam and Indicator Light

• Microphone (both internal microphones)

• Killswitch for WebCam/Microphone (and indicator light)

• Killswitch for Wifi/Bluetooth (Wifi/Bluetooth must be powered on while booting Qubes in order for the device to be recognized by Qubes, and it must be powered on in order for sys-net to startup with it attached. Removing the device from sys-net allows the device to be powered down by the killswitch and ethernet used in its place.)

Some more detail about the Wifi/Bluetooth killswitch when booting up Qubes:

The Wifi/Bluetooth device can be disabled by the killswitch during boot but must be enabled at two certain moments. After the Qubes grub menu disappears and the display goes black, there is a delay of a few seconds before the keyboard backlight turns off and then a shorter delay beore the Qubes luks decrypt screen appears. The Wifi/Bluetooth device must be enabled before the keyboard backlight turns off. Then the Wifi/Bluetooth device can be disabled again. After typing the correct Qubes luks decrypt password and hitting the “Enter” key, the Wifi/Bluetooth module must again be enabled for a few seconds until the Qubes luks decrypt process finishes and the user account login screen appears.

I do not know if this is actually useful information, but I was curious about this and decided to just play around and see if I could find when the device needed to be recognized. I was not expecting two separate moments though, so that was interesting.

This laptop is such a joy to use, especially with 64 GB of RAM and an NVME SSD.

Hopefully this is a good enough post for an HCL report here.

Attachments

Qubes-HCL-Purism-Librem_14-20210807-223750.yml (833 Bytes)

[Sven]

Thank you @dom0 for your detailed HCL report which is now part of this pull request and will be visible on the website soon!

Since this was the second positive report for the Purism Librem 14, it is now also added on the very top of the “just works” list.

[fsflover]

@dom0

Some more detail about the Wifi/Bluetooth killswitch when booting up Qubes:

See also: Qubes fails to start sys-net if wifi kill switch is off - Other OSes - Purism community.

[dallas87]

Librem 14v1
Qubes-HCL-Purism-librem_14-20210816-094413.yml (832 Bytes)

[Sven]

Thank you @dallas87 for your HCL report, which is now part of this pull request and will be visible on the website soon! Once it is, I will also link it from the “just works” page.

[hanabi]

Remarks

Best Qubes laptop I’ve ever had.

10th generation Intel CPU with IOMMU, SLAT, VT-X,VT-D and all the other Qubes stuff that most modern laptops usually lack one off.

Purism laptops come with an optional Pureboot bundle which uses Heads to verify a root of trust though an external Librem Key.
Works in a very similar way to a normal Qubes Anti Evil Maid setup.

Should be equal to or very close to the trust you can derive from a normal AEM setup.
(please shout at me in the comments below if I’m wrong)

What’s tested and confirmed working

• Pureboot bundle (Anti Evil Maid replacement)

• Wi-Fi (no strict PCI reset option needs to be enabled)

• Ethernet (no strict PCI reset option needs to be enabled)

• 3.5mm sound jack works.
  Sound doesn’t automatically switch over though when plugging
  earphones in etc. Probably just a tweak somewhere to be added.

• System Suspend and recovery works.
  No Wi-Fi issues.

• USB-C connectivity works

• USB-C => Ethernet

• USB-C => HDMI

• USB-C => USB splitting

• Webcam

• Mic

• Kill switches for Wi-Fi/Ethernet
  The VM needs to reboot to recognise the Wi-Fi/Ethernet device again after the kill switch is reversed.
  The solution to this should be a similar to the fix for Wi-Fi disappearing after suspending the system which was common on other qubes systems I’ve had.

• Kill switches for Webcam/Mic
  Works as intended the device disappears and reapers when the kill switch is disengaged again.

What’s not tested:

• Bluetooth (should work, just don’t like non free drivers)

• Hibernation
  Have 40Gb of ram in this laptop but a smaller SSD so opted out of having a swap partition.
  Don’t think hibernation can work without it.

Attachments

---
layout:
  'hcl'
type:
  'laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  ''
remap:
  'yes'
brand: |
  Purism
model: |
  librem_14
bios: |
  PureBoot-Release-17.1
cpu: |
  Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:9b51]
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Device [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: |
  40834
scsi: |

usb: |
  1
versions:

- works:
    yes
  qubes: |
    R4.0
  xen: |
    4.8.5-32.fc25
  kernel: |
    5.4.107-1
  remark: |
    FIXME
  credit: |
    FIXAUTHOR
  link: |
    FIXLINK
---

[fsflover]

@hanabi

Bluetooth (should work, just don’t like non free drivers)

Not really supported in Qubes OS yet: Qubes Architecture Next Steps: The GUI Domain | Qubes OS.

@hanabi

Hibernation

Same as above: https://github.com/QubesOS/qubes-issues/issues/2273 and https://github.com/QubesOS/qubes-issues/issues/2414.

[Sven]

Thank you @hanabi for your HCL report, which is now part of this pull request and will be visible on the website soon!

[leaningtrees]

I’ve been having a number of issues with my Librem 14 and Qubes.

1. xfce4-power-manager sometimes does not recognize plugging/unplugging the power adapter.

2. The battery sometimes decides to not charge. Even with the power adapter plugged in, the battery level will stay at 63%, for example.

3. The headphones do not work yet, but evidently there is a firmware update in the near future to fix this.

4. xfce4-power-manager sometimes does not recognize the lid is closed and does not suspend. I’ve been having to manually suspend before closing the lid.

5. After rebooting today, I currently cannot login to Qubes due to some sort of login loop. The OS boots to the login prompt after successfully decrypting the luks drive. Upon entering the incorrect password, the login fails with an appropriate error message. Upon entering the correct password, the login prompt just resets.

I think some more tweaks are required before calling this compatible out of the box.

[fsflover]

Are you talking about Qubes 4.0 or 4.1 here? Librem 14 is very new and 4.0 uses very old Fedora, so I would expect some problems.

@leaningtrees

After rebooting today, I currently cannot login to Qubes due to some sort of login loop. The OS boots to the login prompt after successfully decrypting the luks drive. Upon entering the incorrect password, the login fails with an appropriate error message. Upon entering the correct password, the login prompt just resets.

This looks like a possible bug. Perhaps you could create a separate thread for that and maybe someone can help here.

[leaningtrees]

4.0.

I’m still trying to debug the login issue, I’ll create a separate thread for it later today (edit: created login loop thread).

[toothless]

Did you try to run 4.1 instead 4.0 on Librem?

[hanabi]

@leaningtrees Thats strange.

Looks like we both have 4.0 according to my ACL above and I have none of the problems above.

I run the i3 desktop manager which switches out some xfce tools for their own like xfce4-power-manager.
So you might have some xfce troubles since I only booted that long enough to install i3 on log into that.

I’ll play around with xfce instead of i3 today and see if i can replicate some of your issues @leaningtrees.

[hanabi]

@fsflover Bluetooth works fine =)

Did a quick test with bluetooth and got it working:

1. dnf install blueman in the base template for your media VM that needs bluetooth.
2. restart VM and base image.
3. run lsusb in sys-usb and look for the bluetooth device hash. mine was 04ca:xxxx
   the device had bluetooth in its name.
   this assumes that the bluetooth device got assigned to sys-usb with the other peripherals during installation. If you clicked “use sys-usb for usb devices” during setup bluetooth should be here.
4. then just assign that USB device in the USB applet to your Media vm
5. the blueman applet starts automatically in media VM and detects bluetooth automatically on device assignment.
6. Open blueman applet Pair, connect and listen away on your bluetooth speakers.

Did I misunderstand what you meant by not really supported?

[fsflover]

Yes, you can make Bluetooth work in 4.0. However, AFAIK it won’t be secure to use it for audio, because PulseAudio is not isolated from dom0. I don’t know the technical details, I have only read the link I provided. One more link:

AudioVM outside of dom0

[hanabi]

Thanks @fsflover learnt something new today =)

[hanabi]

I logged into the default desktop manager XFCE instead of i3 that i use to see if I could replicate your issues.
Note, that i only repeated each point a few times, not extended use over a day etc.

xfce4-power-manager sometimes does not recognize plugging/unplugging the power adapter.

it correctly detected that i pulled the power plug and detected the insertion later on and charged to maximum and then stopped.
Repeated a few times with at coffee break in between.

The battery sometimes decides to not charge. Even with the power adapter plugged in, the battery level will stay at 63%, for example.

I couldn’t replicate this unfortunately.

xfce4-power-manager sometimes does not recognize the lid is closed and does not suspend. I’ve been having to manually suspend before closing the lid.

This worked for me a few times in a row. Once it took 7sec before powering down but it worked nonetheless.

The headphones do not work yet, but evidently there is a firmware update in the near future to fix this.

This bug we both share, it doesn’t automatically detect the headphones inserted into the jack so you have go click the sound applet icon and switch the external output to the headphones.
Then everything works, annoying though.

After rebooting today, I currently cannot login to Qubes due to some sort of login loop. The OS boots to the login prompt after successfully decrypting the luks drive. Upon entering the incorrect password, the login fails with an appropriate error message. Upon entering the correct password, the login prompt just resets.

Not sure how I can test this, according to the HCL I posted and the Qubes version you posted we should be running the same Qubes version on the same laptop.
Strange that we have two completely different experiences =/
The silicone lottery shouldn’t matter this much…

Hope you get it working @leaningtrees!

[leaningtrees]

Thanks for checking hanabi.

I was able to get suspend on lid close working - I had to uncomment the following line from /etc/systemd/logind.conf:

HandleLidSwitch=suspend

as the default xfce4-power-manager setting of logind-handle-lid-switch is defaulted to true.

I am still seeing really erratic behavior with the power manager upon un/plugging the power adapter in. Sometimes it detects it, other times it does not. I’ve also noticed that sometimes some of the function keys stop working with xfce4-power-manager - brightness buttons don’t do anything. Other times they work fine. For example, right now I have the power cable plugged in but the xfce4-power-manager applet, upower -d, and cat /sys/class/power_supply/BAT0/status all show Discharging, and the Fn+F5 or Fn+F6 buttons to change the screen brightness do nothing. Not sure if this is a problem in the firmware - certainly doesn’t seem like a problem with Qubes at all. I added a comment to this Purism thread.

The headphone jack has a partial fix coming in the next firmware release according to this Purism forum post, though it sounds like automatic switching to headphones and the microphone (audio input) is still a work in progress.

The login loop was of my own doing - I updated the other thread I created (user’s shell did not exist).

[leaningtrees]

Another update: I noticed that the weird suspend on lid close and power manager behavior mentioned above was only occuring after the first suspend after booting. The Librem’s embedded controller was getting into a weird state with ACPI events that caused certain functions (keyboard screen brightness keys, suspend on lid close, un/plug power events, etc.) to stop working. Installing the librem-ec-acpi DKMS driver manually in dom0 resolved all of my problems. It would be nice if this driver made it to the upstream kernel.

See my two comments on the Purism forums for more information:

symptoms described in Purism forum post

solution and how to get DKMS driver installed