Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)

[Richard Fish]

On 6/21/06, Hans-Werner Hilse <hilse@×××.de> wrote:
> On Wed, 21 Jun 2006 13:50:12 -0700
>
> Hm, I'm pretty sure that it is well possible to pivot_root from an
> initramfs. Isn't that the whole point of pivot_root? But you may be
> right that it is not possible for NFS mounts, I never tried that before.

http://bugzilla.kernel.org/show_bug.cgi?id=4857

My final comments on that bug are based on the attached email that I
received from Andrew Morton that made it clear that Al Viro was
opposed to pivot_root being used from an initramfs.  (BTW, viro's
comments are not very polite, but you have to expect such directness
from kernel hackers!)

Note, be sure we are talking about an initramfs here, not an initrd.
>From an initrd it is still possible and supported to use pivot_root.

> In fact, the approach you took is weak. /sbin/init wouldn't run as PID
> 1 in this case which is bad for the situation that the calling script
> (which _has_ PID 1) dies. The kernel would recognize this and reboot
> (and/or panic, not sure). To avoid this, one has to exec the init from
> the script.

No, this works perfectly.  I use it every time I boot my kernel, and
my init *is* PID 1.

The "exec ./bin/chroot" part replaces the shell executing the /init
script with the chroot command, so chroot then becomes PID 1.  Chroot
then does an exec of ./sbin/init so that init becomes PID 1.

>
> So basically it boils down to this /init in the initramfs:
>
> #!/bin/sh
> PATH=/bin:/sbin
> modprobe supermightyrootfsprovidingmodule && \
>   mount -t blahfs /dev/whereitis /mnt/stagetwo && \
>   cd /mnt/stagetwo && \
>   pivot_root . /mnt/initramfs || reboot -f
> exec /sbin/init

Be warned that if you do this, and then you try to "mount --move"
anything, your kernel will probably hang.

But again, in recent kernels, pivot_root *should* be returning -EINVAL
if you do this.  Indeed I just checked my 2.6.16 sources, and the code
that returns EINVAL in sys_pivot_root for unattached mounts is still
there:

        error = -EINVAL;
        if (user_nd.mnt->mnt_root != user_nd.dentry)
                goto out2; /* not a mountpoint */
        if (user_nd.mnt->mnt_parent == user_nd.mnt)
                goto out2; /* not attached */
        if (new_nd.mnt->mnt_root != new_nd.dentry)
                goto out2; /* not a mountpoint */
        if (new_nd.mnt->mnt_parent == new_nd.mnt)
                goto out2; /* not attached */

So unless your the pivot_root program is doing something other than
sys_pivot_root(), I don't see how this can possibly work on a recent
kernel.

-Richard
-- 
gentoo-user@g.o mailing list