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

[Greg Chicares]

On 2016-09-25 19:04, Vadim Zeitlin wrote:
> On Sun, 25 Sep 2016 15:53:50 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I'm not sure mounting /proc in particular is worth the hassle. This 
> morning
> GC> I experimentally created a chroot for which I did this
> GC>   mount -t devpts devpts /dev/pts
> GC>   mount -t proc proc /proc
> GC> in the chroot, before using apt-get to install the packages lmi needs. But
> GC> apt-get failed:
> GC>   Errors were encountered while processing:
> GC>    /var/cache/apt/archives/libpulse0_5.0-13_amd64.deb
> 
>  Were there any other errors (possibly long) before this line? Normally
> there should have been some output from the {pre,post,}installation script
> for this package but they could have scrolled away because I believe apt
> doesn't necessarily does things sequentially, so some other package(s)
> could have been installed since then.

Yes. In fact, the point of this particular experiment was to try to capture
the entire log. The commands were:

  schroot --chroot=xlmi --user=root --directory=/
  dpkg --add-architecture i386
  mount -t devpts devpts /dev/pts
  mount -t proc proc /proc
  apt-get update
  apt-get --assume-yes install g++-mingw-w64-i686 automake libtool make \
   pkg-config git zsh bzip2 unzip sudo wine >apt-get-log 2>&1

and the output, filtered with 'sed' as shown, is:

/srv/chroot/xlmi[0]$<apt-get-log sed -e'0,/^Preconfiguring/d' 
-e'/^Preparing\|^Unpacking\|^Configuring\|^Selecting\|^(Reading database/d'
0 upgraded, 263 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/231 MB of archives.
After this operation, 925 MB of additional disk space will be used.
dpkg: error processing archive 
/var/cache/apt/archives/libpulse0_5.0-13_amd64.deb (--unpack):
 trying to overwrite shared '/etc/pulse/client.conf', which is different from 
other instances of package libpulse0:amd64
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (215-17+deb8u5) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libpulse0_5.0-13_amd64.deb

Here's the relevant section from the unfiltered log:

Selecting previously unselected package libpulse0:amd64.
Preparing to unpack .../libpulse0_5.0-13_amd64.deb ...
Unpacking libpulse0:amd64 (5.0-13) ...
dpkg: error processing archive 
/var/cache/apt/archives/libpulse0_5.0-13_amd64.deb (--unpack):
 trying to overwrite shared '/etc/pulse/client.conf', which is different from 
other instances of package libpulse0:amd64
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

I *think* (but I'm not sure) that this right before doing this, I had
created a chroot of the same name without redirecting apt-get's output,
and had noted *something* (which I've forgotten) that looked anomalous
in that output...and then run 'apt-get purge [same list of packages as
given for 'install' above]. Therefore, it's possible that 'apt-get purge'
failed to erase the pulseaudio configuration file, even though 'purge'
AIUI is supposed to do that...and perhaps 'apt-get install' would have
succeeded except for that.

> GC> so I decided to eradicate that chroot and start again, to see whether that
> GC> apt-get problem is reproducible.
> 
>  It's really surprising to see all the problems with apt that you're
> running into, I definitely don't set up chroots as often as you do, but I

I learn by practicing. You have some better way (like "thinking", I suppose),
but that doesn't work for me: you probably don't do *anything* as often as I
do, because you don't have to. Besides, I'm still learning *nix fundamentals.
For instance, earlier, I carefully made notes showing that these "pseudo"
directories existed in the chroot:

  address@hidden:/# ls -a /dev/pts/
  .  ..
  address@hidden:/# ls -a /proc/
  .  ..

and was puzzled by error messages saying that /proc couldn't be read. But
surely it could...just as, if I did 'mkdir /croc', that would be readable
by root. Then I realized that the pseudo filesystems must be supported in
the kernel, somehow...aha, because of those magical '-t' parameters:
  mount -t devpts devpts /dev/pts
  mount -t proc proc /proc
But I still figured they must be physical directories, because...well,
they show up in 'ls' output. So I imagined they were *actually* real
directories (magically populated with phony files), which I could just
'rm' (but that didn't work very well). I also cherish the notion that a
chroot is a completely self-contained same-OS VM with no overhead, but
now I see it isn't (though a "plain" schroot comes pretty close).

IOW, I guess I'm condemned to learn *nix by repeating the mistakes of
those who do not understand it.

> still must have done it a few dozen times and I've never seen anything like
> this. I wonder if I was just lucky or if all these problems are somehow due
> to using schroot (which I had never used)?

Probably you understood *nix before you used a chroot. I think my problem
is ignorance, not schroot.

> GC> First, I reentered the chroot as root and tried using 'systemctl' to halt
> GC> the daemon. That failed, with an error message explaining that such an
> GC> operation can't be done inside a chroot.
> 
>  This is really strange because if the service had been started by
> systemd, it should be possible to stop it using systemd also, of course.
> I'm late as usual but I wonder what would have "systemctl status dbus"
> said?
> 
>  Also, if you somehow do _not_ use systemd, which is supposed to be smart
> enough to avoid starting services when inside chroot, I strongly advise
> following https://wiki.debian.org/chroot#Configuration and creating the
> file /usr/sbin/policy-rc.d in chroot always returning 101 and maybe
> diverting /usr/bin/ischroot to /bin/true (I see that I did this in my own
> sid chroot, but I don't remember if it was really necessary).

Okay, I'll do that. I'm sure I read that page some time ago; I think I
interpreted it as applying only to sysvinit chroots, but now I'll follow
its advice, especially since I'm sure I've seen services started in the
rapidly-scrolling output that I only yesterday started trying to capture.

> GC> Looking back (correct me if I'm wrong), AFAICT the only advantage gained
> GC> by mounting /proc in the chroot is that it allowed the usbmux user to
> GC> start dbus-daemon
> 
>  I don't think so both because I believe that dbus-daemon shouldn't have
> been started inside chroot in the first place and because for me the main
> reason for mounting /proc is to avoid mysterious errors when running many
> common programs (possibly including those using wxWidgets as it does use
> /proc for a couple of, admittedly not terribly important, things such as
> returning the number of available CPUs or amount of memory).

Oh. Of course, in these chroots I'm using wxMSW only, and building it with
a cross toolchain...but with a native 'make':

/srv/chroot/xlmi[0]$strings ./usr/bin/make |head -1
/lib64/ld-linux-x86-64.so.2
/srv/chroot/xlmi[0]$strings /lib64/ld-linux-x86-64.so.2 |grep '/proc'
/proc/self/exe
/proc/sys/kernel/osrelease

and 'wine' must also depend on a similar system library. So (thanks for
pointing this out again) I guess I really do need /proc .