/sbin/rc tries to reboot the system if it cannot mount / from /etc/fstab /etc/init.d/<anything> <somecommand> runs dependency check which triggers /sbin/rc as a result, if one does the following: mkdir /mychroot tar xzvf stage3-xxx.tgz -C /mychroot chroot /mychroot /etc/init.d/sshd start # for example to generate ssh keys user is presented with: <some errors> Enter root password for mainenance (^D to conitnue): pressing ^D (or in fact even killing the chroot process) results in entire (host) system going for reboot. Reproducible: Always Steps to Reproduce: Expected Results: Either notice that /sbin/rc or /etc/fstab or something is actually in chroot, or Correct sysvinit (reboot, shutdown) not take the whole system down from within chroot jail. this happened to me several times (bad), one of which on a remote production server (really very bad indeed)
Is there anyway in a userland to detect if we are in a chroot or not?
OK, for Linux I can check to see if /proc/1/root exists. My tests show that this never exists in a chroot, even with proc mount. I was unable to test if it exists if proc was mounted inside the chroot though.
We can add this to a few init scripts, such as checkroot depend() { keywords nochroot } Basically, rc will mark the service as started if we're in a chroot but not actually start it. You will, however, be able to start the service manually. Once a version that supports keywords as described on bug #198494 is in the tree.
we've already shown in the past that there isnt a reliable way to detect a chroot look at all the history of the udev crap
(In reply to comment #4) > we've already shown in the past that there isnt a reliable way to detect a > chroot > > look at all the history of the udev crap Got a pointer to this history?
the end result was "not doable", so i dont think it's relevant the interesting point is that you cant say "if in chroot, do nothing" because some systems (like one of mine) actually boot up in a chroot, so having rc short circuit everything is incorrect
I suppose a stage tarball could automatically mark some services as "started", which would also solve the initial bug report. Also, as technically there are no critical services anymore the only reboot occurs in sysinit - and there are special checks to ensure that sysvinit (or bsd init) has called rc shutdown|single|restart - this bug should not be relevant with baselayout-2 / openrc. But I've not tested that :)
if you want correct behavior with baselayout-1, sync the init.d state dir yourself