4 ms·

In my opinion, this is getting rid of a minor historical relic, instead of the major relic of Linux booting. That ugly hack known as initramfs should have been

In my opinion, this is getting rid of a minor historical relic, instead of the major relic of Linux booting. That ugly hack known as initramfs should have been obsoleted at least ten years ago. It was useful back when you had to worry about keeping all your boot files below the 2gb mark on a disk, but these days, all it does is create a second, ephemeral, userland in a more difficult to debug container. Put the various boot binaries into /bin and /sbin, statically linked, and completely visible to even the running system. Cleaning relics should start with getting rid of entire filesystems that just make it harder to administer a system.

phs2501 10y ago
initramfs isn't (and wasn't) at all about keeping your boot files below the 2gb mark on a disk. It's about actually mounting your root filesystem, either on a fully-modularized kernel where all of your (hundreds of) block drivers are in modules, or where root is coming over a network block device, or a USB disk, or a SAN, or a complex RAID, or an encrypted disk where you need to enter a password or use a hardware token or whatever. Basically, rather than encoding tons and tons of crazy special-purpose logic into the kernel to mount every insane iteration of root filesystem, you just get the bootloader to stick a CPIO image in RAM for the kernel to get at and then use the normal userland tools to do what you want. IMHO, initramfs is the opposite of an ugly hack.
- drvdevd 10y ago
  Though I take your point and mostly agree, is there any reason this couldn't be done with a static boot binary entirely in RAM? Since the kernel is modular anyway, much of the special purpose cruft loaded by the initramfs could just be loaded and unloaded with a boot script of some kind right? I mean: it could all sit on the same filesystem without having a CPIO image on disk? Grub supports pretty much every filesystem already so loading this initial kernel image from the network or wherever could just start there.
  - dfox 10y ago
    Mounting root file system might nowadays conceivably involve some non-trivial userspace code that never even was implemented in kernel space. Few examples: - Searching for root filesystem based on it's contents (in simple case UUID, but mechanisms like "contains this file" are used sometimes) instead of "physical" location - Encrypted root filesystem (requires some kind of UI for entering the passphrase) - LVM2 (which is set of userspace utilities that configure more general kernel modules that know nothing about the actual on-disk format) - while there is slightly hackish kernel support for configuring network interfaces before having userspace and mounting rootfs from NFS, such thing cannot possibly deal with all variants of network configuration (eg. VLANs, 802.1x, ...) and possible network filesystems/block devices. - root on ramdisk, copy-on-write overlay filesystem or something like that. To summarize: it's entirely possible to have the system boot of PXE, authenticate via WPA-EAP on wifi and fetch it's own root filesystem into ramdisk via HTTPS while storing writes onto NFS somewhere. Implementing all which is required for that in kernel space is neither possible nor useful. By the way, the point of initramfs is that it is loaded into memory by bootloader using whatever means the bootloader has and the image does not have to be on rootfs accessible to kernel (for PXE it typically isn't).
    - drvdevd 10y ago
      Ok. That's a great summary and good point about non-trivial userspace bits. I hadn't considered how complex "booting" as a process has become...
  - Sir_Cmpwn 10y ago
    Most initramfs designs are based on shell scripts and use tools like `mount -t ext4`, cryptsetup, etc - normal userspace tools, tied together by shell scripts. What you're suggesting is actually more special purpose than what we already have. Modern initramfs design is really great and not crufty at all.
    - IshKebab 10y ago
      Wait are you suggesting that something tied together with shell scripts is great?
Qantourisc 10y ago
initramfs is also about keeping userland tools, like LVM out of the kernel. But to run the LVM tools you need access to a filesystem, which might be on a LVM. And there are quite a few other scenarios too. But if you can do without, be my quest, less things that can fail.
forgottenacc57 10y ago
There are various RAM based distros in which the only file system is initramfs. Makes no sense to propose getting rid of this.
- digi_owl 10y ago
  I don't think the argument is as much about getting rid of it in the kernel, as trying to avoid yet another case of "i have a hammer, thus all my problems are nails". But then the linux "community" is rampant with this line of thinking. just look at the slow moving recreation of "containerize all the thing!!!" meme.
deleted 10y ago
[deleted]
setq 10y ago
Definitely. If ever I have a hosed Linux machine, the wrangling with systemd, initramfs, grub2, mdraid and all the associated shenanigans fills me with dread. Sometimes it's easier just to reimage and restore. Free/OpenBSD get this 100% on the mark.

phs2501 10y ago

initramfs isn't (and wasn't) at all about keeping your boot files below the 2gb mark on a disk. It's about actually mounting your root filesystem, either on a fully-modularized kernel where all of your (hundreds of) block drivers are in modules, or where root is coming over a network block device, or a USB disk, or a SAN, or a complex RAID, or an encrypted disk where you need to enter a password or use a hardware token or whatever. Basically, rather than encoding tons and tons of crazy special-purpose logic into the kernel to mount every insane iteration of root filesystem, you just get the bootloader to stick a CPIO image in RAM for the kernel to get at and then use the normal userland tools to do what you want. IMHO, initramfs is the opposite of an ugly hack.

drvdevd 10y ago
Though I take your point and mostly agree, is there any reason this couldn't be done with a static boot binary entirely in RAM? Since the kernel is modular anyway, much of the special purpose cruft loaded by the initramfs could just be loaded and unloaded with a boot script of some kind right? I mean: it could all sit on the same filesystem without having a CPIO image on disk? Grub supports pretty much every filesystem already so loading this initial kernel image from the network or wherever could just start there.
- dfox 10y ago
  Mounting root file system might nowadays conceivably involve some non-trivial userspace code that never even was implemented in kernel space. Few examples: - Searching for root filesystem based on it's contents (in simple case UUID, but mechanisms like "contains this file" are used sometimes) instead of "physical" location - Encrypted root filesystem (requires some kind of UI for entering the passphrase) - LVM2 (which is set of userspace utilities that configure more general kernel modules that know nothing about the actual on-disk format) - while there is slightly hackish kernel support for configuring network interfaces before having userspace and mounting rootfs from NFS, such thing cannot possibly deal with all variants of network configuration (eg. VLANs, 802.1x, ...) and possible network filesystems/block devices. - root on ramdisk, copy-on-write overlay filesystem or something like that. To summarize: it's entirely possible to have the system boot of PXE, authenticate via WPA-EAP on wifi and fetch it's own root filesystem into ramdisk via HTTPS while storing writes onto NFS somewhere. Implementing all which is required for that in kernel space is neither possible nor useful. By the way, the point of initramfs is that it is loaded into memory by bootloader using whatever means the bootloader has and the image does not have to be on rootfs accessible to kernel (for PXE it typically isn't).
  - drvdevd 10y ago
    Ok. That's a great summary and good point about non-trivial userspace bits. I hadn't considered how complex "booting" as a process has become...
- Sir_Cmpwn 10y ago
  Most initramfs designs are based on shell scripts and use tools like `mount -t ext4`, cryptsetup, etc - normal userspace tools, tied together by shell scripts. What you're suggesting is actually more special purpose than what we already have. Modern initramfs design is really great and not crufty at all.
  - IshKebab 10y ago
    Wait are you suggesting that something tied together with shell scripts is great?

Qantourisc 10y ago

initramfs is also about keeping userland tools, like LVM out of the kernel. But to run the LVM tools you need access to a filesystem, which might be on a LVM. And there are quite a few other scenarios too. But if you can do without, be my quest, less things that can fail.

forgottenacc57 10y ago

There are various RAM based distros in which the only file system is initramfs. Makes no sense to propose getting rid of this.

digi_owl 10y ago
I don't think the argument is as much about getting rid of it in the kernel, as trying to avoid yet another case of "i have a hammer, thus all my problems are nails". But then the linux "community" is rampant with this line of thinking. just look at the slow moving recreation of "containerize all the thing!!!" meme.

deleted 10y ago

[deleted]

setq 10y ago

Definitely. If ever I have a hosed Linux machine, the wrangling with systemd, initramfs, grub2, mdraid and all the associated shenanigans fills me with dread. Sometimes it's easier just to reimage and restore. Free/OpenBSD get this 100% on the mark.