Hi there!

With the latest upgrade, /etc/schroot/desktop/fstab gained PulseAudio
support (BTW, there is an extra space before the target folder):

The desktop profile was user-contributed, and I don't use it myself
other than trivial testing that it works for basic stuff.  If you
could let me know what's needed, I'll be happy to update the profile.
Note that if it's backward-compatible with earlier distributions, then
that's even better.


Thanks,
Roger

severity 675788 wishlist
tags 675788 + moreinfo wontfix
thanks

In the absence of the needed information to make things work, I won't
be able to fix this bug.  Did you get this working at all?  If you have
an updated configuration to share that would be very useful.

Marking as moreinfo/wontfix for the time being, and reducing the
severity since desktop stuff inside schroot is not something we can
support well, unfortunately, and it's only got more complex and
fragile.


Regards,
Roger

Hi,

While debugging a similar issue (I was trying to run skype inside a
chroot without sharing my home directory), I found this bug report, and
I think I can give the missing information to solve it.

When running skype, I was getting errors about not being able to create
directories under /run/user. Then I found this webpage that lists all
the needed locations that need to be replicated:
http://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#index36h3
(although I did not share ~/.pulse and it still worked).

In particular, pulseaudio needed the $XDG_RUNTIME_DIR location, which is
in /run/user when using systemd. I tried at first to bind mount /run,
but that did not work: each user has a tmpfs with special mount options
to force the UID which do not seem to be replicated when bind mounting
the parent dir, so the files appear as owned by root.

The problem now is that schroot does not seem to have any way to tell it
to mount directories based on environment variables.. I don't know the
code to suggest a workaround, but maybe one option would be to add a
configuration value that enables automatic mounting of the user's XDG_*
directories?

Such logic isn't built in to schroot.  But it's easy to add support using
a custom setup script.  It can look at the environment and ensure that
XDG_XXX_DIR is bind mounted into the chroot.  This should probably be done
by default for the desktop profile if it's set.  However, this type of
thing is going to be fraught with problems due to the way systemd
deletes the directory when the session ends, since a schroot session can
persist for much longer.  XDG_XXX_DIR is quite poorly-specified and it's
likely we won't be able to do a good job of supporting it.  That said,
any improvements, even if imperfect, would be welcome.


Regards,
Roger

Although this is not the right solution (as the XDG vars might point to
some other location), the problem with the systemd-related mounts is
solved if instead of using bind-mounts one uses rbind-mounts (recursive
bind).

I changed my desktop/fstab file and now I get sound with no errors:

/dev           /dev            none    rw,rbind         0       0
/run           /run            none    rw,rbind         0       0
#/run/lock      /run/lock       none    rw,bind         0       0
#/dev/shm       /dev/shm        none    rw,bind         0       0
#/run/shm       /run/shm        none    rw,bind         0       0

Found this by chance. I was reading instructions to set up a schroot for
ubuntu[0], and noticed they used rbinds, which I had never heard of
before! After reading the manpage, I thought this could work, and it did.

[0]: https://wiki.ubuntu.com/DebootstrapChroot

+++ Martín Ferrari [2015-02-04 19:12 +0000]:

I found another circumstance that was fixed by using rbind, but at the
time this did not sit well with autofs. I don't know if that has
changed in the last 3 years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648459

Wookey

We deliberately removed the use of rbind mounts because it broke
systemd users' systems.  Until then they used to be the default.

The bug is that rbinding a directory containing an autofs mount
results in a deadlocked system due to a kernel bug.  Maybe that's
fixed now.  This used to be the case for /dev and /sys.

I'd not be averse to restoring the use of rbind mounts.  HOWEVER,
we can't do this unconditionally.  We do need to know, if it is
fixed, which kernel version fixed it so that we can degrade to
a plain bind mount in the face of a buggy kernel version.  Since
it system is completely unusable shortly after doing the rbind
with autofs, it's not acceptable to do this blindly.


Regards,
Roger