LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   difference between initrd and vmlinuz images (https://www.linuxquestions.org/questions/linux-server-73/difference-between-initrd-and-vmlinuz-images-892868/)

samtoddler 07-21-2011 03:03 AM

difference between initrd and vmlinuz images
 
Hi,

Can anyone tell me the difference between initrd images and vmlinuz images. I've gone through many documents,but didn't got an exact answer.

thanx
samtoddler

EricTRA 07-21-2011 03:13 AM

Hello,

This post here at LQ explains it in very understandable terminology in my opinion: http://www.linuxquestions.org/questi...0/#post2920395.

Kind regards,

Eric

samtoddler 07-21-2011 03:25 AM

difference between initrd and vmlinuz images
 
Quote:

Originally Posted by EricTRA (Post 4420899)
Hello,

This post here at LQ explains it in very understandable terminology in my opinion: http://www.linuxquestions.org/questi...0/#post2920395.

Kind regards,

Eric

thanx for comment
What if I've comipled all the modules required for the system in the kernel.Do I still need initird image.

thanx samtoddler

syg00 07-21-2011 04:00 AM

No.

samtoddler 07-21-2011 04:07 AM

difference between initrd and vmlinuz images
 
Quote:

Originally Posted by syg00 (Post 4420939)
No.

can you please tell me in more detail why is it so.
as far sa I know initrd is must because kernel is not in memory so make it in memory initrd provide basic modules to access the
filesystem and then load the kernel.

thanx
samtoddler

Nominal Animal 07-21-2011 08:10 AM

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?

syg00 07-21-2011 08:35 AM

Very nice explanation - may cause some confusion with regard to the different init being discussed; the initrd one and the "real" one . It should perhaps be added that the only requirement of an initrd is to ensure that all the necessary resources (modules) are available so the kernel can mount the root filesystem.
If it's all compiled in, not an issue - other external issues (hibernation, PXE ...) ignored.


All times are GMT -5. The time now is 05:51 PM.