the next in a series of questions as i try to clarify the underlying
details of initramfs/initrd logistics.
PART 1:
from "make menuconfig", i can see under the "General setup" menu
entry that you select initramfs support via the "Initial RAM
filesystem and RAM disk (initramfs/initrd) support" entry, which
selects the config variable CONFIG_BLK_DEV_INITRD. so far, so good.
now, as i read it, that setting enables support for *both* an
in-kernel (cpio-format) initramfs image, as well as an *external*
(again, cpio-format) initial ramdisk -- the one you would supply via
the "initrd=" command line parameter, correct? in other words, that
one menuconfig selection dictates support for either *both* of those
features, or *neither* of them; there's no combination of
configuration that allows you to select one but not the other.
in addition, the above gives you only *cpio* format external ramdisk
support. if you want the older, mountable ext2-format initrd images,
you need to select CONFIG_BLK_DEV_RAM as well but, AFAIK, most default
configs already have that, anyway. is all of that correct?
(as an aside, i wish the config variable BLK_DEV_INITRD had a
different name, since it has some historical baggage -- it makes one
think of the days when *all* you had was the external, ext2-format
initrd image. it would have been nice if that had been renamed to
something like, oh, CONFIG_INITRAMFS. but that's just griping.
moving on.)
PART 2:
now i want to clarify what happens if you choose to *not* select
initramfs support at all. if you don't select CONFIG_BLK_DEV_INITRD,
then this bit of init/Makefile kicks in:
ifneq ($(CONFIG_BLK_DEV_INITRD),y)
obj-y += noinitramfs.o
else
obj-$(CONFIG_BLK_DEV_INITRD) += initramfs.o
endif
what noinitramfs.c does is explicitly create a trivial root
filesystem (with nothing but /root and /dev/console), at which point
the kernel will go directly to trying to mount the final root
filesystem, correct? that is, if you've configured your kernel with
*no* initramfs support, the set of steps will be:
* kernel goes thru early part of boot process
* kernel uses code in init/noinitramfs.c to create initial, tiny
root filesystem
* kernel then runs code in init/main.c:
if (execute_command) {
run_init_process(execute_command);
printk(KERN_WARNING "Failed to execute %s. Attempting "
"defaults...\n", execute_command);
}
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
which means that, if you have no initramfs support, you have to supply
a self-contained root filesystem to the kernel that's ready to go, and
the only freedom you have while booting is with "init=" to change the
initial program to be run. is that about right? is there any other
way to affect the boot sequence if you have no initramfs support? it
doesn't look like it.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
