linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* pivot_root off an initramfs broken
@ 2003-12-04  0:04 Martin Hicks
  2003-12-04  0:30 ` H. Peter Anvin
  0 siblings, 1 reply; 2+ messages in thread
From: Martin Hicks @ 2003-12-04  0:04 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]


This is the conclusion that I've come to.  For background please see:

http://www.zytor.com/pipermail/klibc/2003-November/000223.html
which finishes up here:
http://www.zytor.com/pipermail/klibc/2003-December/000254.html


The executive summary is this:

If I boot a 2.6 kernel that first execs /sbin/kinit on the initramfs,
does some setup (mostly to find the real root filesystem), then
pivot_roots over to the real root filesystem and execs /sbin/init the
kernel spins inside check_mnt() while mounting /proc in the initscripts.

The reason is because the vfsmount structures for the root filesystem
looks like this:

mnt->mnt_devname = /dev/root                    (this is good)
mnt->mnt_parent->mnt_devname = rootfs           (this is good, I think)
mnt->mnt_parent->mnt_parent->mnt_devname = /dev/root   (wrong!)

I think it's in pivot_root that something is going wrong.

The attached patch fixes the problem, but is just a hack.
Any comments on how to really fix this?

TIA,
mh

-- 
Martin Hicks                Wild Open Source Inc.
mort@wildopensource.com     613-266-2296


[-- Attachment #2: namespace.diff --]
[-- Type: text/x-patch, Size: 586 bytes --]

===== fs/namespace.c 1.50 vs edited =====
--- 1.50/fs/namespace.c	Tue Oct  7 21:52:02 2003
+++ edited/fs/namespace.c	Wed Dec  3 18:48:59 2003
@@ -1064,6 +1064,9 @@
 	detach_mnt(user_nd.mnt, &root_parent);
 	attach_mnt(user_nd.mnt, &old_nd);
 	attach_mnt(new_nd.mnt, &root_parent);
+	if (new_nd.mnt == new_nd.mnt->mnt_parent->mnt_parent &&
+	    new_nd.mnt != new_nd.mnt->mnt_parent)  /* initramfs loop */
+		new_nd.mnt->mnt_parent->mnt_parent = new_nd.mnt->mnt_parent;
 	spin_unlock(&vfsmount_lock);
 	chroot_fs_refs(&user_nd, &new_nd);
 	security_sb_post_pivotroot(&user_nd, &new_nd);

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: pivot_root off an initramfs broken
  2003-12-04  0:04 pivot_root off an initramfs broken Martin Hicks
@ 2003-12-04  0:30 ` H. Peter Anvin
  0 siblings, 0 replies; 2+ messages in thread
From: H. Peter Anvin @ 2003-12-04  0:30 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <1070496272.8280.443.camel@plato.i.bork.org>
By author:    Martin Hicks <mort@wildopensource.com>
In newsgroup: linux.dev.kernel
> 
> If I boot a 2.6 kernel that first execs /sbin/kinit on the initramfs,
> does some setup (mostly to find the real root filesystem), then
> pivot_roots over to the real root filesystem and execs /sbin/init the
> kernel spins inside check_mnt() while mounting /proc in the initscripts.
> 

The initramfs is the "real root" -- you shouldn't pivot_root from it,
instead you should mount the new root on top of it.

This makes cleaning up a bit of an issue -- the proposed rootfs
mount_single patch takes care of that -- but it can also be done by
leaving a cleanup process with cwd inside the initramfs with would use
relative paths to clean up.

Something like this:

	  mount / /dev/real_root_whatever
	  ( rm -rf . ) &
	  exec /sbin/init "$@"

	  -hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-12-04  0:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-04  0:04 pivot_root off an initramfs broken Martin Hicks
2003-12-04  0:30 ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).