On Mon, 05 Sep 2005, Simon J. Gerraty wrote:
> If you are already chrooted the fsck and remount of / will fail
> because the device is busy, using the actual raw device won't help.

Yes, but the outer /etc/rc can do that before the chroot.  When the
inner /etc/rc (inside the chroot) tries to fsck+remount again, it will
fail, but it can ignore the errors, or even anticipate the errors and
not bother trying to do the operations that will fail.  When I boot
using this scheme (in a virtual machine under qemu), it all works just
fine; if I am not paying attention, I don't even notice the error
messages scrolling past.

> The kernel makes a speciall allowance for / to allow this operation at
> boot but that won't work once you're chrooted.

I can't find any code that prevents you from doing
"mount -u -o ${options} /" as often as you like.

> Attempting to remount the boot device within the chroot env would also
> require some very scary changes to the kernel.

Well, re-mounting the root device elsewhere (even without chroots)
already gives an error.  Do chroots make this worse?

# mount | grep "on / type"
/dev/wd0a on / type ffs (local)
# mount -t ffs /dev/wd0a /
mount_ffs: /dev/wd0a on /mnt: Device busy
# mount -t null / /mnt
mount_null: / (/) and /mnt (/mnt) are not distinct paths

--apb (Alan Barrett)