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

[Greg Chicares]

On 2019-09-23 21:50, Vadim Zeitlin wrote:
> On Mon, 23 Sep 2019 21:37:43 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-09-23 20:05, Greg Chicares wrote:
> GC> [...]
> GC> > I hadn't yet set up these filesystems for my new bullseye chroot on my
> GC> > new buster installation. Running lmi's unit tests failed thus:
> GC> >   tee: /proc/self/fd/14: No such file or directory
> GC> > so I figured I'd better mount them, thus:
> GC> > 
> GC> > /home/greg[0]#schroot --chroot=bullseye0 --user=root --directory=/      
> GC> > /[0]#mount -t devpts -o rw,nosuid,noexec,relatime,mode=600 devpts 
> /dev/pts
> GC> > /[0]#mount -t proc -o rw,nosuid,nodev,noexec,relatime proc /proc
> GC> > /[0]#exit
> GC> > 
> GC> > Now the 'nychthemeral_test' script runs successfully, but I can no 
> longer
> GC> > run lmi under wine. The command line where I started it just freezes 
> (and
> GC> > needs a few Ctrl-C's to regain control), and no (wine) lmi GUI appears.
> GC> 
> GC> [...adding the following lines to /etc/fstab and rebooting...]
> GC> 
> GC> > devpts /srv/chroot/bullseye0/dev/pts devpts 
> rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
> GC> > proc   /srv/chroot/bullseye0/proc    proc   
> rw,nosuid,nodev,noexec,relatime 0 0
> 
>  I'm sorry, I didn't succeed in sending my reply to your previous message
> in this thread before you sent this one, but it wasn't a big loss anyhow,
> as I was just saying that I had no idea what was wrong.
> 
>  One thing I can say is that I see absolutely no conceivable reason for
> rebooting just to change chroot mounts.

That's because you know how to unmount. Don't overestimate my
GNU/Linux expertise. Right now, I have:

mount |grep 'proc\|devpts'
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
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)
devpts on /srv/chroot/bullseye0/dev/pts type devpts 
(rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
proc on /srv/chroot/bullseye0/proc type proc (rw,nosuid,nodev,noexec,relatime)

and I don't even know whether the duplicate proc and devpts
mounts are okay. I mean, I infer that they are, but I can't
explain why. Searching the web just leads me into unknown
territory like
  https://lore.kernel.org/patchwork/patch/669159/
which I guess is saying I don't have to worry about this,
but it's all Greek to me.

>  And my only other idea was to check if /src/chroot/bullseye0/dev/ptmx
> existed as a char 5,2 device
               ^^^^^^^^^^^^^^^

I can't even figure out how to search the web for that. However:

> and used mode 0600

/root[0]#ls -l /srv/chroot/bullseye0/dev/ptmx
crw-rw-rw- 1 root root 5, 2 Sep 11 17:14 /srv/chroot/bullseye0/dev/ptmx
                       ^^^^

There's an occurrence of "5, 2", but is '2' part of the date?

Is there one supreme reference book that explains all this stuff?
I have a copy of
  _The Design and Implementation of the FreeBSD Operating System_
but apparently they do things differently; is there a canonical
equivalent book for linux?

> because it's the only
> other thing I'm aware of which is related to terminal problems. I though
> debootstrap was supposed to run MAKEDEV, but at least under Buster it's
> necessary to run it manually, see
> 
> https://www.debian.org/releases/buster/amd64/apds03.en.html#idm4368

I used debian's automated installer for my base system. For chroots,
I've done nothing special. In a chroot:

/opt/lmi/src/lmi[0]$ls -di / 
786435 /

the standard stuff seems to be present:

/opt/lmi/src/lmi[0]$ls /dev                                                     
  
console  fd  full  null  ptmx  pts  random  shm  stderr  stdin  stdout  tty  
urandom  zero

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

> GC> That still didn't quite work, but I seem to have found the problem
> GC> by running 'winecfg': I had apparently set wine to emulate a
> GC> virtual desktop by default. In earlier installations, I had always
> GC> kept that option turned off by default, enabling it selectively
> GC> for only one or two programs other than lmi.
> 
>  Maybe the new version of Wine included in Bullseye has upgraded the config
> file wrongly?

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

> GC> Here's another interesting thing I noticed when I rebooted into my
> GC> old 'stretch' system: I had several chroots, and /etc/fstab mounted
> GC> devpts and proc in an old chroot; but long ago I started using a
> GC> newer chroot instead, yet forgot to change /etc/fstab; however,
> GC> everything kept working just fine. That seems really mysterious,
> GC> but I'm not going to spend time investigating it.
> 
>  As long as you only use [s]chroot to enter it, you may not have needed
> pseudo-terminal support, so it's conceivable that it worked without it. But
> there are plenty of other things that require either PTs or /proc, so this
> does seem unlikely.

I never entered it except with schroot. But the redirections in
lmi's unit-test suite:

make "$coefficiency" --output-sync=recurse unit_tests 2>&1 \
  | tee >(grep '\*\*\*') >(grep \?\?\?\?) >(grep '!!!!' --count | xargs printf 
'%d tests succeeded\n') >"$log_dir"/unit_tests

seem to fail without PTYs.

> Could it be that you had mounted these directories
> manually and just didn't update /etc/fstab?
I think the sequence of events may have been:

(1) create the chroot, running these commands as root:

mount -t devpts -o rw,nosuid,noexec,relatime,mode=600 devpts /dev/pts
mount -t proc -o rw,nosuid,nodev,noexec,relatime proc /proc

(2) then never reboot, and everything just works

(3) then I probably rebooted, losing those mounts, and didn't
run the full lmi test suite again until today.