New Qubes OS Installation is Slow at Startup

User Support General
1

Hi
I have two problems, one of which I seek help for in this post, but the other is relevant for how my system is broken, so I will mention that first.

First “intro” problem.
My new Qubes-OS installment (4.1 or 4.2), which I have used at least for some weeks now is very slow at startup, and starting qubes often results in an error, something like “Cannot connect to qrexec for 60 seconds”. This is particularly common if I start a few qubes at the same time. I also have noticed that the supporting qubes that handle USB and so on can be messed up when I start a lot of user qubes.

I read somewhere that someone had this problem when he was using super slow disks. My disks are nothing special, but they sure should be good enough for the task: “Western Digital WD 2TB Red NAS Hard Disk Drive 3.5” Internal Hard Drive SATA 6Gb/s 64MB Cache For Desktop"
I have 3 of them in a RAID (configured in Qubes-os install procedure).

I have a specwise slower machine which runs all this much faster than this new one. So there must be some special problem here.

Anyway, the real problem, or at least the one that is the most pressing:
Since the qubes take so long to start up, I decided to go to settings in qube manager and mark them “start qube automatically on boot”. Now I get to login (Not the encrypted disk password thing, the disk is not encrypted, I mean the user login), but mouse does not work (mouse pointer is frozen), the text cursor blinks a bit, but stops pretty soon, and at no point can I give any input from keyboard. It seems pretty likely that what is happening is that too many user qubes try to start up when the helper qubes are being started, and they decide to shutdown or something like that. But of course, I cannot just login and change the qube autostart since I never get that far.

So I want to either fix this thing (maybe somehow turn off this “start qube automatically at boot” by messing in the filesystem or something like that) or get all the userdata copied to some storage media and reinstall.

Or maybe there is a solution number 3 I haven’t thought about.

Edit:
I got impatient and asked around, about my problem elsewhere, and was given a link to this:

It turns off autostart for userqubes, and that did the trick for me, I got in and was able to undo my problematic changes.

The slowness is still an issue, so I don’t know, maybe OK to leave the issue open?

1 Like
2

What hardware are you using for Qubes OS?

3

My motherboard/memory: X99 Dual CPU Motherboard Set LGA 2011-3 With 2E5 2680V4 416GB=64GB DDR4 2400Mhz Support Dual 2.5G Network Card X99-8D4

Disks mentioned in the original post. Have tried giving qubes 400 MB initially, I also tried some other numbers, to no avail.

Part of logs that seemed relevant for one of the qubes below. At the time memory allocation was 300 MB initial memory, 3000 MB Max memory.

[2025-03-23 09:09:07] [   50.226613] systemd[1]: Listening on systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket.^M
[2025-03-23 09:09:07] [.[0;32m  OK  .[0m] Listening on .[0;1;39msystemd-oomd.socket.[0m -… Out-Of-Memory (OOM) Killer Socket.^M^M

...

[2025-03-23 09:12:06] [   19.122917] xen-balloon: vmemmap alloc failure: order:9, mode:0x4cc0(GFP_KERNEL|__GFP_RETRY_MAYFAIL), nodemask=(null),cpuset=/,mems_allowed=0^M
[2025-03-23 09:12:06] [   19.123257] CPU: 1 PID: 42 Comm: xen-balloon Not tainted 6.6.77-1.qubes.fc37.x86_64 #1^M

...

[2025-03-23 09:12:12] private login: [2025-03-23 09:12:15] [   27.883083] systemd-journald[301]: Time jumped backwards, rotating.^M
[2025-03-23 09:12:17] [   30.233730] systemd-journald[301]: Under memory pressure, flushing caches.^M
[2025-03-23 09:12:21] [   34.483121] kauditd_printk_skb: 20 callbacks suppressed^M
1 Like
4

That may be related to this post:

2 Likes
5

Try sudo dnf reinstall '*selinux*' within the template of the affected qube as mentioned here:

2 Likes
6

I did the selinux reinstall. Since then I have restarted the machine. Still, today I got the same vmemmap alloc failure.

1 Like
7

What is your PSU, exactly? Are you running ECC RAM? What graphics card do you use and how exactly is it connected? What BIOS is flashed?

Anyhow. If I were you, I’d strip down components as much as possible. Remove anything but the bare minimum (RAM, CPU, GPU, fans) and run some memtest and CPU stresstest.

If all went well I’d add a single SATA drive and install some Linux. Then some Linux with a second drive attached for LVM setup etc. Just to make sure, the RAM is OK and the system can handle all the (initial?) power draw.

2 Likes
8

PSU:
Corsair RMe Series RM850e PSU, 850W

Yes, I use ECC RAM.

BIOS:
Vendor: American Megatrends Inc.
Version: 5.11

Graphics card:
GeForce GT 710

Your suggestion for tests, I am not there yet I feel (this would be very time consuming for me, at best). I believe disks are the problem, perhaps coupled with the Qubes-OS RAID functionality (I do not trust that one at all). I used DeepSeek for consultation on this [1], and it suggested that my disks are slow and that a good SSD disk like Samsung EVO 970 [2] could solve it. It suggested that for Qubes-OS in particular, Xen/VMs require many small IO operations (as opposed to big file transfers), and therefore even a RAID, even if handled by a HW RAID controller would necessarily be quite slow compared to an SSD, no matter the RAID type.

So I’d like feedback on this: Is DeepSeek onto something with its analysis of SSD vs HDD on Qubes-OS?

I can afford an SSD disk, though (long story to do with EM radiation) I’d like to avoid it if there are good alternatives. atm it seems I should bite the bullet and buy an SSD disk, and see if that solves the main issue.

  1. I know, cannot trust it, but its suggestions can help a n00b like myself. ↩︎

  2. Commercials in LLMs already, yay. ↩︎

1 Like