I’ve been using QubesOS as my daily driver for 3 weeks now, running it on my main laptop and desktop PC. I didn’t really have a lot of issues with switching from Ubuntu to Qubes with Debian as the default.
I have made a couple of big errors, but nothing I couldn’t recover from using the backups.
Considering Qubes reputation of being extremely difficult to use I think it’s been surprisingly easy, but maybe the reputation was justified prior to 4.1.
Hello. I am not an expert, but I have been using Qubes for a few years now, first on a Librem 13 and now on a Librem 14. My responses to the issues below may or may not be useful.
I would recommend keeping modifications of templates to a minimal and maybe even having separate templates for different uses. For example, if you are installing software into a template, you could instead clone the template and install the software into the new template. This way your important system service qubes use a template that only receives updates while new software installations and configurations are kept in other TemplateVMs.
I think that I read here in the forum somewhere that suspend does not function properly in Qubes. So after installing Qubes a few years ago, one of the first things that I did was to disable the automatic power management features.
I think that this is because the TemplateVMs do not actually have network connectivity, by design. If you look in the Qubes Manager, the NetVM collumn should display “default (n/a)” for all of the TemplateVMs. I think that the default repos are trusted and can connect properly using a terminal or the Qubes Update Tool, but the software packages in TemplateVMs is not intended to be used. I could be wrong about this though.
I cannot help with this except to say that this is one example of how disposible vms can be useful.
I have not updated to Qubes R4.1 yet, so I cannot comment on this.
This seems to be another Qubes R4.1 issue that I cannot comment on yet.
This seems like the Qubes Manager might have issues in Qubes R4.1 that have not been resolved yet, though it could be something else.
How long was it stuck like that? Depending on how many vms you have running when you initiate a shutdown, it can take a while to shutdown properly. Each vm has to be shutdown before the system itself can shutdown. Even after I manually shutdown all vms, sometimes the system itself takes longer to shutdown on some occations.
That seems odd to me. Can you elaborate about this?
This is another odd one. Do you mean that you could see the panel and that not all items were there and nothing was clickable? Do you have any keyboard shortcuts to launch certain things, like a dom0 terminal, and did any keyboard shortcuts work?
Depending on the error message, this might be an issue that could be resolved on the whonix forums. Please take a screenshot the next time it happens. You can take a screenshot of a specific window using the following command in a dom0 terminal: xfce4-screenshooter -w
I have no experience with YubiKeys, but this is more odd than the other issues. When you initially installed Qubes R4.1, what settings did you choose? Did you choose to have a sys-usb qube or have your sys-net qube also manage your USB controller? Did you select to have any of your default service qubes be disposable?
I would say that there is a learning curve with Qubes, and everyone learns to see things a little differently in order to understand how to accomplish their tasks within it. However, the developers do seem to be working to make Qubes more user-friendly, and I cannot wait to update to Qubes R4.1 when my new SSD arrives.
I think I remember reading on this forum or the Purism forum that someone had issues using the flash drive they received from Purism. When I received my Librem 13, the flash drive that I ordered with it had QubesOS R3.2, and so I downloaded, verified, and installed QubesOS R4.0 installer onto it. So it might be that Purism has issues on their end. When you installed Qubes R4.1, did you use the same flash drive that Purism sent you, or did you use a different one?
I have been using a Samsung Evo 970 and am upgrading to the same one you are using. I would not expect that there are compatibility issues with the SSD or the RAM.
I think it is more to do with the learning curve with Qubes and how some people may have less time to devote to learning the OS or may have a harder time, based on their level of experience with linux.
To anyone that is new to Qubes and having issues, I recommend checking out the Qubes Tutorials playlist by Switched to Linux. The videos are old and demonstrate QubesOS R3.2, but the basic core principles should still apply. Also, there is plenty to read in the QubesOS documentation. I have been using the documentation and the forum to learn new things and apply new configurations to my setup over the past few years, and it is exciting how much QubesOS can do!
Suspend has been working flawlessly on my Librem 15 for years. Now on 4.1, sys-net is stuck every time the machine wakes up, I have to reboot the VM.
Qubes has been my daily driver for many years.
Thank you for the correction. Do you have sys-net set to auto-start? I disable auto-start for everything and manually start what I need when I need it. Maybe there is an issue with auto-start in R4.1? Do you use a disposable sys-net?
My sys-net is not set to auto-start, but other VMs depending on it (sys-firewall) are. However I don’t think it is relevant. When the machine wakes up from sleep, it’s not the same as booting. Everything is already started at this point.
Yes, I’m using a disposable sys-net.
First of all I would like to say that I have encountered some of these problems and will try to link you to the issue or offer a solution. I have been using Qubes OS a couple years as my only OS and over a year on L14 with a similar configuration as you. One thing you could do to rule out RAM fault is to run memtest86.
- Almost every time the fedora-34 template is modified, either by me or via system updates, this breaks my Wi-Fi configuration upon reboot. By “break”, I mean that the system won’t even attempt to connect to the network, even though the configuration is correct. My only fix for this is to delete the configuration and recreate it with all of the same data.
I have noticed that NetworkManager sometimes “loses” the password to saved Wi-Fi networks, this has happened since Fedora 32 or 33 if I remember correctly. Core of the issue seems to be around that NetworkManager stores some wireless configs in /etc/Networkmanager/system-connections/ which are not surviving reboots as sys-net is an App Qube. I might have fixed this by creating identical files to sys-net’s Template Qube under /etc/Networkmanager/system-connections/ but I’m not sure of that. Myself I have migrated to disp sys-net and use Wi-Fi rarely, so this is a non issue for me.
- I’ve encountered an issue similar to #1 after waking up from the suspend state
As @dom0 stated suspend and other sleep states have not been working properly for a lot of people. But that is almost always due to proprietary hardware and should not be the case for L14.
- The software manager in Fedora-34 appears to be useless because it appears to be under the impression that it has no internet connection ("Unable to contact “admin.fedoraproject.org”). I did see an open issue that seemed to describe this, but that was ~4 years ago.
@fsflover linked the issue above.
- The cheese app seems to be corrupted in my personal qube. I attached my webcam to the personal qube, then tested taking a photo, which worked. When I tried to record a video, it froze, and I had to shut down the qube. Now when I open the cheese app, it always says “There was an error playing video from the webcam” and everything in the app is disabled.
Recording video takes quite lot of cpu power, might be worth a while to increase the VCPU count from App Qube’s Advanced Settings.
To fix your personal Qube’s cheese app you might want to try the following:
Delete ~./config/cheese and ~./cache/cheese directories from your personal Qube.
- There are odd graphical glitches in the Qubes splash screen and with some cursors (loading spinning wheel) in the desktop environment that I didn’t see with v4.0.4, particularly around the password box and progress bar during disk decryption
This is an issue with Intel Graphics and the newer GUI on luks decryption splash screen, you can press “Esc” to get CLI or disable GUI completely on spash screen (Run these in dom0):
sudo nano /etc/default/grub
Remove rhgb from GRUB_CMDLINE_LINUX line
Rebuild grub config sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Rebuild initrd sudo dracut -f
Reboot
Fixing some of the graphical issues while loaded into desktop environment you could try to follow this: I3 not working properly video/graphic issues - #4 by bungali
- The OS froze on me during a routine restart. When I clicked restart, it kicked me out to the login screen (which it always does in v4.1.0, which I don’t understand), then went to the Qubes splash screen and froze there. Is anyone else confused by Qubes going from desktop → login screen → Qubes splash screen that makes it appear as though it’s booting up when it’s actually shutting down, or is it just me?
On Qubes OS 4.1 it seems like it log you out before it goes to “shutdown” screen. As @dom0 mentioned App Qube’s take a while to shutdown.
Other issues that you are having seem really odd and personally have not experienced those.
One thing that hasn’t been mentioned that boosts performance (fixing CPU scaling). In dom0:
sudo nano /etc/modules-load.d/xen-acpi-processor.conf
Write xen-acpi-processor and save.
Reboot.
See also:
I’ve been using the Librem 14.v1 with Qubes 4.1 as my daily driver for several months now. I installed RC2 and have upgraded to 4.1.0. I haven’t had any issues with freezing, with one exception below. Everything has been running great, although I never suspend the system so I can’t speak to those issues.
I’ve noticed that NetworkManager does “forget” to connect to saved connections. Re-entering the config resolves the issue for me. So I end up with saved connections that look like ssidA, ssidA1, ssidB, ssidB1. I’ve never had to re-enter the config for a given network more than once. I initially thought it might be related to which wifi band it connects to, but I get prompted twice even on ssids that are only broadcasting on one band. This is probably a Fedora or NetworkManager issue.
Templates have very restricted access to the network. Stick with dnf (Fedora) and apt-get (Debian) whenever you can. Download 3rd party apps in an AppVM and copy them into the template to install them.
Cheese needs an audio input as well as the camera. Pass through the laptop mic or possibly some other device.
I have experienced the graphical glitch at the splash screen/LUKS password entry. The password field is distorted. That’s pretty minor since there’s nothing that useful to see.
The splash screens are the same. If Qubes is not shutting down or taking a long time to shut down there might be a particular VM that isn’t shutting down gracefully. You can try shutting them down individually and see if any take a long time or need to be force stopped.
Not sure what would have caused that unless you accidentally hit the logout button or a keyboard shortcut that locked the screen.
I think this is the error you see when sys-whonix shuts down. [Qubes OS 4.1] "Denied: whonix.NewStatus" dom0 permission - Qubes-Whonix - Whonix Forum
When upgrading dom0 with the librem-ec-acpi-dkms driver install I have to uninstall kernel-devel, upgrade dom0, then reinstall the driver.
The one annoyance I do have that I haven’t been able to track down yet is sometimes the boot process will freeze when trying to initialize the Intel frame buffer when I have DP monitors connected through a Thinkpad 40A9 USB-C dock. This happens after the Qubes kernel starts and before getting prompted for the LUKS password. Entering the Heads menu before booting Qubes seems to help, but that might be confirmation bias. The issue never occurs when I’m not connected to the dock, and I didn’t have this issue with Qubes 4.0 on my previous laptop.
I’ve tried various fixes for similar Intel graphics issues, but they haven’t helped. The boot process hangs with several lines similar to: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] ERROR [CRTC:51:pipe A] flip_done_timed out
Other than that, I haven’t had any issues that were Librem/Qubes-specific.
Which Samsung drive do you have? I heard there may be some sort of queued TRIM issue causing stability problems with some of the Samsung drives in Linux, but I don’t have much detail on that ATM.
Update on issue #1: I don’t think fedora-34 updates are the issue, just that my Wi-Fi configuration breaks from time-to-time upon reboot.
Today, I booted up and logged in. Wi-Fi connected automatically as expected. Then I did a shutdown, rebooted the system, logged in, and was annoyed to see the configuration was broken (i.e. Qubes would not make any attempt to connect, even though the configuration is correct).
What I do in this case is:
This is really tedious as I have had to do this probably 20 times over the past week.
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.
Should sys-net be disposable? If so:
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 have been running on Qubes 4.1 on a librem 14v1 since a few days after it went stable.
I do a full time dev job and some personal stuff through it as my daily driver.
Only real issues i have are:
Losing network connectivity on suspend, sometimes. Blacklisting device or modprobing it back to life only works sometimes.
Running sys-net in dvm.
Videoplayback works but only in debian based templates (vlc). Default videoplayer in fedora is very choppy.
I’ve been working around the two above issues and will post when i fix then but that seems like positively nothing compared to some things posted here