Re: Daemons in schroot or how to start chroot automatically
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
Reply to: