Re: [lmi] Creating a chroot for cross-building lmi

[Greg Chicares]

On 2016-09-08 22:06, Vadim Zeitlin wrote:
> On Fri, 2 Sep 2016 01:31:12 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> During 'debootstrap', I see messages like this:
> GC> #   E: Can not write log (Is /dev/pts mounted?)
> GC> #   [FAIL] Can't start system message bus - /proc is not mounted ... 
> failed!
> GC> and I just ignore them, because the chroot seems to work perfectly.
> GC> What negative consequences could this have?
> 
>  I don't know because I don't see them, probably because I updated my last
> Wheezy system to Jessie by now. I probably could install a Wheezy chroot
> and try creating a Jessie chroot from it, but this is starting getting
> seriously metaphysical, so let me just give two advices without bothering
> practically checking them:
> 
> 1. As I said before, I think you do need to mount /dev/pts because many
> programs risk to fail mysteriously if PTYs don't work. This can be done
> manually using "mount -o bind -t devpts /dev/pts devpts".
> 
> 2. For the system bus, this is a systemd thing and I'm almost sure it's not
> going to function correctly without it, so I'd do "mount -t proc /proc
> proc" too (here "-o bind" could be used too, but is not necessary, I
> think).

I'm not sure mounting /proc in particular is worth the hassle. This morning
I experimentally created a chroot for which I did this
  mount -t devpts devpts /dev/pts
  mount -t proc proc /proc
in the chroot, before using apt-get to install the packages lmi needs. But
apt-get failed:
  Errors were encountered while processing:
   /var/cache/apt/archives/libpulse0_5.0-13_amd64.deb
so I decided to eradicate that chroot and start again, to see whether that
apt-get problem is reproducible.

I exited the chroot and tried
  $rm -rf /srv/chroot/name-of-chroot
and that failed, producing an apparently endless stream of diagnostics.
Apparently that's because /proc was still mounted on a directory inside
the chroot (as well as on the host), and I guess /proc does not want to
be removed.

So I tried umounting it, and that failed
  umount: /srv/chroot/xlmi/proc: device is busy.
so I did this:
  $lsof /srv/chroot/xlmi/proc/
  dbus-daem  4775 usbmux    6r   REG    0,3        0 2129687280 
/srv/chroot/xlmi/proc/sys/kernel/cap_last_cap
My 'wheezy' host has no user usbmux, but the 'jessie' chroot does, and
the daemon it started of course remained active after I exited the chroot.
I figured I'd better kill that daemon.

First, I reentered the chroot as root and tried using 'systemctl' to halt
the daemon. That failed, with an error message explaining that such an
operation can't be done inside a chroot. (I copied and pasted the exact
diagnostic into an email draft that I neglected to save before the
slight disaster that I'll describe shortly.) Then I tried exiting the
chroot and halting the daemon with 'systemctl'...which of course doesn't
exist on my 'wheezy' host.

At this point, perhaps I should have tried 'kill 4775', but that seemed
harsh, so I tried a command that I think was
  services stop dbus
but I'm not sure because that took down my desktop. It didn't work anyway,
because on tty1 I saw that pid 4775 was still running...so I used 'kill',
and then 'umount' succeeded.

Looking back (correct me if I'm wrong), AFAICT the only advantage gained
by mounting /proc in the chroot is that it allowed the usbmux user to
start dbus-daemon, which doesn't seem necessary for cross-building lmi
(libpulse must have been installed as a dependency of wine, but I don't
actually want to use wine for multimedia). And the downside is that this
made /proc difficult to umount, though now I guess I might know how to do
it. I think I'll forge ahead without this /proc mount, and see whether
that actually causes any problem.