VMs refuse to start after being shut down (following latest update)

[tetra...@danwin1210.me]

After the latest round of updates I have started seeing some odd
behavior: VMs will only start once per system boot. This is rather a
problem (it makes Qubes much less usable!), should I also add it to the
Github tracker?

Further details: After a VM has been shut down, when I try to start it
again I get the notification:

"Domain MYVM has failed to start: Cannot connect to qrexec agent for 60
seconds, see /var/log/xen/console/guest-MYVM.log for details"

In the relevant file I find the following block of ugly text. The "start
job is running" part is interesting as there is a similar message when I
go to reboot the machine (which I need to do to use the VM again!)... on
shut down, it hangs at the various "stop job is running" messages (which
it rotates through) until timeout. There are also further errors which
scroll past, but which I could not note down in time.

[ 3.659414] intel_rapl: Found RAPL domain core
[ 3.659429] intel_rapl: Found RAPL domain uncore
[.[0;1;31mFAILED.[0m] Failed to start Init Qubes Services settings.
See 'systemctl status qubes-sysinit.service' for details.
[.[0;32m OK .[0m] Found device /dev/hvc0.
[.[0;32m OK .[0m] Found device /dev/xvdc1.
[.[0;1;31mFAILED.[0m] Failed to activate swap /dev/xvdc1.
See 'systemctl status dev-xvdc1.swap' for details.
[.[0;1;33mDEPEND.[0m] Dependency failed for Swap.
[.[0;1;31mFAILED.[0m] Failed to start Initialize and mount /rw and /home.
See 'systemctl status qubes-mount-dirs.service' for details.
[.[0;1;31mFAILED.[0m] Failed to start Adjust root filesystem size.
See 'systemctl status qubes-rootfs-resize.service' for details.
^M[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (30s / n
o limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polli
ng (30s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… pro
gress polling (31s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (31s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (32s / no limit)^M.[K[.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (33s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (33s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (34s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (34s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (35s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (36s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (36s / no limit)^M.[K[ .[0;31m*.[0m] A start job is running for Monitori… progress polling (37s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (37s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (38s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (38s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (39s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (40s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (40s / no limit)^M.[K[.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (41s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (41s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (42s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (43s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (43s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (44s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (44s / no limit)^M.[K[ .[0;31m*.[0m] A start job i:

[tetra...@danwin1210.me]

On Fri, Oct 11, 2019 at 05:44:26PM +0200, tetrahedra via qubes-users wrote:
>After the latest round of updates I have started seeing some odd
>behavior: VMs will only start once per system boot. This is rather a
>problem (it makes Qubes much less usable!), should I also add it to the
>Github tracker?
>
>Further details: After a VM has been shut down, when I try to start it
>again I get the notification:
>
>"Domain MYVM has failed to start: Cannot connect to qrexec agent for 60
>seconds, see /var/log/xen/console/guest-MYVM.log for details"

Key discovery: when I updated Qubes, around the same time I decreased
the starting memory for some VMs to 200MB (from 400MB), and only those
VMs were affected by this issue.

Solution: raise the starting memory back to 400MB.