- 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.
...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.
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.
That would probably make updates a lot less slower than having zfs shipped in an initramfs though.
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.
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.
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.
But initramfs isn't so bad, and it allows things like ZFS root to have a modicum of smoothness and integration.
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.
Me too. I go back to within about 3 years of that.
But I expect my distro to handle this for me now.
If the distro compiled and updated the kernel for my hardware then there's be no need for an initramfs.
While initramfs was a simplistic kludge, the UKI idea does not fix it, it wraps a kludge inside a fugly ball of lack of understanding.
That is a lot faster than recovering from a backup.
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.
I don’t see the point of doing so however.