Audio in Debian VMs just disappeared?
Stumpy
AFAIK I haven't done anything other than regular updates. I didn't
notice until recently so I am not sure about exactly when it started.
In the audio mixer window none of the debian vms are showing up. I tried
plaing something in VLC and it gave the follwoing errors:
https://privatebin.net/?f36509f33694a053#821JIyu4z/YqpQ61qGRYFP9Bspo7DAP8HmkPJCAk9Q8=
Also, another strange, maybe unrelated thing happened, I don' thave
nautilus in my debian VMs any more and I tried to reinstall then but
error saying I had some missing dependencies?
Stumpy
I still haven't figured this one out
in case the private/paste bin was causing no responses here is the
output from VLC:
from the vlc window:
"Audio output failed:
The audio device "default" could not be used:
No such file or directory."
and from the term that I started vlc from:
VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c)
[00005e890a526938] pulse audio output error: PulseAudio server
connection failure: Connection refused
[00005e890a4410e8] core libvlc: Running vlc with the default interface.
Use 'cvlc' to use vlc without interface.
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function
snd_func_card_driver returned error: No such file or directory
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared
object file: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat
returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer
returned error: No such file or directory
ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
[00005e890a526938] alsa audio output error: cannot open ALSA device
"default": No such file or directory
[00005e890a526938] core audio output error: module not functional
[000076de94d7eaa8] core decoder error: failed to create audio output
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared
object file: No such file or directory
[000076de74001268] xcb_xv vout display error: no available XVideo
adaptor
anyone?
Stumpy
Is there something else I can post that would make this easier to diag?
I really really would like to resolve this.
Foppe de Haan
pulseaudio-qubes is still installed?
qubenix
problem on a Kali VM that has the following pulse packages:
$ sudo dpkg -l | grep pulse
ii gstreamer1.0-pulseaudio:amd64
1.12.3-1 amd64 GStreamer plugin for
PulseAudio
ii libpulse-mainloop-glib0:amd64
11.1-1 amd64 PulseAudio client
libraries (glib support)
ii libpulse0:amd64
11.1-1 amd64 PulseAudio client
libraries
ii libpulse0:i386
11.1-1 i386 PulseAudio client
libraries
ii libpulsedsp:amd64
11.1-1 amd64 PulseAudio OSS
pre-load library
ii pulseaudio
11.1-1 amd64 PulseAudio sound server
ii pulseaudio-utils
11.1-1 amd64 Command line tools for
the PulseAudio sound server
However on another Debian stretch template audio is normal. The pulse
packages there are:
$ sudo dpkg -l | grep pulse
ii gstreamer1.0-pulseaudio:amd64 1.10.4-1
amd64 GStreamer plugin for PulseAudio
ii libpulse-mainloop-glib0:amd64 10.0-1+deb9u1
amd64 PulseAudio client libraries (glib support)
ii libpulse0:amd64 10.0-1+deb9u1
amd64 PulseAudio client libraries
ii libpulsedsp:amd64 10.0-1+deb9u1
amd64 PulseAudio OSS pre-load library
ii pulseaudio 10.0-1+deb9u1
amd64 PulseAudio sound server
ii pulseaudio-utils 10.0-1+deb9u1
amd64 Command line tools for the PulseAudio sound server
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
Stumpy
debAppVMs?:
user@debappvm:~$ dpkg -l | grep pulse
1.10.4-1 amd64 GStreamer plugin for
PulseAudio
ii libpulse-mainloop-glib0:amd64
ii libpulse0:amd64
libraries
ii libpulsedsp:amd64
1:1.1-0ubuntu15.4 amd64 PulseAudio OSS pre-load
library
ii pulseaudio
1:1.1-0ubuntu15.4 amd64 PulseAudio sound server
ii pulseaudio-module-x11
1:1.1-0ubuntu15.4 amd64 X11 module for PulseAudio
sound server
ii pulseaudio-utils
And in my deb template:
user@debian9:~$ dpkg -l | grep pulse
1.10.4-1 amd64 GStreamer plugin for
PulseAudio
ii libpulse-mainloop-glib0:amd64
ii libpulse0:amd64
libraries
ii libpulsedsp:amd64
1:1.1-0ubuntu15.4 amd64 PulseAudio OSS pre-load
library
ii pulseaudio
1:1.1-0ubuntu15.4 amd64 PulseAudio sound server
ii pulseaudio-module-x11
1:1.1-0ubuntu15.4 amd64 X11 module for PulseAudio
sound server
ii pulseaudio-utils
1:1.1-0ubuntu15.4 amd64 Command line tools for
the PulseAudio sound server
Thoughts would really be apprecaited as I am comming up with no ideas.
yura...@gmail.com
You could try make a copy of the debian template, then re-install the copy completely with this Qubes guide https://www.qubes-os.org/doc/reinstall-template/
The command is quick to execute, just do something else while it works in the background. Once it is complete, then, see if the sound issue is fixed in the new debian template.
- If it is not fixed, then you will know the issue is in Dom0, and you narrowed it down to a Dom0 issue, which then likely might be something like the VNC server, or whichever packages is dependent on the sound sharing between VM's in dom0.
- If it is fixed, then the issue was likely in debian template itself, and you have no more worries. Just install all your applications in your new debian template, and change all your AppVm's to it.
yura...@gmail.com
Marek just posted a "potential" solution for the debian sound issues a few hours ago, here;
https://groups.google.com/forum/#!topic/qubes-devel/CJvMfj0zfb8
Stumpy
Thanks for pointing me to Marek's recent post.
Unfortuately I am not famialr with adding repos in qubes. After looking
around a bit (the i3 install doc) it seems it would be something like:
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
but I am not sure about the last part, I would think it should be like
qubes-debian or something.
What exactly is the cmds I should be using?
Thx!
yura...@gmail.com
It's likely due to the dom0 being more documented than the template testing repositories, causing this misunderstanding. You don't need to update the dom0 one, it's actually the debian template testing you need to update (from Qubes tools repositories), not the Dom0 repositories.
I recommend you make two copies of your original debian template. One is for unchanged frozen backup, the other is for messing around and experimentation, which if you find a solution, you can apply to your original debian template. Thereafter delete your experimentation template, while keeping your backup one for a while. If the solution stops working, then you have an old backup to fall back on. So it's easier to upgrade packages again to the right version, rather than having to mess around with downgrading packages.
Everything needed is found here https://www.qubes-os.org/doc/software-update-vm/
You can also go into the repo list and edit it, as briefly mentioned in the link above as well.
Run in Debian terminal: sudo nano /etc/apt/sources.list.d/qubes-r3.list
remove the # in the Qubes updates candidates repository, in front of the "deb". You don't need the "deb-src" one, so don't change that line.
Ctrl+X, press y to save, and exit.
Now run;
sudo apt-get update && sudo apt-get upgrade
Just install everything in the testing repository, see if it fixes the sound issues. Try temporarily switch one of your sound AppVM's to your experimentation Template OS to find out.
The reason it's suggested to two copies of the debain template, is to ensure that everything works smoothly, before you change anything, minimizing annoying extra work to do, if something goes wrong.
Note, if you want to remove the testing repository again, you can just go back in Debian terminal: sudo nano /etc/apt/sources.list.d/qubes-r3.list
and put back the # infront of the deb, which you had removed earlier.
Also note that the --enablerepo= flags are only temporarily, while editing the file above is permanent changes, until the file is edited again, that is.
If I understood Marek correctly in his post from earlier, the reason this fix is a temporary one, is because this is a fix outside the Qubes responsibilities. Which means, the moment the original repository pushes an update here, it will break the fix Marek made. As such, you must either avoid updating it until a fix from the original repository arrives, or alternatively, just update and take your chances.
The reason I suggested to make a backup template, is so that you caan easily return and apply Marek's fix, should you have used a future update that overwrites it.
Hope it helps, as Marek said, this update isn't tested.
yura...@gmail.com
I'm actually a little unsure how the Qubes repository command works in the Debian repository. It might not be sudo apt-get update && sudo apt-get upgrade, but rather something else. I haven't had the need for this before, and the exact debian command isn't documented for some odd reason. But the Fedora one is pretty straight forward, I assume the debian one is similar. But either way, the approach above "should" trigger the testing updates.
Just in case it doesn't work, you'll need to confirm if it actually did trigger the testing repository to update. If it doesn't trigger it, then no harm is done anyway, it'll just run plain steady updates, and not the resting ones.