Qubes 4.0 rc3 boot and performance is quite slow
Fabrizio Romano Genovese
Looking at the console messages at startup, it looks like the problem is that Qubes takes more than one minute to boot sys-net, sys-firewall, sys-usb and sys-whonix. That was not the case in 3.2.
Also, when giving
qvm-start someVM
the startup time is again quite slow. Could it be that my VMs are based on Fedora26?
Cheers,
Fab
Tom Zander
> Looking at the console messages at startup, it looks like the problem is
> that Qubes takes more than one minute to boot sys-net, sys-firewall,
> sys-usb and sys-whonix. That was not the case in 3.2.
>
> Also, when giving
> qvm-start someVM
> the startup time is again quite slow. Could it be that my VMs are based on
> Fedora26?
I saw that the default of 400MB is causing VMs to swap like crazy on
startup. I change it to 1000MB and stuff starts significantly faster.
I also removed swap in fstab on all templates, the only effect this has had
so far is show that the memory balancer is in need of work. It fails to give
hosts memory when they use significantly more than others.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Fabrizio Romano Genovese
- When QubesOS is happy, it starts in ~1 min (yup, starting up all the VMs still takes a while). The overall system is very reactive, for instance if I type qvm-ls I obtain some output straight away. Moreover, if I start a VM the notification "VM blabla is starting" is displayed immediately.
- When QubesOS is not happy, it starts in ~3mins. The overall system is very slow, qvm-ls takes 3-4 seconds to display output, and starting a VM takes up to 20 seconds. Even the notification "VM blabla is starting" is displayed 4-5 seconds after the command is issued. Moreover the battery is drained much much quicker (200% quicker give or take).
What makes Qubes happy or not happy to start seems to be completely random. I have a slight suspect that this may depend on booting the laptop while plugged/unplugged, but I cannot confirm this.
Essentially my Qubes experience atm can be exemplified as follows: "At boot, throw a coin. If it's heads then it's fine, otherwise it's fubar". Any suggestion (or report of similar behavior) would be greatly appreciated!
Cheers,
Fab
Yuraeitha
After you type in your drive encryption password, followup by typing F1 key on your keyboard. This way you can follow the booting process in details as it happens. If any booting processes are hanging, you'll be able to take note "which one", and thereby narrow down the possible culprit.
You can also do a "sudo journalctl --boot" or akin to that, after booting. But remember to do so after a fresh bootup, unless you want a mountain of extra unneeded information.
Also, if the booting is slow before you type in your drive encryption, then you know it's related to settings or features EFI/UEFI or Legacy-Boot/BIOS. It could also possibly be because you got a thumb-drive or external-harddrive sitting in your USB; which on some systems can make the booting process significantly slower as the system tries to identify bootable systems on the extra external-drives/thumb-drives.
Yuraeitha
The battery issue, btw, as far as I recall is nothing new in Qubes 4. It's not something specifc to your system, and if it gets fixed, it'll probably be an update to fix all the Qubes 4 systems out there. But maybe there are settings you can flip to fix it manually, however it's not something I've checked.
Make sure the VM's that start at boot, are starting just as slow (or quick) as if you started them on an already running Qubes system. If the speed is similar, then at least you can assume it has nothing to do with the actual booting process.
It sounds weird that it happens randomly, maybe a few more clues are needed to hunt down the actual reason as to why it happens, unless someone with better insight drops by.
Marek Marczykowski-Górecki
Hash: SHA256
system, regardless of Qubes version: when it is on AC power, performance
is normal, but on battery it is significantly slower. Some workaround is
to change CPU scaling governor, by executing in dom0:
xenpm set-scaling-governor performance
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpSuRQACgkQ24/THMrX
1yyUiQgAhD98/UgCgmUIhyu77ShIccLqV0WqE+pPnFmC8uAije3wRztS6JE83ioP
/KI0GuCiGMgSDy/zodPkeh9CTG5pRE8K6qvkN6Xp0jBKWdvoV+DUyFw/Fx1ZX/yz
UpvMFdmIZCeF6HNndKI4jWTsJS/ypg8H8mZQ4odRtFXUiYaiRt1mbp6zS10cmMpB
kl0OQM8z3JBCrVaytYCGHEGvNoDU/fXnd485S35Nu4W00/1f2vIhDvsDPpk/PVa2
AxRC6LnWxxmO1UTEo30m7VJOE8ylezd0ZwwtahMGUUN8NyBWgstJA3UUQL9bVUuE
F1kXEZ7iAW9YvxQHPFpm18BAHxfaaA==
=r0ng
-----END PGP SIGNATURE-----
Fabrizio Romano Genovese
The booting problem is 100% dependent on being plugged or not. Precisely, I observed the following behaviors:
Booting plugged: Everything is normal, PC is fast. If I unplug it afterwards nothing really happens and performance stays the same.
Booting unplugged: FUBAR. Slow, unresponsive, battery draining over 9000. Plugging AC adapter in afterwards doesn't help at all.
Dunno if my intuition is the right one, but it may be that the booting process, when unplugged, triggers some sort of fucked up setting regarding power management that causes havoc. Note that, in my case, the only important factor to consider is if the AC adapter is plugged/unplugged AT BOOT. Connecting/disconnecting it afterwards has no effect whatsoever on performance.
Yuraeitha
That extra information you discovered is really insightful I think, where your power management stays as desired after unplugging (after boot), based on the two scenarios you listed. This should make it possible to narrow it down to 3 further detailed scenarios.
I'm no expert btw, so listen to Marek who is far, far more knowledge than I. But for now, heres a suggestion to narrow down the issue further based on your new post.
It probably means either of the three scenarios:
A) Xen is not changing to its own preferred power-settings over the BIOS/UEFI/EFI/Grub boot power settings (Can be changed bottom up from BIOS/UEFI/EFI/Grub?).
B) Xen is maybe tricked into believing the preferred power-settings due to incorrect BIOS/UEFI/EFI/Grub settings (can be changed top-down from Xen?).
C) No settings available in BIOS/UEFI or executable commands in EFI/Grub (Nothing that can be done).
So there is possible a top-down apporach, a bottom-up approach, and a scenario where you cannot do anything. I believe the command Marek listed is a top-down approach, while changing power-settings in your BIOS/UEFI/EFI/Grub is a bottom-up approach.
Given your relied information in your last post above, you can probably deduce that a bottom-up approach can work as well, since as you describe it, the power-state you're in during initial boot, decides the overall power-settings irregardless if you unplug later on. Question then, would be, what to change in BIOS/UEFI/EFI/Grub? And the Xen top-down command Marek mentioned above might also work too.
Just be careful with power-settings, it can damage your hardware severely if a setting is poorly set, and it's way out of my league to say with any certainty which settings are fine to change, and which are not.
For now though, maybe try take a stroll in your BIOS/UEFI and see if you can identify and suspicious power settings?
Fabrizio Romano Genovese
Cheers,
Fab
cooloutac
double check for updates cause after new years. my board just fixed all the bugs I reported. nice holiday present lol.