Firstly, i want to say that I am mindful of criticizing something that is so good as qubes and developed by the tireless efforts of great people. I can’t thank you all enough.
I have been a qubes user for a few years, but recently decided to use it on two laptops as my daily drivers. Yes, I use two laptops. Work and home.
I have to say that I had virtually zero issues with the version before this one (almost). I updated to the latest version and there is a litany of issues that have me thinking that maybe I can’t trust the stability of this release. Below are some of the problems that I have now that weren’t there on the previous release. Just for the record I run both of these qubes on lenovos, an x230 (16gb) and a w530 (32gb).
The inconsistent starting of sys-usb. There is nothing more annoying then starting my laptop when I need it go to have sys-usb not start. Sometimes this can be fixed by manually starting it, but about 30% of the time I get a message something like ‘unable to start’ and I have to reboot it.
On both machines qubes occasionally boots but won’t recognize wifi. Have to reboot. And rebooting takes a while with this monster.
I have had numerous occasions of the system freezing. The most recent example was that I couldn’t access anything on the top panel. Right or left click only gave me the panel preferences. Opening a terminal with right click was ok but keyboard didn’t work. Reboot.
Unable to shut vms down. It gets caught in a loop of shutting down and then restarting. Reboot.
The one that has me most concerned was today. This is a replay of an issue that I did have in the previous release. At the LUKS pw prompt it wouldn’t accept my password. I learnt from last time that inputting my pw very sloooooowly will have it accepted. Last time this happened I found out about the slow input after I’d done a reinstall. After inputting the pw slowly it booted into a “maintenance” window with a command prompt that was something like $sha (I think - I didn’t note it). I had no choice but to hard power off and reboot. On reboot it took my pw ok, ie no need for slow input, but then no wifi. A reboot and normal restart is where I am at now.
There have been other issues which I haven’t noted. But I am now worried that on any boot up it will not operate and my work of configuring this for my situation will be lost. I am no expert with qubes, and there may well be steps to take at the "maintenance’ window (happy for some inks), but my confidence is now shaken. Some may say that maybe qubes isn’t for me, which may be right, but I can’t help thinking that the versions of qubes that I scrubbed for this latest release was far more usable for someone at my level. I know my way around the system and am getting more confident but I worry that something will crop up that I haven’t seen before and I will be stuck (like the “maintenance” window today which luckily, so far, allowed a successful reboot).
I have posted this just as a marker of my issues, to see if others have similar problems, and if there are some things I could do to help these things.
As I said at the start, no offense is meant to the great developers and the community who have at least made something as complex as qubes accessible to a relative luddite like me. I just hope that some improvements take into account some of these things.
Then, did you try with fedora-35 and kernel latest? Did you try to disable wifi and diagnose then? I read many topics with Atheros wifi issues, and some were even by accidentally switching off by hardware button on the laptop.
Hi @Silver, I’m sorry that you have so many annoying problems with Qubes 4.1. I don’t have them, so it seems like it’s connected to the hardware, and also it’s a regression.
You can also have a look at the list of known issues and maybe contribute your logs there if you find anything related. See for example these issues:
I started using Qubes since this release, and experienced many of those. sys-usb is I think the most bugged part of Qubes, but most of this bugs are reported and some of them have to be fixed soon, according to github. Problems with freezes in my case was indeed probably hw related since when I switch from NVIDIA GPU to Intel GPU they are less common, but now there are strange artifacts on the screen (mainly when prompting password for LUKS) - also known bug. I hope that all of that annoying bugs will be fixed soon.
I’ve been a Qubes user for many years starting with version 4.0 and my experiences are similar, this posting pretty much describes my ideas about 4.1
Just like Silver I have to start with expressing my gratitude to the Qubes team for this great OS which has given me a ‘reasonable’ peace of mind while doing my work, a peace of mind which I could not have had otherwise. Also, just working with Qubes and reading the docs taught me a lot about security, it has been a great experience.
Qubes 4.0 has been solid as a rock, it never crashed on me once, the only problem I experienced was it occasionally didn’t let me type in the LUKS password and I had to reboot. This bug disappeared and it was just smooth sailing after that, for years.
Qubes 4.1 has been a completely different experience, there has been quite a few bugs, so much so I never skip a day backing up my work to an external encrypted disk, just by copying the files directly.
Qubes update tool not mentioning dom0 updates is an annoying bug.
sys-usb problems locking me out occasionally are annoying too, and also worrying. Having to distrust the possibility of restoring backups because users have reported pretty alarming problems with this is also unpleasant.
My general experience is that Qubes 4.1 has a long way to go before it reaches the stability of 4.0 and I think it would be wise to focus on this instead of adding new features, the multitude of problems mentioned on this Forum are not just because of a sudden increase in the number of inexperienced users, imo. I use Qubes because of the security it gives me, this is the primary function of Qubes for most (right?). So if the dom0 update procedure is faulty and dom0 vulnerabilities are not fixed if you don’t check with the CLI, fixing this seems more important to me than implementing some new shiny feature. Any OS needs to be up to date, most of all a security oriented OS.
Apologies for the rant … it’s mostly because I like this OS so much and hate to see the stability (might be) decreasing. And I also have to mention I haven’t experienced many problems the past few weeks, but I still can’t trust the OS.
I’ve been following Qubes since Snowden mentioned it. I didn’t want to use Qubes until 4.1 and used that time to carefully pick the hardware. Waited for stable QWT as well. Then I started to use it form the early 4.1 betas. Always updated it regularly and I still use that first installment.
Never, ever, not a single time it crashed. Never, ever, not a single time froze. Fully functional sys-audio even with Windows qubes, fully functional Windows dispxxx qubes, apt-cacher-ng, customized disposables for services and in general, and now preparing to transfer to sys-gui-gpu, even infamous xHCI USB controller now in HVM mode. And, me being a noob, the one could imagine how bloated or compromised it could become from then till today and still stable as a rock.
So, being inexperienced the only way I can interpret
is that the chosen hardware isn’t good enough for security standards set by Qubes. Or, some misconfigurations, more probably. Whatever, I’d wanted to share that there are some of us extremely satisfied with 4.1
I actually also experience a regression compared with 4.0: every wake-up from suspend hangs my sys-net and I have to reboot it. It’s with Atheros chip based on purely free software and firmware, I’m really surprised.
However it doesn’t look like a Qubes fault; AFAIK Qubes developers do not touch this part and rely on Fedora for the hardware support.
If the former, then any other distro is good for that (I’m not referring here to @fsflover, it’s just an example), and the reasons for using Qubes should be reconsidered. Stepping back from time to time to get a bigger picture is often rewarding. I won’t make more noise, sorry.
Everything seemed to upgrade smoothly over time from my initial 4.0.3 ISO install, but while attempting a clean install on a new machine of 4.1 has been quite difficult.
In attempting to build the ISO myself using qubes-builder, theres quite a few conflicting walkthroughs on it (and mismatching older images).
There seems to be a non-insignificant amount of similar, yet outdated info scattered around.
I can’t help but think a restructuring of the docs, including some kind of tagging system might save everyone a few headaches?
You probably know that the docs are a collaborative thing.
Any one can help by improving them.
That said builder v2 is in the pipeline and will need a complete
doc rewrite.
The actual build process is straightforward imo.
What part of this
are you having problems with?
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
@unman Yes I’ve been meaning to update the VPN section with a new guide, it keeps sliding down my list of tasks every week though!
I was following that qubes iso building guide, but it kept failing on some dependencies - attempted a little tweaking, but shelved it for now as I was more focused on other hardware issues this week.
In the past, I’ve spent many hours on the template building version (attempting arch builds), so I think I may be a little hesitant getting pulled down the rabbit hole
What my thoughts were on the docs (which I understand may be hard to implement in its current git hosted form): was to add standardized tagging to docs - date last updated (to save checking commits), specify template versions used at the top, or any other specific info - which could be an easier way to scan docs every year, to see what needs updating.
And if there was a way to implement a simple ‘is this helpful’ thumb up/down at end, for some loose metric of if the content still applies and is a valid doc.
I guess this topic may deserve a discussion in itself. I know the barrier to edit the docs isn’t difficult, but if it was a wiki-style I imagine many people may have made slight tweaks on the fly, compared to current iteration.
All things considered, I know an implementation like that opens up many other issues (hosting/security/spam etc), so I understand its no easy decision to make.
