[Pkg-sysvinit-devel] Bug#674178: /dev/shm is not set up right in chroot

[Serge Hallyn]

Quoting Roger Leigh (rleigh at codelibre.net):
> On Wed, May 23, 2012 at 12:02:15PM -0500, Serge Hallyn wrote:
> > Quoting Roger Leigh (rleigh at codelibre.net):
> > > On Wed, May 23, 2012 at 10:47:26AM -0500, Serge Hallyn wrote:
> > > > Package: sysvinit
> > > > Version: 2.88dsf-24
> > > > 
> > > > If you do:
> > > > 
> > > >     debootstrap sid sid
> > > >     chroot sid dpkg -i /var/cache/apt/acrchives/initscripts*.deb
> > > > 
> > > > you will be left with a mount on sid/run/shm
> > > > 
> > > > The related Ubuntu bug is https://bugs.launchpad.net/launchpad/+bug/974584 .
> > > > 
> > > > A debdiff proposed (but not yet pushed) to fix this in Ubuntu follows.
> > > 
> > > Could you possibly try with -25 (in experimental).  I fixed a bug with
> > 
> > I'm only seeing -24 right now, will re-check in a bit.
> > 
> > (http://packages.debian.org/experimental/sysvinit)
> 
> Hmm, looks like the upload went wrong last night; it was not accepted
> for some reason.  I've reuploaded--it's definitely passed through the
> upload queue.  In the meantime, you can also get the packages here:
> http://people.debian.org/~rleigh
> (It's now also in incoming, http://incoming.debian.org/sysvinit_2.88dsf-25.dsc)

Thanks.  That one did NOT result in a leftover mount on $chroot/run/shm,
however i got:

Installing new version of config file /etc/default/rcS ...
Installing new version of config file /etc/default/tmpfs ...
Installing new version of config file /etc/network/if-up.d/mountnfs ...
dpkg: error processing initscripts (--install):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of sysvinit:
sysvinit depends on initscripts (>= 2.88dsf-13.3); however:
Package initscripts is not configured yet.
dpkg: error processing sysvinit (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
initscripts
sysvinit

More importantly (this is the root of the problem I started looking into for
containers) it leaves the /dev/shm directory.  Since a chroot doesn't usually
have a separate /dev, that means that on the next entering of the chroot (or
startup of the container) you'll have the devshm tmpfs mounted at /run/shm,
and an empty separate directory at /dev/shm.

> > > /run/shm handling last night, though it was related to size
> > > determination rather than chroot handling it's not impossible that it's
> > > related.
> > > 
> > > WRT the patch, if ischroot is behaving incorrectly, then the ischroot
> > > utility needs updating.
> > 
> > Ok - as I said in the Ubuntu bug I do suspect we don't want that part
> > in there.  I'm not sure whether 'chroot dpkg -i *.deb' without
> > mounting /proc is meant to be supported.
> 
> In practice, /proc is required.  There's too much that needs it; just
> look at the usage in maintainer scripts--they rely in it without
> checking for its presence.
> 
> The mounting and unmounting of /proc is a good workaround, and it's
> something that the ischroot tool /might/ be best doing, especially
> since it's relying on it being present.  However, whether this
> should be done basically depends on whether using a chroot without
> /proc being mounted is supported.  I would think "no" is the answer,
> to be honest.  IIRC debootstrap mounts /proc automatically, and all
> the chroot usage on Debian e.g. build and user chroots either have
> /proc mounted in fstab, or use schroot to set up the chroot
> automatically.

Ok, I'm happy to drop that - all I *really* wanted was for debootstrap
to work, and as you say it mounts /proc.

-serge