Initrd Support Could Finally Be On Its Way To Being Removed From The Linux Kernel
Initrd Support Could Finally Be On Its Way To Being Removed From The Linux Kernel
11 comments
-
The current one is initramfs in case you too are old enough to get them confused
-
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.
-
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.
-
-
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.
-
-
Honestly, I thought initramfs was initrd
-
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.
-
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.
11 comments