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?
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?
It depends on your threat model. If it’s disposable, it’s reset every reboot, so you have to, e.g., enter your WiFi password every time. If there was any malware, it should disappear, too.
It’s Fedora-34-dvm by default (if you choose disposable sys-net during the installation). You can also configure it manually: Disposable customization | Qubes OS
You choose it during the installation. Some people may not expect or like that their passwords are not saved.
I’m using 4.1 for a long period of time on L14 and for what I’m using it is working ok [for the moment most of the time just browsing and coding from time to time] …
Could you please share the HCL report? If two people confirm that everything (including suspend) works fine, the machine will be included into Community-recommended computers.
Yeah, that was my mistake, usually apps store some config files or cache that may be corrupted. Don’t know where cheese stores those if at all. I have quickly tested video on Debian 11 based App Qube and with 4000MB RAM and 4 VCPUs it worked fine, no crashes.
So, I was considering to do what you had done because I do not live in the US and the price for the Librem 14 is great compared to similarly spec’d notebooks in my region, but the import taxes is where you get screwed.
I inquired about the hardware because I had multiple concerns. First and foremost was that if I would need more ram as the OS is ram intensive. They do have specific ram manufacturers, models, speeds, and types. Even though in theory the RAM you have should work, maybe this is actually the case. It is worth reaching out and asking Purism support to clarify.
In my communication with them, they did not specify either way, but Linux is picky on hardware alone and we are talking about a less mature OS than Ubuntu…
I appoligize for not returning to this thread sooner.
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.
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.
See my response in the next section of this comment for my perferred solution to this problem, which involves a disposable sys-net.
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.
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:
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.
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.
I suspect that you may be able to solve this without a disposable VM (randomization issue aside as that doesn’t improve my chances of helping you but you are quite welcome to work on tackling this anyway that you like) - where @concerned saw some light in the dark, I would recommend placing the MAC of the device in the field in network manager (where @concerned saw wls6 or wls7) & not the device name (wls6 & wls7 & wlswhatever will always resolve down to the MAC assigned to the device by the manufacturer - which is why randomization murkies the water when talking about this).
Actually, although I know in advance that this will not do any good at all, this is much further a field than merely Qubes (I’ve seen this sort of issue on Manjaro on their support forums for one it simply can be very difficult to parse the language used to identify the issue). But I know, I may be incorrect.
FWIW, I’ve been using a configuration with the MAC in the Device field instead of the device name, and I have not had any issues so far. Will get back if I do, but this looks like a potential solution.
I got Cheese working today without changing anything. I set my memory and VCPU back to defaults a while back, so this isn’t the issue. I’m still not sure what caused the issue and why it was so persistent (survived several reboots).
At first, I thought this had something to do with booting up the device without the camera/microphone powered on (Librem 14 has a physical killswitch that I normally have off), but I just tested this and even this doesn’t replicate the issue I was having.
@dom0 Thank you for the detailed info. Replacing the device name in the Device field with its MAC address seems to fix this issue. I have done several restarts and a few system updates without the connection breaking like before.
Regarding the disposable sys-net, this is very interesting. I will have to look into this more when I have more time.
Over the past week or so, my Qubes 4.1.0 installation has been relatively stable. However, just a few minutes ago, the OS froze/crashed on me (everything in the GUI is locked up, including mouse cursor).
I have seen a few reports of users stating that v4.1 works “flawlessly” on their Librem 14, but I don’t see how that could be. I installed the OS from a verified ISO, using the Qubes instructions, and I’ve made ~0 configurations to the OS, yet the OS continues to freeze on me for no apparent reason. In this particular case, all I did was:
Boot up and sign in
Open terminal in a fedora-34 AppVM
Open terminal in a debian-11 AppVM
A few minutes later (I was reading something on my other PC), I noticed the OS froze on me. There were no updates being applied, I wasn’t running any other applications, and there is nothing plugged into the PC (not even the power adapter). I can’t imagine that I am the only one experiencing this, nor do I believe that this is the result of anything that I’ve done to the OS (which again is almost nothing).
Does anyone have any recommendations? Has anyone else experienced OS freezes? How concerned should I be about file system damage as a result of needing to force a shutdown when this happens?
Suggestion, order the minimal configuration = smallest price = lowest tax and order your RAM and storage locally. Purism has made two nice movies which shows the disassembly and assembly. Repairing Librem 14 Part 1: RAM/WiFi/Storage/Battery – Purism
For the storage, I have no experience but it should also work fine with all mainstream M2 SSD. Also, on the linked picture you can see that Pursim equips the Librem 14 with a Samsung storage but some reported issues with Trim on Samsung I cannot share any feedback on this but I can say crucial storage works fine for me too.
) i.e. Crucial RAM 64GB Kit (2x32GB) DDR4 2666 MHz