- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
The current one is initramfs in case you too are old enough to get them confused
Honestly, I thought initramfs was initrd
Clearly post does not understand kernel booting. Initrd will never go away, you need a way to tell the kernel to start systemd, which is usually part of initramfs. Both can be compiled as part of the kernel image which can be directly booted from EFI. So basically EFI->Kernel->Decompress InitramFS->Run Initrd Boot Script (usually ends by kicking off SystemD). Initramfs is compressed to reduce boot partition usage, load faster into ram (more noticeable on HDD). You want the bare minimum of kernel modules available in initramfs to load storage drivers, filesystem, LVM, LUKS. Everything else should be modules on the root filesystem, unless it needed for boot. You can compile these static into the kernel too. Generally modules are preferable as they can be unloaded/reloaded if there is an issue. Also updating initramfs modules is annoying. I wrote my own initrd scripts and custom initramfs. You can build it all with bash scripts and configure the kernel to include the payload.
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.
This is fairly clickbaity
Initrd support is not going away any time soon as far as I can tell since it does have a use case. However, initramfs is preferred and should be used unless there is a reason not to.
