On Wed, Aug 15, 2012 at 06:54:56PM -0600, Bob Proulx wrote: > There are two issues. And I know that the /run transition was > discussed at length in debian-devel. Unfortunately I wasn't following > it then and only run into this problem now. I think using bind mounts > in either of the two cases is an unfortunate choice. I *really* > dislike it. So for me one issue is that the transition uses bind > mounts at all. But I am still investigating. I haven't figured out > why initscripts takes two different paths depending upon being in a > chroot or not. I think that is the root cause of the problem. > Whatever it decides to do it should to the same thing in either case.
So one key question here: do you have /proc mounted inside the chroot? That's required by ischroot to detect that it's in a chroot; but more importantly, it's required for lots of things to work properly, including libc, so it's something which is expected to be present. Note that it's also used by package maintainer scripts, so during an upgrade, it's also required. The reason for the bind mounts. We are migrating: /var/run -> /run /var/lock -> /run/lock /dev/shm -> /run/shm /lib/init/rw -> [removed] We are also doing this on a live system. We can't move the locations except at boot time, but we want it to be functional as soon as initscripts is configured. Then packages can simply Depend on (initscripts >= $version) and get a functional /run. So it works in two stages: 1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any programs with open files on these filesystems will be unaffected. Programs can use both the old and new paths without problems. 2) On reboot, mount a tmpfs on /run and replace these directories with symlinks. Programs can use both the old and new paths. This works very well. See http://wiki.debian.org/ReleaseGoals/RunDirectory for the detail. However, it won't work in a chroot: chroots don't run init scripts at boot, so on reboot, the bind mounts will be lost and the migration won't complete. chroots are a special case, and because we can't move the directories while they might be in use, we have to adopt a different strategy. See the latest initscripts postinst in unstable for what we have to deal with. It's really nasty; but we don't have a choice. We also have little control over what parts of the host system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need to take extra special care never to modify them, lest we break the host system. One thing we could do here is check if /proc is mounted with "mountpoint -q", and then assume we're in a chroot if it fails, since having /proc not mounted is very unlikely on the host system. However, it will need careful consideration, since the chroots are the special case here--we never want to run the special case setup for a chroot on the host system unintentionally. "Unlikely" isn't a good enough guarantee here--we need to be absolutely certain. 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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816105436.gy25...@codelibre.net
