Endless Issues with Qubes 4.1.0, 4.0.4 on Librem 14v1

User Support General
1

Hello,

I am a big fan of what Qubes OS aims to accomplish, but have had nothing but issues with v4.0.4 and v4.1.0. After fighting with Qubes for several days now, I am wondering how anyone actually uses this OS and whether I should switch to something that I can at least boot up and shut down without it freezing on me.

The reason why this is one post is I’m hoping someone can point to an issue that may be causing most or all of these rather than going on a wild goose chase trying to address all of these individually.

Hardware
I purchased the stock Librem 14v1 with PureBoot specifically because it is supposed to be one of the best systems to run Qubes OS. This came with Qubes OS v4.0.4 installed from Purism. After playing with it a little, I upgraded it by replacing the memory and storage with the following. Other than this, everything is stock and I don’t have any external peripherals or drives plugged into it:

  • Memory: G.Skill Ripjaws DDR4 2666MHz, 2x32GB
  • Storage: Samsung 970 EVO Plus, 2TB

For all installations detailed below, I allowed Qubes to automatically partition the entire drive. The only setting I changed was enabling “Enable system and template updates over the Tor anonymity network using Whonix” because why not?

v4.0.4 Installation
1st Attempt:
The installer froze on step “Installing qubes-mgmt-salt-dom0-update.noarch (821/1016)”. I let it got for ~7.5 hours before I did a force-shutdown.

2nd Attempt:
The installation completed without throwing any obvious errors, but when I restarted, it skipped the Initial Setup step, leaving me nothing but dom0 in the Qube Manager. I manually ran the Initial Setup, but this threw a dom0 error “qubes-prefs: error: Failed to connect to qubesd service: [Errno 111] Connection refused”.

I restarted and attempted the Initial Setup again a couple of times, then ran into error “…can retry configuration by calling ‘sudo qubesctl state.highstate’ in dom0 (you will get detailed state there).” I called this command, and it claimed “Succeeded: 28 (changed=2)” and “Failed: 0”. Then I rebooted and the OS froze on the Qubes splash screen, so I had to do a force-shutdown.

Then I restarted and was able to log in, but received the message “Domain sys-firewall has halted” and then the OS froze again. After more fiddling, I ran into other issues like the system claiming the Tor browser wasn’t even installed in the whonix-ws disposable VM, which wasn’t true. When I looked in the Qube manager, the debian-10 template wasn’t there, but there was a “tmp-debian-10” that the system installed, which is odd.

By this point, I had decided that I couldn’t trust this installation, so I reinstalled the OS…

3rd Attempt:
The installation completed without throwing any obvious errors. When I rebooted, it did correctly take me to the Initial Setup, which the previous installation did not. However, this ran into the same error I saw before: “qubes-prefs: error: Failed to connect to qubesd service: [Errno 111] Connection refused”.

I gave up on v4.0.4 and decided to try v4.1.0.

v4.1.0 Installation
I downloaded and verified the v4.1.0 ISO (integrity and authenticity), then flashed it with Rufus from Windows 10 in DD mode. The installation completed without any issues that I saw. So far, so good. Regarding the following issues, note that I’ve done virtually nothing to the system beyond installing system updates and tweaking the Firefox settings in the AppVMs and template VMs.

v4.1.0 Issues:

  1. 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.
  2. I’ve encountered an issue similar to #1 after waking up from the suspend state
  3. 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.
  4. 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.
  5. 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
  6. 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?
  7. One time, I was clicking around in the Qubes Manager when the OS suddenly kicked me out to the lock screen (i.e. as if the PC was idle, but clearly wasn’t). Is the idle timer not taking into account mouse actions?
  8. The OS froze on me during a normal shutdown (stuck on the Qubes splash screen)
  9. I saw the sys-whonix VM mysteriously shut down when I was in the Qubes Manager even though nothing was happening and no updates were being applied
  10. The OS froze on me after I signed in, but before it finished loading all of the items during startup (stuck on the desktop)
  11. I wish I had taken a screenshot, but I have seen something related to whonix getting into a weird state and an error being thrown when I shut down a whonix-ws-16-dvm, on several occasions

I’ve been using computers extensively since the early 90’s and have served in software engineering roles in a professional capacity, but I’ve never experienced anything like this. I’m not trying to throw shade here. I do love the OS and believe the world needs something like this, but it has been a real nightmare to try to get this to be even remotely stable, and I haven’t even begun installing software or trying to get a dock to work (prayers).

Does anyone actually use this OS regularly or for critical computing, or is this more of a hobby/experiment? Does anyone have any ideas what’s going on here, or is this par for the course? I am willing to put up with some inconvenience for the sake of improving my security, but I need something that actually functions reliably, not a science fair project.

2 Likes
2
  1. Along the lines of v4.1.0 issue #1, inserting my YubiKey 4 into a USB-A port broke my Wi-Fi configuration in such a way that not even a reboot fixed it. What does my YubiKey have to do with Wi-Fi?
3

I don’t have any answers for your problems of which there seems to be plenty.

But as I am just about to purchase a new laptop the Purism V14 was top of the list with qubes installed. I intend to go the full hog with this one, 64gb etc etc, but this sounds like a worry. Reinstalling qubes should not present as an issue. After considering a long list of linux laptops (including the framework project which doesn’t appear to support qubes) I have just about settled on Purism.

And yes, qubes is eminently usable for my needs, which admittedly are not demanding. But yes, it works, although I have also posted about a few issues with this latest release of qubes.

I will be watching this post closely.

1 Like
4

I do like the Librem 14v1 so far. If I can’t get Qubes to work out, I may resort to PureOS, but I really don’t want to give up Qubes.

One of the reasons why I bought the Librem stock (8GB RAM, 256GB storage) was to save money and confirm that I could install Qubes myself and understand how the whole PureBoot system works. What I didn’t want to happen was using the device as it came from the factory for a good while, then running into an issue at a bad time, then realizing I was in way over my head. I guess it’s a good thing that I’m running into these now when I have some time, but I’m kind of at an impasse and am not of the opinion that this is a Librem 14 issue at this time.

5

I agree, but I just couldn’t come at PureOS. I just don’t like it.

But I get your reasoning. I bought a Lenovo with coreboot/seabios with qubes installed and then after a couple of years I decided to reinstall qubes on it. Same thing as you’re saying. Initially it wasn’t obvious how to do it but, as usual with Linux, research and some helpful people. Now I have the confidence.

So I could potentially be in the same boat with the V14. Get it with qubes from the factory and then with a reinstall, which will come of course at some point, run into issues.

It may be worth your while to post over on the puri.sm forums as well. Plenty of helpful and knowledgeable people there who might help. Maybe even Purism support might want to know about this?

1 Like
6

Good idea. I do intend to reach out to them/their forum and note that they were somehow able to install v4.0.4. I did purchase a flash drive from them with v4.0.4 on it, and that’s what I used for the 3, failed installations I mentioned, so this is a real puzzle. Either they gave me a faulty flash drive, they didn’t flash it correctly, or they have some mysterious way of installing to avoid these issues.

7

…or there is some compatibility issue with the RAM or SSD I installed that I’m not aware of. I don’t see any real indication that they are physically faulty.

8

Bad news to me since I have planned to go for a L14.

@dom0 you have reported a very positive feedback on L14. Could you please comment to the issue list here? Thanks

2 Likes
9

Please crosslink or keep us updated here in this thread. Thanks

1 Like
10

I had some similar issues when I installed Qubes on my Librem 13(v4). It was full of issues, not too dissimilar to what you are describing. However, I persisted, and once I bought a Samsung hard drive everything worked much better. My Librem 13 has died, so am replacing with a 14v1, and will persist should the issues present on my set up too.

I have used Qubes for a couple of years now, and use it for everything, much more than a hobby distro. I encourage you to keep persisting and troubleshooting if you can.

2 Likes
11

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.

12

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!

4 Likes
13

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.

2 Likes
14

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?

15

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.

1 Like
16

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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

  1. 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.

4 Likes
17

See also:

18

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.

  1. 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.

  2. 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.

  3. Cheese needs an audio input as well as the camera. Pass through the laptop mic or possibly some other device.

  4. 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.

  5. 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.

  6. Not sure what would have caused that unless you accidentally hit the logout button or a keyboard shortcut that locked the screen.

  7. 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.

19

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.

20

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:

  1. Go into the “broken” configuration and copy the Wi-Fi password
  2. Go to the network manager and click on the SSID of the same network, paste in the password, then delete the original configuration. This will usually survive a few reboots before the issue is encountered and the process repeats.

This is really tedious as I have had to do this probably 20 times over the past week.

1 Like