what's the processing sequence for initramfs during boot?

[Andy Green]

Somebody in the thread at some point said:

>   i've asked about this on the kernel newbies list, but i want to ask
> it here in a slightly different, fedora-centric way.
> 
>   the short form:  what is the precise sequence of kernel boot
> regarding the initramfs (both the internal and external
> possibilities)?
> 
>   the long form:  i'm reading the docs and trying to understand the
> intricacies of the boot sequence regarding how the kernel deals with
> the initramfs.  first, AIUI, every built kernel has an *internal*
> compressed cpio initramfs image although, by default, it's "empty."
> 
>   now, i opened up one of the internal cpio initramfs images that's
> generated when i do my own kernel build, and it contained;
> 
> drwxr-xr-x   2 root     root            0 Sep  7 16:14 /dev
> crw-------   1 root     root       5,   1 Sep  7 16:14 /dev/console
> drwx------   2 root     root            0 Sep  7 16:14 /root
> 
> so it's not truly "empty" but it's pretty close.  anyway, onward.

New to me... but I do know that having an (external) initrd at all is
completely optional.  You can (and I think Debian does it this way; I
certainly do it that way on embedded devices) get the kernel to mount
the filesystem on the /root= partition directly and jump straight into
the init program found on there.  Maybe that is in fact done via this
mysterious internal cyst of an initrd, I don't know.

>   based on my reading, it appears that, when the (2.6) kernel starts
> to run, it allocates a tmpfs-based "rootfs" (always, without
> exception) and copies into it the contents of the internal initramfs
> image (again, without excepton).  is this correct so far?

New to me, I only ever used an external initrd.  Sounds like it could be
pretty cool in a pinch though.

>   once that's done, what happens if there's an executable "init" file
> in the rootfs?  does the kernel simply pass control to that
> executable?  if that's true, that means that there would be no way to
> process regular kernel command-line parameters so, despite what the
> documentation seems to suggest, i can't believe that's what's
> happening.

Not sure what you mean about "no way to process regular kernel
command-line parameters", you can always cat /proc/cmdline from userspace.

>   on the other hand, let's say there's no "init" in that internal
> initramfs.  then, AIUI, the kernel will check whether it's been passed
> a second initramfs image (that would be the one identified in
> /etc/grub.conf via the "initrd" directive).  and in the case of
> fedora, that's the one created by running "mkinitrd" during the kernel
> installation process, which *does* have an "init" script which fires
> up "nash" and takes over, etc, etc.
> 
>   but, once again, even if that happens, at what point in all of that
> would a kernel boot-time parameter of, say, "root=" be processed?
> surely *something* has to deal with that but in all of the above,
> where is that being done?  and do i have the order even remotely
> correct?

The "init" nash script in the fedora external initrd gets nash to sort
out the real root device and to pivot_root into it, near the end of the
init script.

-Andy