[delete] doesn’t matter
You can try in your sys-audio template
sudo dnf install qubes-audio-daemon --allowerasing
It should remove pipewire-pulseaudio. Of course, try it in a cloned template for testing purposes.
dumb question on a long and old thread but is this worth it? as in is dom0 being exploited via audio stuff a real thing? have there ever been CVEs that would have worked on this (patched or not by now)? or is this overkill paranoia?
in general, malicious peripherals (usually USB devices) are a real attack vector. the other sensible use case for sys-audio is running DSP software (like an equalizer, noise suppressor etc), which you wouldn’t want to be doing in dom0
1 Like
ok understood - then for a normal laptop that just plays audio this doesnt make to much sense yes?
What if I attach a usb headset? then it starts to make sense, unless I attach it to the “linphone” or “signal” Qube yes? As in if I use a headset (with usb soundcard in it or so) for all audio of the laptop / computer.
You are quite correct.
However, even in your described setup, it is still a good idea to configure it. As a general rule we want to run as little things as possible in dom0 to reduce any possibilities of dom0 compromise
1 Like
I am using 4.3.1, no issue on my side. If some others have the same issue, I can delete my config and reconfigure it from the guide to check if I forgotten something. Any log on your side ?
1 Like
For me it’s worth it simply because otherwise using USB/bluetooth audio is such a PITA and sys-audio really simplifies this.
Mine is the third report so far. I’ve opened a ticket here. It includes the step by step instructions which reproduce the issue on my system. It would be great if others could confirm it.
But the instructions are for debian-13-minimal, so it’s different from the original tutorial you posted. As I mentioned before, the same setup worked for me on R4.2.
While watching journalctl, and switching the audiovm of the client qube from None to sys-audio (while they are both running), in dom0 I see the policies triggering correctly. But in the client qube and sys-audio no log entries are generated.
Stupid question maybe - but how “stable” is this?
I’m thinking if “kuhbs” - the thing (gui + config management) I build so endusers can easily use Qubes - should have an audio VM.
Audio in dom0 IS weird, I agree there.
But if I do this then audio has to work reliably across MANY devices (laptops, workstations, bla) and I have to be able to fully script this. I can’t ask endusers “open a terminal and type bla” - this just has to work.
Having a half way complex initial setup is ok, but then it has to be very reliable.
@fb2043 are the steps in your issue reliable for many (most all) laptops / workstations? (I mean you opened an issue so i suppose “kinda” but still wanted to ask).
I’ve increased pipewire’s debug level by adding Environment=”PIPEWIRE_DEBUG=3” to the systemd service, in both the client qubes and sys-audio.
Then again I switched the audiovm of the client qube from None to sys-audio. In sys-audio, the logs remained silent. The client qube showed this:
pipewire[510]: mod.qubes-audio: module 0x5cfc8759f5f0: new ({ }), peer id is 51
pipewire[510]: mod.qubes-audio: Closing stale vchan
pipewire[510]: mod.qubes-audio: module 0x5cfc8759f5f0: new ({ }), peer id is 51
pipewire[510]: mod.qubes-audio: Closing stale vchan
pipewire[510]: spa.loop: 0x5cfc8755be38 created queue 0x75f218000b70 idx:0 0x75f21eac76c0
pipewire[510]: mod.qubes-audio: Setting new peer domain ID
are the steps in your issue reliable for many (most all) laptops / workstations?
Even if the bug didn’t exist, the steps in my issue aren’t sufficient for a working sys-audio setup. For example they don’t attach the sound card to sys-audio. For a set of complete instructions (using a fedora template) you should read the tutorial at the top of this thread.
Post alpha, pre beta.
Mostly works but you need few workarounds. No production ready. No option in installer to add `sys-audio` even in beta.
1 Like
Sorry, I redid all the steps to create a sys-audio based on a debian-minimal template, and a debian-minimal appvm, and it just work for me. (R4.3.1, testing repositories)
Can you recheck that your ‘audiovm’ is ‘sys-audio’ ?
Also modified the guide to remove some unnecessary steps for debian VM.
Thank you for checking.
Can you recheck that your ‘audiovm’ is ‘sys-audio’ ?
I’ve repeated the steps, even with various small modifications, multiple times over the course of past days. The outcome is the same.
sys-audio was one of the qubes that I restored from backup after installing 4.3.1… I wonder if that could have screwed something up and couldn’t be reversed by recreating everything. Ideally the devs will help to troubleshoot this in the Github issue at a lower level, but I’m not holding my breath.
If it can help:
In your sys-audio, kill the “/usr/bin/qvm-start-daemon” process (if it doesn’t run, there is a issue).
Then relaunch it manually like that:
“/usr/bin/python3 /usr/bin/qvm-start-daemon --all --watch -v -d“
When you start your appVM for audio tests, it should try to connect to sys-audio and a log should appear there
and check the result of
qubesdb-read -w /qubes-audio-domain-xid
in your audio appVM and compare it to “qvm-prefs sys-audio xid”
Then relaunch it manually like that:
“/usr/bin/python3 /usr/bin/qvm-start-daemon --all --watch -v -d“
Ok, thanks for that! Could you pplease check what you have at /usr/lib/python3/dist-packages/qubesadmin/tools/qvm_start_daemon.py:594? I have installed python3-qubesadmin/unknown,now 4.2.18-1+deb13u1 and for me the line is:
pacat_cmd = [PACAT_DAEMON_PATH, '-l', self.pacat_domid(vm), vm.name]
This has a bug which was at the root of the problem. The verbose output showed it was throwing TypeError(‘expected str, bytes or os.PathLike object, not int’). I fixed it by wrapping self.pacat_domid(vm) in str(). Now everything works. But I’m really confused why this wasn’t being reproduced. I wonder if it’s because you were using the testing repos?
EDIT: Found the reason. I was creating everything using the debian13 template imported from my R4.2 backup. That template still had the R4.2 repos configured. The bug I found was fixed in Fix starting audio daemon · QubesOS/qubes-core-admin-client@ced1d2f · GitHub but it seems it never made it to the R4.2 repo.
@cocil001 pinging you with how I fixed a similar issue to yours
1 Like
thanks
fb2043 <qubes_os@forum.qubes-os.org> 于 2026年7月9日周四 08:38写道：