Endless Issues with Qubes 4.1.0, 4.0.4 on Librem 14v1

[dom0]

I appoligize for not returning to this thread sooner.

@concerned

When I look at the “Device” field in the “Wi-Fi” tab for this connection, it lists only the device (“wls7”). I should also mention that I’m using the “Cloned MAC address” field to specify/spoof the MAC because the router is using MAC filtering (not a fan of this, but it ain’t my router).

Perhaps you are onto something, though, because I do see in past screenshots that this was previously “wls6”, which I did not notice until now. Are you thinking I should replace the device name (in this case, “wls7”) with the adapter’s native MAC address?

This issue is not unique to QubesOS R4.1, as I currently have this issue on my QubesOS R4.0 install on my Librem 14v1. I had thought that this was an issue with my odd wireless network setup; I have two wireless access points, both set to broadcast the same two SSIDs (one for 2.4GHz network and one for 5GHz network) and use the same passwords for the SSIDs. I had thought that the “wls6” and “wls7” were somehow referring to the two wireless access points, but now that I see that this issue is affecting others, it seems like it is an issue with QubesOS or with the Librem 14v1.

There are two solutions for this issue that I see.

1. You can simply click the dropdown option and switch the selection from “wls6” to “wls7” or vice versa whenever it does not automatically connect. This will work 100% of the time. There is no need to delete the configuration or create another one.
2. See my response in the next section of this comment for my perferred solution to this problem, which involves a disposable sys-net.

@concerned

Should sys-net be disposable? If so:

1. Did you change its template to fedora-34-dvm?
2. Why would it not be disposable by default (i.e. at least in my installation, the template was set to “fedora-34”, not the dvm)?

1. As @fsflover said, you can configure sys-net and other service qubes to be disposable by default now, during initial setup of QubesOS R4.1, but they can also be configured this way manually using the instructions on the Disposable customization page. You can also choose Fedora or Debian, whichever you prefer.
2. Also, as @fsflover said, it depends on user preference. QubesOS is designed this way to make it easier for people to switch over to it. When sys-net is disposable, the user either has to manually enter wireless credentials each use (if using Wifi instead of ethernet), or the user must make custom configurations for their needs, which I will address below.

My solution for the odd sys-net behaviour has been to setup my sys-net to be disposable and to make a simple script that executes when I click a button in my panel. This script tells dom0 to send the Wifi password to the sys-net qube and send the command to it to connect to the Wifi network using the password that it was sent. I also decided to separate my sys-net into two qubes, one for ethernet and one for Wifi, and I made some scripts to quickly set the netvm of my sys-firewall to the sys-net (ethernet) or sys-wifi. This has also allowed me to use the Wifi killswitch whether I have network connected qubes running or not.

To try to keep this simple, below is the simple script to make my sys-wifi connect to one of my Wifi networks:

qvm-run -u root --pass-io sys-wifi 'echo "<PASSWORD>" > b' && sleep 3 && qvm-run -u root --pass-io sys-wifi 'nmcli device wifi connect <NETWORK_SSID> password "$(cat b)"' && rm b

To summarize this, dom0 is sending a command to the sys-wifi service qube. The command tells the sys-wifi to run it as root (because I setup my service qubes to be minimal and not have qubes-core-agent-passwordless-root installed). The command tells sys-wifi to make a text file, which I simply named b and to input the password into this text file. Then the next command is to connect to the Wifi SSID of your choice and use the text from the b file as the Wifi password. Finally, it deletes the b file once it has successfully connected to the Wifi network. Note that you must replace <PASSWORD> with the password for your SSID and replace <NETWORK_SSID> with the SSID of your network.

In general, I have grown to appreciate the concept of disposables very much. One can setup qubes to be as minimal as possible, making them quicker to startup and quicker to shutdown, and any oddities tend to be solved by simply rebooting the disposable.

I hope that this was not needlessly wordy, but I want anyone to be able to understand this if they stumble upon this thread. If anyone has any questions about my setup or wants to correct me on some error in my thinking here, please respond. I typically browse forums without signing in, but I will try to remember to check back here when I can.

@Sven

As of today there is not a single positive HCL report for the Librem 14v1 and Qubes OS R4.1

There are four positive reports for R4.0 by @dom0, @dallas87, @hanabi and MrChromebox: if you upgraded to R4.1 please share HCL reports. Do you see similar issues as the OP?

I have received my new SSD, and I will soon be installing QubesOS R4.1 on it and restoring a backup of my current QubesOS R4.0 installation. I need to set aside some time to do this, and then I will submit my HCL report after testing it out. Thank you again for maintaining the HCL for us.