<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Shachar Shemesh wrote:
<blockquote cite="mid:4A533461.7040108@shemesh.biz" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Ilya A. Volynets-Evenbakh wrote:
<blockquote cite="mid:4A532F79.4020802@total-knowledge.com"
type="cite"><br>
<pre wrap=""><!---->I think it's the other way around - if you exit from your linuxrc when
running from initramfs,
it'll continue on with standard boot sequence, while ending linuxrc in
initrd will panic the kernel
with "Trying to kill PID 1" error.
</pre>
</blockquote>
An initramfs exists for any 2.6 kernel. Sometimes it's just a very
small one. The way the kernel decides whether to execute it is to check
for a */init* file in it. If it finds one, it runs it. If not, it does
not.<br>
<br>
As such, if you have a /linuxrc file in your initramfs, and it simply
exists at the end, all that will happen is that the kernel will not
find a /init and will skip running anything from the initramfs at all.
In that sense you might be said to be right that if your linuxrc
exists, the normal boot sequence will continue.<br>
<br>
The history goes something like this:<br>
Originally, the drivers for the root file system had to be compiled
into the kernel. This was very difficult, if not impossible, for
distribution kernels, as the list of potential drivers included, well,
everything, and the kernels were just too big. Then the idea of initrd
came - we compile the drivers only for the ram disk and the initrd file
system (typically, cramfs) into the kernel. The initrd loads the
relevant drivers into the kernel and quits, restoring the original boot
sequence. Then someone pointed out that, sometimes, an initrd is all
you need. The convention then arose to pass "boot=/dev/ram0" to the
kernel, which tells it that the initrd stage is the last one. It then
became common to put the real "boot=" option on the kernel command
line, but then, from initrd, to load the values for "/dev/ram0" into
the proc entry for the boot device from linuxrc, manually mount the
real root file system, make it the root file system using pivot_root,
and exec init from there.<br>
<br>
Then, for 2.6, people figured that if this is what you normally do
anyways, there is no point in carrying around the drivers for the ram
disk and cramfs (compiled into the kernel, which means it cannot be
unloaded). Instead, use the much lighter tmpfs file system, and use a
cpio archive for the actual files. The tmpfs file system was made
mandatory, whether initramfs was used or not, and so you couldn't move
it from the root (only mount on top of it). This means you cannot use
pivot_root, and switch_root was invented. While at it, the "legacy"
boot sequence was removed. Assuming, as Gilad seems to, that we leave
initrd is out of the discussion, your options are either run an
initramfs and perform the entire root mounting from the /init script
there, or compile the root file system drivers into the kernel and let
the kernel mount them using the boot= kernel option.<br>
<br>
Shachar<br>
<br>
<pre class="moz-signature" cols="72">--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.lingnu.com">http://www.lingnu.com</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Linux-il mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a>
<a class="moz-txt-link-freetext" href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a>
</pre>
</blockquote>
Many thanks to all of you,<br>
<br>
Due to some glitch, initramfs image does not have /init script. <br>
This is the reason boot stopped. (and the required device driver was
compiled in kernel, so the device was created)<br>
<br>
<br>
<br>
Thanks you Again<br>
Lev.<br>
<br>
BTW, is there any way to track next line from /proc/devices <br>
8 sd <br>
<br>
which modules actually made possible access to devices 8,0 ....
???<br>
<br>
<br>
</body>
</html>