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.
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.
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.
发布评论
评论（5）
initrd/initramfs 是可选的，而不是必需的。 bzImage是纯内核镜像，可以直接由bootloader启动。然而，可能需要执行一些通常需要访问文件系统和用户空间工具的任务（加载文件系统模块、磁盘访问驱动程序、从某些没有固定名称/路径的可交换介质安装根文件系统等）。
这就是 initramfs 的用途：它是一个 CPIO 存档，附加到内核映像（内核映像是 initramfs 的容器，而不是其他方式），可以在内核映像本身中，也可以通过启动时的引导加载程序。
该 CPIO 存档包含一个初始 rootfs，其中包含设置所有设备以访问正确的根文件系统所需的模块，以及一些用于识别这些设备、加载模块、执行其他一些启动任务的程序，将正确的根文件系统重新挂载到 / 并启动 /sbin /init
initrd 类似，主要区别在于它是文件系统映像，通常可能被压缩。内核必须支持内置的文件系统，并将此映像作为初始 / 挂载。
由于 CPIO 简单了几个数量级，因此 initramfs 比 initrd 更受青睐，因为这既节省了对内置任何文件系统模块的要求，也使 initramfs 的创建更容易。它不必创建 ext2 映像、loopdevice 挂载并填充它，而是归结为简单的存档创建，与使用 tar 没有什么不同。
但是，如果您使用内置于内核映像中的所有必需驱动程序和模块来编译内核，并且您的根文件系统设备在系统中具有固定名称，则您不需要 initramfs，因为内核可以自行执行操作。
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.
最小 QEMU + Buildroot 示例
这是一个最小的具体示例，表明 initrd 不是必需的：https://github.com/cirosantilli/linux-kernel-module-cheat/tree/0b4f156b1b536a89c90882ed8ce551abcd3780af#initrd
通过该设置，我们可以轻松运行两个类型的 QEMU 命令：
和：
其中：
rootfs.ext2和rootfs.cpio基本上是相同的根文件系统，但格式不同-initrd-initrd但没有硬盘驱动器在这两种情况下， Linux 启动正常，除了在
-initrd系统中，文件写入不是持久的，因为所有内容都在内存中。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:
and:
Where:
rootfs.ext2androotfs.cpioare basically the same root filesystem, but in different formats-initrd-initrdbut no hard driveIn both cases, Linux boots fine, except that in the
-initrdsystem, file writes are not persistent since everything is in memory.initrd 包含了解根文件系统所需的模块，从而能够访问内核模块的正常存储。
如果您的内核是使用所有内置代码而不是模块进行编译的，则不需要 initrd。
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.
是的，您可以在没有 initrd 映像的情况下启动系统。
initrd 映像可以是 gzip 压缩的 ramdisc 映像，或者（现在更常见）gzip 压缩的 .cpio 映像。
在后一种情况下，.cpio 被扩展为名为 initramfs 的文件系统。
如果 .cpio 映像不存在，内核将使用内置映像，其中仅包含一些特殊文件（例如 /dev/console、/dev/null 和一些目录），但不包含二进制文件。
然后，内核使用一些内置逻辑和命令行选项来尝试查找并挂载“真正的”根文件系统，该文件系统挂载在 initramfs“上方”，因此将其隐藏。
这种“传统”引导系统在现代发行版中大多不使用。
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.
我的 Debian Linux 盒子里有一个自定义内核。我自己编译内核，然后将它们应用到 dpkg 系统的知识中。
配置内核时，我首先删除的是 initrd。我知道我的设备如何访问根文件系统（串行 ATA、SCSI 支持、SCSI 磁盘和 ext4），因此我将它们编译到内核中。其他模块可以从根文件系统 /lib/modules 访问，
这已经救了我很多次。如果出现问题，内核会将我带到一个工作提示符，我可以使用它来访问我的设备。如果 initrd 坏了，我需要一个启动棒（通常会丢失）。现在，当内核知道如何进入启动提示符时，我通常可以使用我的系统工具来解决问题。
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.