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

[Roger Leigh]

> > 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

What went wrong with the initscripts postinst configure?  Would it
be possible to find out where the failure occurred?

> 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.

I think this is deliberate.  We're a bit stuck here.  Consider that
it's quite common to bind mount the host /dev into the chroot; mucking
around deleting this directory could seriously break the host system.
IIRC this is a deliberate choice.  I'm not sure it's the right choice
for newly bootstrapped or installed systems though--we should be
creating a symlink in this case, and I'll be happy to change that
logic if possible, but for upgrades of chroots it's really not a good
plan.

For systems using udev, this is a non-issue.  But finding out what
creates /dev/shm otherwise would be useful.  It looks like it's the
initscripts postinst, but I'm not sure if it's the only place.  And
even then, it's usually run when udev is active, so won't affect the
base /dev.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800