Qubes fails to start sys-net if wifi kill switch is off

Software Qubes OS
1

Hi,

I am using Qubes 4.1 on my Librem 14, and if I start my system with the network kill switch off, sys-net will fail to start because the wifi device is not found, and then it freezes and I have to reboot the system with the kill switch on, only to turn it off as soon as sys-net loads.

A trivial way to solve this would be to just remove the assigned wifi device from sys-net, however that is not ideal because then I would have to manually add it every time I wanted to use the wifi.

Does anyone know a way around this?

Thanks

2

Can switch it on while booting and then switch back off?

See also: https://forum.qubes-os.org/t/hcl-report-for-librem-14-v1/5585

3

this seem to be the same issue that was reported here:

Librem 14 Qubes Users: Which device is for Wifi?

4

That is what I am doing at the moment, but I don’t really like this solution since it leaves my wifi card slightly more exposed than I would like it to be (not a huge problem with Qubes), but mainly because I have to be mindful of turning it on and off again to boot or to restart sys-net.

Thanks. So I guess this is a Qubes problem, I wonder how hard it would be to implement the graceful handling of a PCIe disappearance.

5

By the way, I don’t have such problem on my Librem 15 with Qubes. AFAIK, Purism is upstreaming all their patches and at some point it should just work for you, too. Perhaps there is a way to patch it yourself, but I have no idea how.

6

That’s why

It doesn’t make sense to upstream the patches, since PureOS and other Purism software is not downstream from Qubes, I don’t believe Purism is actively working on this.

However, given that they want to advertise L14 as the best Qubes laptop, I think they should look into fixing these small problems.

7

But it is. Net-vm is using a Linux kernel, which Purism upstreams to.

8

The problem is not in the sys-net kernel, the problem lies with Qubes code that loads the VM and assigns the devices to it. More specifically, I believe the problem lies in one of these two Qubes files: qubes-core-admin/qubes/vm/__init__.py and qubes-core-admin/qubes/devices.py

1 Like
9

only for the Librem 5, so the statement is true in the context of Librem laptops

1 Like
10

I’m happy to report that I found a workaround for this issue. Basically, I wrote a service that is executed at startup before sys-net that tries to determine if the wifi card is plugged in at boot, and attaches or detaches it from sys-net accordingly.

Note that with this solution, if the kill switch is off (wifi disabled) at boot, then you won’t be able to use the wifi unless you reboot with the kill switch on, since Qubes won’t ever load the PCI device. However, you can still use bluetooth if you turn the kill switch on.

Instructions:
Create a file named /etc/systemd/system/killswitch.service and write into it:

[Unit]
Description=Killswitch fix for L14
After=qubesd.service
Before=qubes-vm@sys-net.service

[Service]
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'
Type=oneshot
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

(note that the PCI device name in your machine might change, but I doubt that. In any case, you can quickly find the device name running qvm-pci)

Then, run this command to enable the service you just created:

systemctl enable killswitch.service

That’s it!

2 Likes