Is it possible to boot the Linux kernel without creating an initrd image? [closed]

Answer 1

The initrd contain the modules required to understand the root filesystem, and thus be able to access the normal store of kernel modules.

If your kernel is compiled with all that code built-in, rather than as modules, then an initrd shouldn't be required.

Answer 2

I have a custom kernel in my Debian Linux box. I compile kernels myself and then put them to knowledge of dpkg system.

When configuring the kernel, first thing I remove is initrd. I know how my rig accesses root filesystem (serial ATA, SCSI support, SCSI disk and ext4) so I compile them into kernel. Other modules are accessible from root filesystem /lib/modules

This has saved me many times. If something goes wrong, kernel drops me to a working prompt I can use to access my rig. If initrd goes broken, I need a boot stick (that is missing usually). Now when Kernel knows what to do to get to boot prompt, I can use my system tools just usually to fix the problem.

Answer 3

Yes, you can boot a system without an initrd image.

initrd image is either a gzipped ramdisc image, or (more commonly nowadays) a gzipped .cpio image.

In the latter case, the .cpio is expanded into a filesystem called initramfs.

If the .cpio image isn't present, the kernel uses a built-in image instead, which contains just a few special files (such as /dev/console, /dev/null and a few directories), but no binaries.

The kernel then uses some built-in logic and command-line options to try to find and mount is "real" root filesystem, which is mounted "over" the initramfs and therefore hides it.

This "legacy" boot system is mostly not used in modern distributions.

Answer 4

initrd/initramfs is optional and not a requirement. bzImage is the pure kernel image and can be booted directly by the bootloader. However it might be neccesary to execute some tasks (loading filesystem modules, drivers for disk access, mounting the root file system from some exchangeable media without fixed name/path, etc.) that would usually require access to a filesystem and userspace tools.

That's what initramfs is for: It is a CPIO archive that gets attached to the kernel image (the kernel image is the container for the initramfs not other way round) either in the kernel image itself, or by the bootloader at boot time.

That CPIO archive contains an initial rootfs with the modules required to setup all devices to access the proper root filesystem and some programs to identify those devices, load the modules, do some other startup tasks remount the proper root file system to / and start /sbin/init

initrd is similar, with the main difference that it is an filesystem image, that may be and usually is compressed. The kernel must have support for the filesystem used built in and will mount this image as the initial /.

Since CPIO is simpler by several orders of magnitudes, initramfs is prefered over initrd, as this saves both the requirement for any filesystem modules being built in and also makes initramfs creation easier. Instead of having to create an ext2 image, loopdevice mount and populate it, it boils down to a simple archive creation, not unlike using tar.

However if you compile your kernel with all required drivers and modules built into the kernel image, and your root file system device has a fixed name in the system you don't need a initramfs as the kernel can do things by itself then.

Answer 5

Minimal QEMU + Buildroot example

Here is a minimal concrete example that shows that initrd is not mandatory: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/0b4f156b1b536a89c90882ed8ce551abcd3780af#initrd

With that setup, we can easily run two working QEMU commands of type:

qemu-system-x86_64 -drive file=rootfs.ext2

and:

qemu-system-x86_64 -initrd rootfs.cpio

Where:

• rootfs.ext2 and rootfs.cpio are basically the same root filesystem, but in different formats
• the first command has a hard drive and no -initrd
• the second command an -initrd but no hard drive

In both cases, Linux boots fine, except that in the -initrd system, file writes are not persistent since everything is in memory.