I wonder why we need stuff like an initrd or initramfs and can’t just put everything into a folder. Might save some space and make it more obvious what’s in it and how it works.
You actually can boot without one—the system I’m typing this on right now has none. However, you have to keep the system simple enough that the root partition can be mounted without requiring anything not built into the kernel. That means your root partition can’t be encrypted or RAIDed, and you can’t build the support for the filesystem it uses as a module, which can mean a custom kernel. Most people don’t want to bother.
The trick with initramfs and initrd is that the kernel does not read them into memory. By the time the kernel boots, they are already in memory. This let’s you move a lot of initializing logic out of the kernel and into userspace. In some sense, this just moves the problem to the bootloader. But the bootloader already has to load the kernel, so that is no real loss.
This is also incredibly useful for stateless VMs. You do not need to futz around with virtual drives. Just put everything you need into a CPIO archive, then pass that and and your kernel into QEMU (or your emulator of choice) and it will just work.
Initramfs’s main purpose is to load enough of a system to be able to load/boot the kernel and everything else from the hard disk. It’s also used for more complex boot scenarios such as loading LUKS and providing a password prompt if the root partition is encrypted.
This has absolutely nothing to do with EFI booting and the kernel does not sit in the initramfs. With EFI the bootloader is just an executable in a FAT32 partition. The kernel is its own file either on the same partition or on one readable by the bootloader. The initramfs is also a single file and contains additional kernel modules and like you said programs like LUKS.
I’m questioning the single file for initramfs concept.
The reason for initramfs is because if you build your block or filesystem drivers as modules the kernel can’t boot without loading the modules and can’t load the modules without said modules and therefore causing a chicken and egg problem. Reading a folder without all necessary boot drivers just isn’t possible. That’s why the bootloader is responsible for loading initramfs into system memory, the kernel can read it with 0 drivers required. Getting rid of it can be done but ALL of your boot drivers need to be statically linked into the kernel image so that the kernel doesn’t need any modules to get the rootfs mounted. Ironically EFI can be used to obsolete initramfs in theory since the kernel can read data from the ESP without any drivers being required so putting modules in a folder on the ESP would work for EFI enabled systems
Thanks. I remember the big fat reminders to not forget to include the correct filesystem drivers when building your own kernel. Back before Mr Reiser decided to become a murderer.
I wonder why we need stuff like an initrd or initramfs and can’t just put everything into a folder. Might save some space and make it more obvious what’s in it and how it works.
You actually can boot without one—the system I’m typing this on right now has none. However, you have to keep the system simple enough that the root partition can be mounted without requiring anything not built into the kernel. That means your root partition can’t be encrypted or RAIDed, and you can’t build the support for the filesystem it uses as a module, which can mean a custom kernel. Most people don’t want to bother.
How do you get the folder?
The trick with initramfs and initrd is that the kernel does not read them into memory. By the time the kernel boots, they are already in memory. This let’s you move a lot of initializing logic out of the kernel and into userspace. In some sense, this just moves the problem to the bootloader. But the bootloader already has to load the kernel, so that is no real loss.
This is also incredibly useful for stateless VMs. You do not need to futz around with virtual drives. Just put everything you need into a CPIO archive, then pass that and and your kernel into QEMU (or your emulator of choice) and it will just work.
That’s basically what EFI booting does.
Initramfs’s main purpose is to load enough of a system to be able to load/boot the kernel and everything else from the hard disk. It’s also used for more complex boot scenarios such as loading LUKS and providing a password prompt if the root partition is encrypted.
This has absolutely nothing to do with EFI booting and the kernel does not sit in the initramfs. With EFI the bootloader is just an executable in a FAT32 partition. The kernel is its own file either on the same partition or on one readable by the bootloader. The initramfs is also a single file and contains additional kernel modules and like you said programs like LUKS.
I’m questioning the single file for initramfs concept.
The reason for initramfs is because if you build your block or filesystem drivers as modules the kernel can’t boot without loading the modules and can’t load the modules without said modules and therefore causing a chicken and egg problem. Reading a folder without all necessary boot drivers just isn’t possible. That’s why the bootloader is responsible for loading initramfs into system memory, the kernel can read it with 0 drivers required. Getting rid of it can be done but ALL of your boot drivers need to be statically linked into the kernel image so that the kernel doesn’t need any modules to get the rootfs mounted. Ironically EFI can be used to obsolete initramfs in theory since the kernel can read data from the ESP without any drivers being required so putting modules in a folder on the ESP would work for EFI enabled systems
Thanks. I remember the big fat reminders to not forget to include the correct filesystem drivers when building your own kernel. Back before Mr Reiser decided to become a murderer.