Quoting Roger Leigh (rle...@codelibre.net): > On Wed, May 23, 2012 at 12:02:15PM -0500, Serge Hallyn wrote: > > Quoting Roger Leigh (rle...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org