LinuxQuestions.org - [SOLVED] difference between initrd and vmlinuz images

No, syg00 is absolutely correct.

vmlinuz files contain the Linux kernel proper.

initrd files are CPIO images, filesystem images.

The boot loader is responsible for loading both the kernel image and the initrd image into memory. They both will be in memory, before the boot loader hands control over to the kernel.

The kernel will receive the address where the initrd is in memory; it will just "interpret" it as if it were a full filesystem, in RAM. (The kernel does actually decompress it first. CPIO is used, because it is simple and robust to implement, requires not too much code, and has all the features needed.)

You can extract an initrd image into current directory using

Code:

zcat /boot/initrd... | cpio -i

You can generate an image from the contents of the current directory and all subdirectories using

Code:

find . | cpio -o | gzip -c > /tmp/new-initrd

The image must be somewhere other than the current directory or any subdirectories, because otherwise cpio may include a partial copy of itself.

An initrd image will contain a script (or program) called /init (I keep the / in front to highlight that it will be in the root directory of the initrd image). That is the only real process the Linux kernel will start, whether an initrd is used or not. It will be process ID 1. If the process ever exits or crashes, kernel will panic -- but it is so rare you are unlikely to ever see that happen. (Okay, the kernel can start [worker processes], and even run /sbin/modprobe to load modules to satisfy module dependencies, I think, but they don't count. They're just slaves working on specific tasks.)

/init is almost always a POSIX shell script, so feel free to extract an image and read it in your favourite text editor. (An initrd /init will later on exec (replace itself) with the normal init, used during normal operation. If you look at your process list, you will always see process 1, named init.)

The main purpose for an initrd image is to prepare the system for the actual operating system, for example to load the modules the kernel should use. These kernel modules are included as files in the initrd image, usually in /lib/modules/kernelversion/ (again, starting from the root of the initrd image). The initrd will then also contain /sbin/modprobe and/or bin/insmod , /lib/ld-linux.so.2 ,and /lib/libc.so.6 , so that the script can load any kernel module it deems necessary.

First, however, /init will create a few additional directories, and mount the special filesystems. These include /proc, /sys, and usually also /dev (using the devtmpfs filesystem). Then, /init will parse the kernel command line, /proc/cmdline. This is the string you can set in the boot loader, defining how you want to start up your system.

It can then check files and directories in /proc, /sys, and /dev to find out which hardware is present and load the appropriate modules, but we have something much better: udev. udev is a hotplug mechanism, where the kernel tells the userspace udev daemon about all the hardware it finds, and about all hardware events later on, like when you plug in or remove something. udev configuration is ordered as rules, usually in /lib/udev/rules.d/, and it takes care of not only loading the necessary kernel modules, but also creating the necessary symlinks and all that.

It is quite possible to have a DHCP client in an initrd, and use for example NFS for all other filesystems. It is often used for thin clients. The kernel command line may then contain the NFS server name and the name for the machine itself, so it can obtain the correct filesystems. As you can see, that requires only a little thought, and a rather simple initrd, to set up and maintain. (Of course, something like this is impossible with most common proprietary operating systems.)

In Linux, resuming from a suspend-to-disk image (usually called "hibernation") is also done in the initrd. If the initrd detects a suspended image, it will resume it instead of continuing with the normal boot. In fact, there is even an utility called kexec, which can start another kernel altogether, without a full reboot (a "warm reboot").

initrd is, for all intents and purposes, a very small operating system image. It has the singular purpose of preparing the system for the actual operating system you want to use. Typically, it will mount the true root filesystem (named in the kernel command line) -- it must contain basic binaries (/bin and /sbin), libraries (/lib and possibly /lib64), and of course configuration files (/etc). Finally, the /init will replace itself with /sbin/init on the actual system, which will continue with mounting the rest of the filesystems, and starting all the services.

Many distros do require an initrd image, even if your kernel has everything built in, and does not support modules at all. In those cases, the initrd is expected to handle all of the other stuff mentioned above -- for example, starting udev, or looking for a hibernation image.

On other distros, an initrd is not needed, and the init scripts can handle the boot from raw kernel (plus root filesystem) up. For example, you can look at Linux From Scratch to see what those init scripts then have to handle.

The Linux kernel really does not care whether you have an initrd, or if your root filesystem can handle the entire init by itself. It is more of a matter of versatility and ease of management; most distributions have automatic scripts which regenerate initrds when new kernels are installed. If you use Busybox, you can pack a quite usable system into an initrd and be done with it -- many routers actually do that, with the initrd stored on a built-in flash chip.

Does this clarify the difference between initrd and vmlinuz for you?