Good advice, but in this particular case, the only change I had made was tweaking some basic Firefox settings (e.g. changing default search engine).
I let it go for ~20 minutes. It normally takes about 20-30 seconds to shut down, and none of my AppVMs were doing anything, so I’m pretty confident it was frozen.
I was literally just looking at the Qube Manager when I saw the notification in the top-right corner of the screen telling me that sys-whonix had shut down. I didn’t do anything to cause this, nor were any updates being installed, so it seems to me that it may have crashed.
In this case, I was watching the desktop as the OS was loading. The first thing I noticed was it stopped loading, but never loaded the network manager (or whatever it’s called). When I went to investigate, I realized the whole OS was frozen, even the mouse cursor, the keyboard wouldn’t work, etc. I don’t have any shortcuts or anything like that - my OS is 99.99% stock from the v4.1.0 install. I have only made very few tweaks like Firefox changes, installed system updates, changed the power settings such that closing the lid only turns off the monitor.
On the Initial Setup screen, I accepted all of the default options except that I also enabled “Enable system and template updates over the Tor anonymity network using Whonix”. I do have separate sys-net and sys-usb qubes, which furthers my confusion as to why plugging in a USB security key would pwn my Wi-Fi connection/configuration (and yes, I think it’s safe to assume my YubiKey isn’t malicious). All it really is as far as the OS is concerned is a USB keyboard AFAIK.
I get the learning curve, and am willing to undergo that, but I’m having a difficult time getting to the learning part with the erratic behavior (crashing, intermittent network issues, things failing when nothing is going on, etc.). It feels as though this OS has schizophrenia.
I used a separate USB 3 flash drive with a good track record and limited use so I could keep my Purism flash drive untouched for other debugging or experimentation if necessary.
Thanks for this. I normally delete the original configuration once the new one is working. I will have to try keeping both of them to see if this is a good workaround
I did give it camera access, but forgot to give it microphone access during my first video test. However, now I’m stuck because it seems to be corrupted and won’t let me do anything - not even take a picture like I was able to before I did the video test.
I was only touching the touchpad
Possibly. I think something was “denied”, but I will have to wait for it to happen again and take a screenshot.
When I encounter this, my password is not lost. In fact, I go into the configuration that the OS refuses to use, copy the password, then set up a new one with the password and the same settings and then the OS will connect with the new one. I’ve even taken screenshots of each tab in the connection settings to make sure that the “broken” one wasn’t altered, but it was not, so I have no idea what the issue is or how to force the OS to accept it and connect.
I will test it again, but yes, I acknowledge that waking up from suspend is usually flaky, even for some big names like Dell in some cases. I will have to test it some more.
Good call - I will test
Thanks. If it really is just a graphical issue in these limited cases, I won’t worry about it. Seeing these is just a little unnerving because it makes it appear as though a deeper problem is lurking beneath the surface.
I mostly just wanted to make sure I wasn’t the only one seeing this. I still don’t understand why a shutdown procedure would present the user with the login screen. In my case, this is usually only displayed for ~2 seconds before it switches to a black screen with several white squares in a grid in the upper-left corner of the screen (also interesting).
I will look into this, but I was hoping to be able to make minimal changes to the system out of concern that an accumulation of such changes might introduce other stability issues, security issues, or interference with future updates. Any thoughts on that? If this is a legitimate solution, I do wonder how it could still be open for over 3 years now - it sounds like something pretty serious that should take 5 minutes for the devs to fix.
When I encounter this, my password is not lost. In fact, I go into the configuration that the OS refuses to use, copy the password, then set up a new one with the password and the same settings and then the OS will connect with the new one. I’ve even taken screenshots of each tab in the connection settings to make sure that the “broken” one wasn’t altered, but it was not, so I have no idea what the issue is or how to force the OS to accept it and connect.
Maybe this could help: Did you happen to notice (plus did you happen to see around elsewhere in the forum - it has been mentioned before but it can be hard to search for) that the Network Manager entry has only the device name? This is a common issue, which is generally solved by editing to cause Network Manager configuration to have the MAC (and only the MAC usually) of the WiFi device. Since the device name is more fluid in Qubes than it is in Linux, the name will not be guaranteed but the MAC (unless you have already taken steps to randomize) will generally remain the same.
I have confirmed that neither of these directories exist (yes I caught that it’s .cache and .config), so I was unable to delete them. The app is stuck in this “There was an error playing video from the webcam.” Any other ideas?
I also doubled the memory (800 initial, 8000 max) and VCPUs (2 to 4), but it is still stuck in this error state.
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.