From: "Kevin P. Fleming" <kpfleming@cox.net>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: Oliver Tennert <tennert@science-computing.de>,
linux-kernel@vger.kernel.org
Subject: Re: Kernel setup() and initrd problems
Date: Thu, 13 Mar 2003 11:05:43 -0700 [thread overview]
Message-ID: <3E70C877.7040804@cox.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0303131051160.7342-100000@chaos.physics.uiowa.edu>
Kai Germaschewski wrote:
> I think whoever came up with that just got the idea of pivot_root wrong.
> The idea was to get rid of the initrd special case. It should be possible
> to do the following, though I didn't work out the details:
>
> Tell the kernel that our root dev is /dev/ram and give it an initrd which
> isn't really a classical initrd (with /linuxrc on it), but instead has a
> /sbin/init which is similar to the linuxrc above.
>
> Then, the kernel will load the image into /dev/ram, mount that as root and
> exec /sbin/init, skipping the special initrd code.
>
> Now, we have to take care of all the remaining business in /sbin/init
> ourselves, i.e.
>
> - load modules
> - mount real root
> - pivot root to real root
> - execve /sbin/init on real root, pointing stdin/out/err to /dev/console
> on the new root
> - umount and free our first (ramdisk) root
I have used exactly this process, and it works as you expect. In this
situation you're not really using the initrd as a "classic" initrd, it's
just a temporary root filesystem. The kernel has no idea what the real
root is going to be, and that determination isn't made until the
initrd's scripts decide what to mount and then pivot_root to it.
Much cleaner than the old way.
next prev parent reply other threads:[~2003-03-13 17:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-13 8:42 Kernel setup() and initrd problems Oliver Tennert
2003-03-13 17:16 ` Kai Germaschewski
2003-03-13 18:05 ` Kevin P. Fleming [this message]
2003-03-14 19:12 ` H. Peter Anvin
2003-03-14 19:27 ` Chris Friesen
2003-03-14 19:43 ` H. Peter Anvin
2003-03-14 20:04 ` Chris Friesen
2003-03-14 20:42 ` H. Peter Anvin
2003-03-14 20:53 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E70C877.7040804@cox.net \
--to=kpfleming@cox.net \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tennert@science-computing.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox