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
