Troubleshooting slow bootup/shutdown?

[Emily]

The startup/shutdown sequence for some reason is now about 10X as long as it was before… (no joke).

I can’t isolate a specific change that might have caused it.

Anyone have some ideas that would lead to this symptom?

[BEBF738VD]

When you reach the cryptsetup prompt, press ESC, then insert your decryption password as you’d normally do, just without plymouth. This way you’ll be able to see which processes take the longest.

[Insurgo]

Some good answers here (be cautious modifying files, not recommended):

Workarounds for slow booting at LVM2 in Qubes OS

Here denotes my attempts to speedup booting as R4.1 on newer hardware is not stable enough and reboot may be required to reset the hardware into known good states. After inputed the correct hard disk encryption password on boot, press F1 to see the actual booting log in real time. Here one can see which step is taking the most of the time along with how much time has been spent on booting. systemd-analyze is useful to spot the slowest process and to spot the paths of services, however plea…

Otherwise discussion happened in length under:

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 F…

And then this testing thead for those interested into testing packages before they land in stable repos:

Xen + xmm-xen fixes to test (suspend/resume fixes, directio loopback devices, sys-usb fails to start, slowness vs bare metal)

I’m experiencing slowness as never before. When compiling stuff (enough ram all available cpus usable), my mouse stops moving sometimes, like if dom0 (where xorg is) was not having enough priority. This behavior is new since about a week. Will try to isolate, everything now from stable repo.

[renehoj]

You can try running sudo systemd-analyze blame in dom0, should tell you how long you spend on each step of the boot sequence.

[SteveC]

I haven’t noticed this – yet.

One thing you can do, if you haven’t already, is move the startup of your qubes into a script in ~/.config/autostart (or is it autostart-scripts) on dom0. Uncheck the “startup at boot” flag in the qube options for those you move to the script. Yes, you have to wait for them to start up before you can use them, once you’re logged in, but at least you get prompted for your password a lot faster. (As Sven puts it, he can go off and get a cup of tea.)

The only thing I have set to startup at boot is sys-usb. Network, firewall, cacher, my vera-store and vera-keys, and lastly my update canary all start up after I log in. (Update canary is just a minimal template VM I leave running so it will detect that my templates need updates to the OS–cacher seems to interfere with that process otherwise.)