lkml.org 
[lkml]   [2005]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: pivot_root doesn't work for me in 2.6.14-rc3
From
Date
Felix, thanks for the forward.  Please "reply to all" when posting on
LKML.

> Hi James,
> > I've found a problem with pivot_root that worked fine in 2.6.13.3, but
> > fails for me, starting in 2.6.14-rc3 (haven't tried rc1 or rc2).
> >
> > This is for LTSP.org (Linux Terminal Server Project) thin clients.
> >
> > In our initramfs, we have a '/init' script that creates a mountpoint for
> > a 2nd ramfs, and i'm trying to pivot_root to that mount point.
> >
> > I'm getting:
> >
> > pivot_root: Invalid Argument
> >
> > This worked perfectly in 2.6.13.3, so I looked at the 2.6.14-rc3 patch,
> > and I found the code in fs/namespace.c that is causing it to fail for
> > me:
> >
> > @@ -1334,8 +1332,12 @@ asmlinkage long sys_pivot_root(const cha
> > 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 */
> > tmp = old_nd.mnt; /* make sure we can reach put_old from
> > new_root */
> > spin_lock(&vfsmount_lock);
> > if (tmp != new_nd.mnt) {
> >
> >
> > The first of the 2 new tests are causing the pivot_root to fail for me.
> > If I comment out those lines, it works again.
> >
> > I'm thinking that somebody put those lines there for a reason, so
> > there's possibly something wrong with the way i've been doing this for a
> > long time, and the tightening of the code has uncovered my problem.
> Miklos Szeredi put these lines there with the following comment:
> "[PATCH] pivot_root() circular reference fix
>
> Fix http://bugzilla.kernel.org/show_bug.cgi?id=4857
>
> When pivot_root is called from an init script in an initramfs
> environment, it causes a circular reference in the mount tree.
>
> The cause of this is that pivot_root() is not prepared to handle
> pivoting an unattached mount. In an initramfs environment, rootfs is the
> root of the namespace, and so it is not attached.
>
> This patch fixes this and related problems, by returning -EINVAL if
> either the current root or the new root is detached."
>
> > I'll explain how we use the initramfs/nfsroot:
> > [...]
> >
> > Somebody recently told me that pivot_root has been put in the 'evil way
> > to do things' category, and that there was a new way, but he couldn't
> > remember what that was.
> googeling a little bit I found the following link:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137005
>
> Felix Möller

Here's a post by Richard Fish explaining how to go about changing root
in initramfs:

> Tim Sia wrote:
>
> >
> >
> > From reading the kernel bug tracker:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=4857
> >
> > I got the impression that pivot_root is not supported from inside
> > initramfs. I can change my initramfs
> > init script not to do pivot root, but the question is will I be able
> > to unumount the initramfs root
> > once I chrooted to the "real root fs" ?
> >
>
> Tim,
>
> The short answer is "no".
>
> I am guessing you want to unmount the initramfs to free the memory it is
> using. You can do this by simply deleting everything from the initramfs
> before you chroot. If you use only statically linked utilities in your
> initramfs, like busybox, then "rm -rf /etc /bin /sbin ..." will do the
> trick. Just make sure your PATH has the bin and sbin directories from
> your real root filesystem listed first, and run hash -r if necessary
> before removing the files. You will also need to symlink /lib to the
> lib directory on your real root filesystem to run dynamically linked
> programs (like chroot) from there. And obviously, be careful that you
> don't "rm -rf" your real root in the process (like I did once)!!
>
> If you use dynamically linked utilities (like me), things are bit more
> complicated, because once you remove /lib/ld-*.so, you cannot run any
> dynamically linked programs. I was able to work around this by creating
> symlinks like this (my real root mounts on /new_root):
>
> /lib -> /new_root/lib
> /new_root/lib -> ../libdir
>
> All my dynamic libraries go in /libdir. The mount of /new_root hides
> the symlink to ../libdir, so as soon as root is mounted and I run hash
> -r, all programs and libraries are automatically loaded from /new_root,
> and I can delete /libdir without any problems.
>
> If you have other questions for me, feel free to ask. Unfortunately
> things are very busy at work, and I will be travelling some next week,
> so I cannot promise 'real-time' answers. But if I can help, I will.
>
> Cheers,
> -Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-08 12:08    [from the cache]
©2003-2011 Jasper Spaans