Qubes OS release

4.2

Brief summary

This is an old issue of a machine I'm no longer using. I'm documenting it here after @marmarek encouraged me to. Sadly, I won't be able to provide additional logs or analysis. Title was chosen for what I would have tried searching for at the time.

The basic issue starts with creating the audio-vm via salt:

sudo qubesctl top.enable sys-audio

After a reboot, dom0 will start but no other VM and the error-notifications were very cryptic.

The central issue was that my last machine had a GPU. The GPU had an audio-part. This audio-part was permanently attached to sys-audio and thereby became a requirement in order to start it. However, partly attaching the GPU is impossible and sys-audio therefore could never start.

The salt-script at the same time sets the audio-vm property of all VMs. I am not entirely sure what caused all other VMs not to start, but it seemed to me that all VMs required their audio-vm to be started before starting themselves.

This assumption is based on every time I tried starting a VM, qubes tried to start sys-audio but failed.

Steps to reproduce

On a vanilla QubesOS, run the sys-audio salt.
Ideally, have a GPU with an audio-part present. But I believe the essential part is to create a non-starting sys-audio, so maybe permanently attach a different PCI device and then attach the PCI-device as well to a VM that would start first? (make sure to remove it's audio-vm settings!)

Furthermore, it's quite possible this is a more subtle issue about PCI-devices. It's somehow related to sys-audio's autostart property. Setting this property to false,

Expected behavior

Creating a sys-audio with salt at the very least allows VMs to start, always.
GPU-parts are not added to VMs (i.e. more selective PCI-selector in the salt-script)
There should be a way to start something in such cases. Maybe an "ignore dependency" mode? I would like to at least have enough VMs to

Actual behavior

The bug was fully fixed by removing the offending PCI-device.

I removed sys-audio's autostart as a precaution, so it doesn't poison the startup procedure. (At the time, his will required to start sys-audio manually before any other VM, but this behavior seems to be fixed by now?)