Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies]

[Vadim Zeitlin]

On Tue, 24 Sep 2019 00:00:53 +0000 Greg Chicares <address@hidden> wrote:

GC> That's because you know how to unmount. Don't overestimate my
GC> GNU/Linux expertise. Right now, I have:
GC> 
GC> mount |grep 'proc\|devpts'
GC> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
GC> devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
GC> systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15459)
GC> devpts on /srv/chroot/bullseye0/dev/pts type devpts 
(rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
GC> proc on /srv/chroot/bullseye0/proc type proc 
(rw,nosuid,nodev,noexec,relatime)
GC> 
GC> and I don't even know whether the duplicate proc and devpts
GC> mounts are okay. I mean, I infer that they are, but I can't
GC> explain why.

 They indeed are, and the answer to "why" seems simple enough: they're used
by different "systems". Any process running in chroot doesn't have access to
the real /proc, when it tries to access /proc inside chroot, it accesses
/srv/chroot/bullseye0/proc, which is the point of the chroot, isn't it. So
for /proc to retain its magic properties, it needs to be mounted on this
directory too, in addition to the "real" /proc.

 Of course, things are more complicated for /dev/pts, as everything related
to pseudo-terminals is more complicated (this is just a universal law, I
can't say why is it so). And I won't pretend to understand everything, or
even much, about them myself. But to keep things maximally simple, without
/dev/pts creating pseudo-terminals won't work in chroot.

GC> Searching the web just leads me into unknown territory like
GC>   https://lore.kernel.org/patchwork/patch/669159/
GC> which I guess is saying I don't have to worry about this,
GC> but it's all Greek to me.

 I didn't know about this patch and while it seems like it's something
interesting to learn about, it definitely doesn't seem obvious to me at
first glance neither...


GC> >  And my only other idea was to check if /src/chroot/bullseye0/dev/ptmx
GC> > existed as a char 5,2 device
GC> 
GC> I can't even figure out how to search the web for that. However:
GC> 
GC> > and used mode 0600
GC> 
GC> /root[0]#ls -l /srv/chroot/bullseye0/dev/ptmx
GC> crw-rw-rw- 1 root root 5, 2 Sep 11 17:14 /srv/chroot/bullseye0/dev/ptmx
GC>                        ^^^^
GC> 
GC> There's an occurrence of "5, 2", but is '2' part of the date?

 No, 5 is the major device number and 2 is the minor one and this is
exactly what I meant by my "char 5,2" shortcut ("char", BTW, means
"character device", which is indicated by "c" in the first column of "ls
-l" output). Sorry for not making it more explicit.

GC> Is there one supreme reference book that explains all this stuff?

 I really don't know. Classic stuff like device numbers and such are
explained in just about any Unix book, certainly including

GC> I have a copy of
GC>   _The Design and Implementation of the FreeBSD Operating System_

this one, but modern Linux systems are very different from classic Unix
systems. Information about them can usually be found on the web, or even in
the kernel documentation itself, but usually you know what to look for in
order to find it, which is definitely inconvenient.


GC> I used debian's automated installer for my base system. For chroots,
GC> I've done nothing special. In a chroot:
GC> 
GC> /opt/lmi/src/lmi[0]$ls -di / 
GC> 786435 /
GC> 
GC> the standard stuff seems to be present:
GC> 
GC> /opt/lmi/src/lmi[0]$ls /dev                                                 
      
GC> console  fd  full  null  ptmx  pts  random  shm  stderr  stdin  stdout  tty 
 urandom  zero

 Hm, so debootstrap did create at least some devices. Although there are
many, many more of them in the main system, so it seems to have done the
strictest minimum. That's fine though.

GC> and everything does seem to work. Does that mean this step isn't
GC> necessary for a debian-on-debian chroot? All I did is scripted
GC> in 'lmi_setup_{1,2}*.sh', and I don't see any way MAKEDEV could
GC> have been executed.

 It must have been done either by debootstrap or by post-inst script of one
of the packages installed by it (base system perhaps?). In any case, the
instructions in the Debian release notes I linked to seem to be obsolete.

GC> No, PEBKAC, I think. This option is mentioned in 'lmi_setup_40.sh',
GC> but I 'winecfg' seems to offer a GUI only, so I couldn't script it.
GC> I probably applied this setting globally. I just don't understand
GC> why it had worked as expected for weeks, until I found I needed to
GC> mount proc and devpts.

 In principle, I guess it could be trying to do something involving /proc
and falling back to the old behaviour when it failed. But it seems like a
rather contrived explanation even to my own ears, to be honest. I don't
have any other one however.

GC> I never entered it except with schroot. But the redirections in
GC> lmi's unit-test suite:
GC> 
GC> make "$coefficiency" --output-sync=recurse unit_tests 2>&1 \
GC>   | tee >(grep '\*\*\*') >(grep \?\?\?\?) >(grep '!!!!' --count | xargs 
printf '%d tests succeeded\n') >"$log_dir"/unit_tests
GC> 
GC> seem to fail without PTYs.

 Running this prefixed with "ltrace -f -e openpty --" should show if
anything here uses pseudo-terminals (provided ltrace is installed, of
course), but I'm not curious or wakeful enough to do it right now.

 Regards,
VZ

pgpFmD8uAcWkM.pgp
Description: PGP signature