I am using an old Thinkpad T430 and I have been testing Qubes OS a little while ago on this machine, through an installation on a USB key. Everything was working fine and I liked the experience so I decided to make it the main OS of this machine.
So I took the last version (R4.3), wrote it on an other USB stick and installed it on the HDD. The problem is that is was completely unusable. Everything is pretty sluggish. Background appears slowly. A lot of error messages on sys-* qubes boot saying “Cannot connect to qrexec agent for 60 seconds”. After a fresh install, it takes at least 5 minutes after logging in, before reaching a stable state and getting the network working. And it is even worse after updating the different templates, it never succeeds to reach a stable state anymore, sys-* qubes just finally stop attempting to boot, only dom0 is running and no qube boot.
The difference with my working USB key install I noticed is that I was using Qubes R4.2.4, so I reinstalled a 4.2.4 version on HDD, and there everything was working fine, like it was on USB key. To be sure I did not fail anything during first R4.3 install, I reinstalled it again completely, I verified signatures, rewrote the install key, but the same result, everything was slow.
All the different AIs I used to help me solve this problem reached to the same conclusion: I have an IO bottleneck problem, due to installation on a HDD (7200 RPM), and I should either stick to 4.2.4 or buy a SSD to use 4.3.
I’m pretty fine with 4.2.4, but I saw somewhere in the documentation that it will be EOL in June '26, so it is not a viable solution in long term.
So my question is, is R4.3 definitely unusable on a HDD and require a SSD ? Will buying a SSD allow me for sure to run Qubes R4.3 fine on a T430, or might there be another incompatibility between my hardware and this version ?
I’ve been using r4.3 on a T430 with SSD and preloaded dispvms disabled for awhile. It is more sluggish than r4.2.4, but usable. Disabling preloaded dipvms wasn’t necessary, but I’m working to slim everything down (for example, minifying my firewalls and vpn qubes)
Ok, as I was back on R4.2.4 I reinstalled a 4.3 to give it a try. Disabling the disposal qubes preloading did not help much, I have the same result in both cases enabled and disabled.
However, I took advantage to do several installations and try different things, and I notice a slight improvement if I set sys-net being a DispVM instead of an AppVM (which is not my preferred option, but well…). In this case, all the sys-* qubes attempting to start at boot fail a 1 or 2 times but within 4-5 minutes sys-net manages to start and I have networking. Not ideal, but kind of usable (less than 4.2.4 though).
Ooooh very interesting, this may be the explanation for all my issues ! Too bad there is no fix foreseen nor postpone of R4.2 EOL… Seems like a end of support for my hardware then.
Edit: I’ve quickly tested adding cpufreq=xen on boot and result seems not that bad, I’ll reinstall Qubes one more time to get back a sys-net AppVM and I’ll see on the longer run.
Not sure if this is related, but a recent dom0 kernel update caused networking to fail after every suspend on my T430. I solved this by reverting to a debian-12-minimal template, installing the latest kernel (including the copy fail fixes in linux-image-amd64), and selecting the “provided by qube” kernel option for sys-net. Same set-up may work with debian-13, but I wanted to test an older kernel first and debian-12 still has a couple years in LTS.
I’m back with a few updates. In the end, cpufreq=xen does not seem to have changed anything. The good news, I don’t have the sys-net never loading problem anymore, sys-net always ends up showing after 2 minutes. Possible enhancement is that this time I went with Debian templates instead of usual Fedora. However, a lot of qubes often fail to load at first attempt (including all sys-* qubes), still saying cannot connect qrexec agent for 60 seconds. System is barely usable now in 4.3, but having to reattempt a few times to load my qubes, it is so frustrating that I have to manually restart my all qubes setup several times at each boot to get it working…
Anyway, I’m pretty sure now it is not related to HDD nor SDD in the end (I’ll see if I can edit the title). I love 4.3 and the many enhancements provided, especially in the UX, but the whole system is such a pain to run that I’m definitely considering downgrading to 4.2.4, despite the EOL. Things seem related to Is 4.3 sluggish for you? so I’ll keep updated on this topic, hoping an enhancement for 4.3 may be found soon.
Have you tried increasing the qrexec timeout to 300 ?
qvm-prefs --set sys-net qrexec_timeout 300
Personally I notice a difference between my ssd and nvme desktops, I definitely think a HDD would cause issues. Qubes really hammers disk I/O at startup
Thank you, I’ve just tried and it indeed improve things. With this, sys-net now ends to boot alone without any error, in around the same delay as before. Problem is that it is the only one, and all other qubes still fail to boot at first attempt. So with a script I have set qrexec_timeout at 300 for all my (~20) qubes. I was not fan of this workaround and wished we could set this property globally (because for every new qube I’ll create, I’ll have to re-do this), but now my whole qubes stack ends booting without any error nor manual reattempt required on my side, so it is much better. It is still slow, but less of a burden, I’ll give it a try on the longer run.
I’m sure performances would kinda improve with a SSD, but for now I’m not sure there is no bottleneck coming from CPU, and I’m not confident that my hardware will still be supported by QubesOS. So I’m not sure a SSD for my old hardware would be a wise invest. Maybe I should just give up with Qubes R4.3 on this hardware, choose another OS and wait for a new hardware for Qubes, or rollback on R4.2.4… I’m still thinking about it.
I have just noticed the same issue as well. My sys-net is based on kicksecure-18 so I only tried to select “provided by qube” for kernel as workaround but it is worse, sys-net never boots and CPU is at 100%. So maybe the template downgrade is necessary as well, but I’m not sure this is related to the whole sluggishness.
I agree that sluggishness seems like a much broader issue with r4.3. I am now using a debian-13-minimal template with the current stable kernel provided by the qube (6.12.86). Suspend is working.