Why is Qubes OS booting slow?

One of the significant downside is that Qubes OS boots show and shutdowns slow.

I kind of understand why Qubes OS shutdowns slow - that is because Qubes OS want to shut down the remaining appVMs (what I do not understand is that why a VM using 10GB ram spends ~2 minutes shutting down, and ~5 minutes if it has 20GB ram; I suspect that the VM spends their time flushing the memory cache).

I does not understand why Qubes OS boots slow. Usually it takes more than 5 minutes to boot up. By pressing F1 I can see that Qubes OS spending nearly most of the booting time (when I looked at the journalctl -r it seems to be around 4 minutes) playing with LVM (like it takes 4 minutes to “Finish LVM event activation on device ‘/dev/dm-0’”). btw I installed my Qubes OS on HDD.

I bet that the slow boot time can be one meme about Qubes OS. Every time why anyone asks why I like to “suspend” my computer I can only say that the OS boots as slow as a snail.

Anyone knows better about the question?

  1. Why is Qubes OS booting slow?
  2. Why is AppVM with large memory shutdowns show?

maybe you want to take a look in this thread for my benchmark, btw it’s a fresh qubes.

Mostly that you have big files in there? try run systemd-analyze in dom0, and examine what makes booting take so long.

I’m not sure in my answer, but i do have a appvm that use for qubes-builder, it has 50gb storage space and 10gb ram, i don’t see any difference between the minimal and this vm.

That is probably the issue.

I’m using nvme and I don’t have any issues.

2 Likes

My main programming VM has 400GB private storage max size (300GB used) and 20GB ram, I am using HDD, and it boots fast (default qrexec timeout suffices) but shutdowns slowly (may be that docker stops slow, since docker starts that slow as well).

3min 57.613s lvm2-monitor.service                                                                     
3min 50.666s lvm2-pvscan@253:0.service                                                                
1min 16.355s qubes-vm@sys-firewall.service                                                            
1min 11.776s qubes-vm@sys-audio.service                                                               
     57.505s qubes-vm@sys-net.service                                                                 
     43.258s qubes-vm@sys-usb.service                                                                 
     37.370s qubesd.service                                                                           
     30.220s plymouth-quit-wait.service                                                               
     14.569s systemd-journal-flush.service                                                            
     14.241s dracut-initqueue.service      

This is what systemd-analyze blame tells.
One major problem come from lvm2; another major problem come from qubes-vm@sys-firewall.service - Why will this service take so much time despite sys-firewall is not booted at that time (this service starts BEFORE I enter dom0 login password)

try upgrading to nvme if possible, even ssd would do.

actually, qubes-vm service is started after qubesd service, and qubesd service is started before user session, nothing wrong.

The bigger the storage, the longer it takes to shut the VM down: