Initrd and initramfs with OE: snippet 1

One of the former weak areas of OpenEmbedded was creation of small, fine-tuned, (hand)optimized initrd and initramfs images. However, during few last months, the situation vastly improved, and by now OE offers all tools needed to create initrd/initramfs per your purposed and requirements. I would like to describe them, and as that would be quite a bit of contents, going to do it describing features one by one, in "snippets".

The first is:

Building initramfs with OE and everything you wanted to know about initramfs but didn't bother to figure out yourself.

IMAGE_FSTYPES = "cpio.gz"

Yes, that's all what you need to create an initramfs image, voila. After that, you can use resulting image instead of conventional initrd (in ext2 or some other format). For the kernel to be able to boot it, you need to have CONFIG_BLK_DEV_INITRD=y in its config (contrary to its name, this option actually means "support external initrd *or* initramfs images"). As initramfs support is unconditionally builtin into kernel, you don't need any filesystem enabled for initramfs support.

(Note that above is written for standalone initramfs image which is used in initrd-like manner. Support for initramfs which are linked into the kernel image so far is not provided OE, but would be pretty easy to add. Still, it's of more interest to vendors which work on specific products than OpenSource distros. By the way, mentioned config option is not required for builtin initramfs.)

Note that execution of initramfs starts with /init. If you want to rebuild initrd (or otherwise conventional rootfs image) as initramfs, you'll need to pass following parameter on kernel command line to have it started properly: "rdinit=/sbin/init".

Final note is that contrary to popular belief, initramfs does not completely covers and supersedes initrd functionally. Initramfs has relatively big memory requirements, which precludes usage of big initramfs images on low-memory systems. Specifically, initramfs is compressed, and needs to be uncompressed during startup, which already limits its size to at most half of the available RAM. But actually, ramfs, which is used as backing store for initramfs content, is pretty inefficient for such type of content (static), and that imposes even more limits. Also, my experiments show that kernel has poor error handling while uncompressing initramfs, and out of memory condition makes it just hang. So, when you need to fill memory up with lots of content, nothing would replace an initrd with builtin compression like cramfs or squashfs. Granted, that's rather adhoc need.