Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
Well, too many replies, thank you all :)I could solve my problem using strace to detect where init stops (of course I had to recompile init allowing to not be PID 1). Looking at the errors reported on strace log I could see that the problem was with the /dev/null and /dev/console doesn't exists so I've changed my init script to create they both and now everything works like a charm :) Oh, and actually I'm using switch_root from busybox which is very similar to pivot_root.Again, tks for all replies,Claudinei MatosOn 6/21/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/21/06, Hans-Werner Hilse [EMAIL PROTECTED] wrote: chroot. OK, I definately stand currected. But I was pretty sure I once did this from initramfs. But that was admittedly back in the 2.6.10 days, I think.Yeah, I did it too! ;-Worked great until I tried to usefbsplash/bootsplash, which did a 'mount --move'as part of it'ssetup.Cheers,-Richard-- gentoo-user@gentoo.org mailing list-- Claudinei Matos[EMAIL PROTECTED]55-21-81980605
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
On 6/16/06, Claudinei Matos [EMAIL PROTECTED] wrote: I'd created an initramfs wich mount the nfs share and do the pivot_root (actually switch_root from busybox) but the problem is exactly at this moment, 'cause when I try to do the switch_root and start the real init from the nfs share, the system appears to freeze but after some seconds it do print a message Rebooting System and just reboot the machine. Sorry for the late reply...I've been on offline (vacation) for several days. pivot_root is specifically *not* allowed from an initramfs environment. What you want to do is simply mount the new root filesystem, chroot into it, and execute init. Something like: cd /new_root ; exec ./bin/chroot . ./sbin/init $@ dev/console dev/console 21 If you are *extremely* tricky, and use a symlinked /lib directory, you can actually delete everything from the initramfs before doing the chroot/init calls. Let me know if you need some more details on this. HTH, -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
Hi, On Wed, 21 Jun 2006 13:50:12 -0700 Richard Fish [EMAIL PROTECTED] wrote: pivot_root is specifically *not* allowed from an initramfs environment. What you want to do is simply mount the new root filesystem, chroot into it, and execute init. Something like: cd /new_root ; exec ./bin/chroot . ./sbin/init $@ dev/console dev/console 21 If you are *extremely* tricky, and use a symlinked /lib directory, you can actually delete everything from the initramfs before doing the chroot/init calls. Let me know if you need some more details on this. 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. 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. 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 Note that I assume /mnt/stagetwo exists in initramfs (as well as modprobe, mount, pivot_root and reboot) and /mnt/initramfs exists in the to-be-mounted fs. Note that the last point may prevent pivot_root'ing in a scenario where an NFS root fs is desired (because I'm not sure if it can have mounts in it, but that would be needed for proc, sys and dev, too, so it _may_ work here, too). The call to /sbin/init happens in the new fs because pivot_root manipulates the namespace of the calling process. Exec'ing is important so that /sbin/init gets PID 1 and we don't have a process which depends on the initramfs anymore, so we can unmount it at a later point. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
On 6/21/06, Hans-Werner Hilse [EMAIL PROTECTED] 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@gentoo.org mailing list
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
On 6/21/06, Richard Fish [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=4857 My final comments on that bug are based on the attached email -1,000,000 points for not including the email... -Richard From - Thu Aug 18 13:01:31 2005 X-Account-Key: account1 X-UIDL: f9050c2168cec49d57cb44456faba2d8 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Apparently-To: [EMAIL PROTECTED] via 66.218.93.224; Thu, 18 Aug 2005 10:24:05 -0700 X-Originating-IP: [65.172.181.4] Return-Path: [EMAIL PROTECTED] Authentication-Results: mta107.pa.mail.re2.yahoo.com from=osdl.org; domainkeys=neutral (no sig) Received: from 65.172.181.4 (EHLO smtp.osdl.org) (65.172.181.4) by mta107.pa.mail.re2.yahoo.com with SMTP; Thu, 18 Aug 2005 10:24:05 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j7IHO3jA023758 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 18 Aug 2005 10:24:03 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j7IHO2iP028972; Thu, 18 Aug 2005 10:24:02 -0700 Date: Thu, 18 Aug 2005 10:22:42 -0700 From: Andrew Morton [EMAIL PROTECTED] To: Miklos Szeredi [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: pivot_root-circular-reference-fix-2.patch Message-Id: [EMAIL PROTECTED] X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 tests= X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.45__ X-MIMEDefang-Filter: osdl$Revision: 1.114 $ X-Scanned-By: MIMEDefang 2.36 cw viro: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/broken-out/pivot_root-circular-reference-fix-2.patch viro WTF? cw -EWTFWTF? viro akpm: patch is an utter bullshit viro akpm: we are _NOT_ allowing to change namespace root viro not with pivot_root(), not with anything else viro moreover, I distinctly remember having such check in sys_pivot_root() viro where the hell had it gone? cw viro: what about depricate pivot_root since it's the source of so much angst? (i used it myself and im not sure how to avoid it here but there must be a way) * viro goes to look through history viro LARTs are needed, apparently olaf or -einval for pivot_root on rootfs (if thats detectable) viro of course it is -- plai_ ([EMAIL PROTECTED]) has joined #kernel viro sigh... viro what we should do is prohibit any mount activity on detached vfsmounts, *period* viro akpm: please, consider that patch in its current form strongly vetoed crlf viro: if you restructure vfsmount trees to not depend on namespaces, there's no need for that restriction akpm viro: OK. You were cc'ed on it a lot at the time.. viro akpm: -*-Mutt: /var/spool/mail/viro [Msgs:23748 New:21604 Del:83 Post:31 128M]---(threa
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
Hi, On Wed, 21 Jun 2006 15:51:51 -0700 Richard Fish [EMAIL PROTECTED] wrote: 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. OK, I have to apologize. I totally missed that you were exec'ing chroot. OK, I definately stand currected. But I was pretty sure I once did this from initramfs. But that was admittedly back in the 2.6.10 days, I think. Of course in this case /sbin/init also gets PID 1. -hwh (happy to not have been the one complaining to the kernel devs :-) and also forgetting to send attachments. I need a plugin that saves me from doing this, e.g. searching for the word attachment and complaining if there isn't one...) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] initramfs, network diskless boot, init process, problems with switchroot (pivot_root)
On 6/21/06, Hans-Werner Hilse [EMAIL PROTECTED] wrote: chroot. OK, I definately stand currected. But I was pretty sure I once did this from initramfs. But that was admittedly back in the 2.6.10 days, I think. Yeah, I did it too! ;- Worked great until I tried to use fbsplash/bootsplash, which did a 'mount --move' as part of it's setup. Cheers, -Richard -- gentoo-user@gentoo.org mailing list
