3

For example we have exotic file system on the disk and in order to load system we need mount root filesystem. But we cannot because there is no suitable driver exists in kernel image.

Let me explain how I understand kernel and initrd.

  1. When kernel is compiled we can select different modules to be included into kernel image (one single file)
  2. For example my root filesystem is reiserfs and I have configured kernel not to include module for this filesystem
  3. In this case kernel doesn't know how to mount such filesystem and it needs some help -> so load initramfs into the memory
  4. Find proper module in ram fs (lib/modules or etc)
  5. Load this module to the kernel
  6. Now kernel can mount reiserfs it mounts and than unloads (frees) memory occupied by ramfs

Am I right ?

But I don't understand why do we need initramfs in every distro ( I have seen it in every distro I have ever installed) if most of specific drivers are already present in kernel image (single file) furthermore we only need drivers for filesystems when kernel boots other drivers can be loaded from the filesystem after it is mounted.

So is it really essential part of any distro ?

P.S What is used more often initramfs or initrd and why ?

4

The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.

An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.

The "Rationale" section of the Wikipedia page on initrd has more examples.

initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.

A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.

2

There are many reason to have an initramfs, some are below.

  1. When you need have a separate /usr,/var as some distros depends on having these directories in /
  2. When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
  3. When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
  4. When using dmraid on /
  5. When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)

I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.

  • Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for. – fpmurphy Jun 10 '16 at 9:50
1

I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.

However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd ;-).

Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.

An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.

Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.