The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.
I realize that. But every distro I've used uses an initramfs, so unless you want to build your own kernels, you're stuck with it, and the painfully slow initramfs updates when you update packages, and dkms (or similar) updates the initramfs with the newer version of your out-of-tree modules.
Given the reason why "out-of-tree modules" exist, there's really no way to eliminate initramfs or something like it entirely in the general case. It might be possible to speed up the process of building the image (as long as the results are not "redistributed"), but this is a licensing and legal problem, not a technical one. FreeBSD is under a much more permissive non-copyleft license and so can legally bundle things that Linux cannot.
- linux tells the bootloader what folder the modules live
- bootloader just puts them all in memory
- linux just picks what it needs.
That's all the initramfs is anyways. The point is there's no reason to prebuild an image from inside Linux, you can just have grub assemble a simple fs on the fly.
initramfs can be eliminated if no kernel modules are required to boot the system. In practice, this means drivers for the motherboard, drivers for the block storage system, and the filesystem have to be compiled in as opposed to being modules. Certain 'interesting' disk schemes that require userspace configuration tools aren't possible, including LVM2, dmraid, disk encryption, /etc/fstab has to hardcode the physical path, and probably a dozen other things I can't think of. If you want to do PXE boot over wifi and you have out of tree wifi drivers I don't think that would work, though tbh PXE over wifi sounds insane.
> ...But to load it at boot time it absolutely must be done through an initramfs. Is that right?
No, not AFAICS; it is incorrect.
On UEFI the system boots from a FAT32 partition. Put the kernel directly on that FAT32 partition, and any necessary modules such as ZFS, and the kernel can load the ZFS module from FAT32 and then mount root directly without any need for an initramfs.
This is how systemd-boot works.
I am not advocating systemd-boot -- I found it a pain to work with -- but the point is that it's perfectly possible and doable. The initramfs is a bodge and it's time we did away with it. It should only be needed for installation and rescue media.
> But to load it at boot time it absolutely must be done through an initramfs. Is that right?
Yes, because it cannot be part of the kernel image, or it would be illegal (a violation of the GPL license) to distribute that kernel. Therefore, it must be a module, and that module has to live somewhere and be loaded by something. If root is on ZFS, this must therefore live in an initramfs and be loaded by it so that the initramfs can mount the real root filesystem on the kernel's behalf.
One could have the equivalent of DKMS build the modules into the kernel image instead of building the initramfs. I don't know how much practical overhead there is to the initramfs and pivot_root dance, but it feels far uglier than it should need to be to just load some modules.
That would run afoul of Turkish copyright vignette laws, that have an exemption for stuff everyone can use and redistribute royalty-free but no exemption for stuff that you can use royalty free but not redistribute.
The distro could automatize the compilation of the kernel with ZFS on the user machine. In that case no license is violated as the kernel image is not distributed with ZFS.
That would probably make updates a lot less slower than having zfs shipped in an initramfs though.
It doesn't really have to be slower as all that would be needed to do on installation is the final linking step. Linking prebuilt objects into a prepared kernel image shouldn't be inherently slower than assembling modules into an initramfs.
The "problem" with the GPL here arises not when you, the end user, take a piece of GPL-licensed software and combine it with other software, as is your GPL-protected right, but when you try to redistribute the result. You see, every end user has the same right to obtain all of the source code for GPL-licensed software that they receive, and for all of that source code to be licensed in a way compatible with the GPL. Once the kernel and non-GPL-licensed modules have been combined into a single piece of software, you are free to use it locally as you wish, but you can't share it, because you would be unable to meet the obligations you owe to the person you give it to.
Bear in mind that the modules are meant to be combined with the kernel, and the method by which that happens isn't specified by the module authors. So, a tool which makes all of this easier for you to do isn't circumventing any restriction meant to stop you from doing this, because no such restriction exists.
> So, a tool which makes all of this easier for you to do isn't circumventing any restriction
Is this the case though? I thought there was an argument that in order to create that tool - you would need enough knowledge that it would require you to basically create a derivative work.
Is anyone really wanting to get back into the business of building their own kernels? I started using Linux heavily in '92, and I've built a lot of kernels, and am quite happy to not be building them anymore.
It's easy (2-3 commands), takes like a minute on a modern machine with trimmed down kernel configuration, and you can customize the kernel to your liking (write/patch drivers, embed firmware blobs, fix things that are broken or missing). What's to hate? :)
Though I only do it for my ARM based devices currently.
And if you're not throwing away build artifacts after each build, then getting stable updates is just a `git pull` and incremental make, which is usually very quick.
I kind of liked compiling my own kernels. I felt I was better-connected to the state of things, and it was fun to see it all evolve from the vantage point of "make menuconfig".
But initramfs isn't so bad, and it allows things like ZFS root to have a modicum of smoothness and integration.
I build my own kernel. I did invest some time to select the right configuration, but now it's just a question of copying over the old .config and running "make". What's annoying about that?
I understand not wanting to. I have been compiling my own kernels since about 2008, I think. I have occasionally thought about switching to something else, but really it has only gotten better (faster) over time.
When I was young and spry, I used to compile them with every new minor revision. Now, it is just maybe a couple times per year. I think that cooling it on how often I do it has helped it not become annoying.
kernel compilation is easily automated. I don't want to do that and like the initramfs approach mostly because I like the fact I can take a hard drive out of a computer and boot the system on another one in case of a hardware failure.
That is a lot faster than recovering from a backup.
> Initramfs is used for generic kernels where you don't know beforehand which features will be required.
And also for e.g. cases where you've got some custom stack of block devices that you need to set up before the root FS and other devices can be mounted. It's not just about loading kernel modules.
Because there are a lot of different types of filesystems supported. And you'd have to compile them all into the kernel. Which of course you can do, that is supported by the build system today. But Distros typically prefer to keep their kernels small, and not waste the RAM that would be taken up by compiling it all into the kernel.
