Problem
I set up a gaming hvm. For some reason, no audio nor video works in it (single frames show in videos. ie: appears paused). I am not sure when this issue began.
Tests
There aren’t any packages missing from the gaming hvm - I checked against other vms. The gaming hvm is based on debian.
I created a disposable template based on the gaming hvm’s template, started a disposable, and it had no issues.
I have tried checking the sinks with pactl list sinks and sink inputs pactl list sink-inputs and there seems to be no problem (I compared with a working vm).
Testing pavucontrol in the gaming vm shows the programs which should be playing audio, but there is no audio shown to be playing (the bar that shows the volume of what is being played is empty)
Other info
I am using gpu passthrough with NVIDIA Prime. It works great. Regardless of whether I have the gpu attached or not this issue persists. If I attach it to another hvm, I have no issue there. It is just this gaming hvm that has the issue.
I have sys-audio set up according to this guide: Audio qube
I have no other issues with it. The gaming hvm has its audiovm set appropriately. Pavucontrol does not show the gaming hvm but that should make sense given there is no audio received from it.
Summary
Gaming hvm video/audio not working. Template is fine. Only this particular AppVM suffers.
Current problem
Seems the original issue just went away on its own. But I have a larger and separate issue. It takes many, many, many reboots to get my qubes to boot properly now. I have had this problem since install (relatively recently), but not nearly to the extent of how bad it is now (it used to take just a few reboots to work properly).
Seems like I have a major issue with starting any domu qube. I only have sys-usb set to autostart, so when booting, about 80% of the time it hangs on the service which starts sys-usb. So I have to hold down the power button to kill the system. I have tried disabling autostart with qubes.skip_autostart but this only pushes the problem down the line. If sys-usb starts properly though, about 50% of the time qubes freezes during startx (I don’t use xfce) before X is shown (tty output is all that is seen). If I get to X, then 80% of the time if I start any qube it will just freeze almost the entire system. Notifications will be frozen and sometimes i can click with the mouse. Other times I cannot click with the mouse (I think). The keyboard becomes completely unresponsive always though. Seems like I can always move the mouse though. After a few dozen attempts to boot over the course of a few hours it eventually all works. Now I don’t want to shutdown haha.
Summary
Starting any domu qube freezes/halts most of the system most of the time, requiring multiple reboots to fix.
I will update this post when I shutdown and boot again.
It won’t let me edit the post so here’s the update:
Seems like the problem is mostly gone. Booting has been fine, generally. I have still run into the issue where occasionally I start a qube and it freezes everything.
It is a bad idea to install/run such software in Dom0.
If a hardware problem is suspected, and you are not using a laptop, then first:
If you did upgrades, verify that your PSU is adapted to your system components, especially GPU power requirements.
Verify that the ram is compatible and no overclocking.
Did you have a previous stable configuration?
You mention a gaming HVM, but no other hardware details. GPUs are power-hungry. If you have more than one graphics device then what happens with only one installed ? If you only use one?
There are different possibilities for testing…
Bare-metal memory test
If you can boot from usb or dvd, then some install ISO for "normal’ Linux include a memory tester in the grub boot menu. I am not sure if this is on current iso images - I have some old dvd I use.
This only tests the main memory.
tests in AppVM
Phoronix Benchmark gives a lot of possibilities. There are many web pages with other suggestions for torture testing.
You can make a new AppVM:
You can first clone an existing one - maybe your gaming HVM?
give it the maximum number of vCPU - equal to your number of cores.
give it a large amount of RAM, fixed without ballooning. I use 1GB less than installed memory, but maybe it is possible to allocate more.
Shutdown all other qubes, except sys- ones.
Install and run one of the different possibilities for testing.
This allows testing inside Qubes, but it does not give the software full access to the hardware.
Test in non-Qubes distribution
This might require an alternative HDD/SSD.
Can your hardware configuration run stably in standard Fedora or Windows ?
This also simplifies use of onboard temperature sensors to verify cooling. I guess it is also possible to use lmsensors in Dom0 -to be verified. You can also more easily test GPUs, etc, without virtualization.
All previous problems went away. No qube was freezing the system for a time. Now I have a new issue. I think I have pinpointed the source of the initial problem and the current problem: suspend. After suspending twice, after the second suspend the system was left in the frozen state. This has resulted in a similar situation to the initial problem.
Starting sys-usb leads to no usbs working. I cannot log in. To get the system to work, kernel param qubes.skip_autostart can be used.
VM communication is messed up. qvm-copy and qvm-move fail stating Request refused. qvm-connect-tcp blocks all requests stating the same.
I have tried rebooting dozens of times to no avail. I have only booted with qubes.skip_autostart a few times though. I have also tried repeatedly starting and shutting down sys-usb with a script, although this expectedly didn’t help.
You’re absolutely right. It was my own error. /etc/qubes/policy.d/30-user-networking.policy
Missing “+” in front of the port: qubes.ConnectTCP 8888 programming * ask
VS qubes.ConnectTCP +8888 programming * ask
I am still shocked that this one error caused the qrexec daemon to fail completely. Admittedly, it makes sense though, looking at it through a security perspective.