This still won’t answer all you need, but will probably be useful…
When a system boots the bootloader itself is an operating system. If the bootloader needs content in a partition, then the bootloader itself needs the driver for that access. In the case of accessing configuration files on an ext4 filesystem, then the bootloader would also need ext4 drivers.
At the moment the Linux kernel loads the bootloader has essentially killed itself off by overwriting with a new operating system. As this occurs the Linux kernel needs its own drivers for reading partitions and for reading ext4. This is rarely a problem.
The trick is that some drivers may not be part of the Linux kernel
Image file. Some drivers might be in the form of a module. Those modules are located somewhere else. Let’s say that you are working on some weird advanced filesystem which the default kernel does not know about, and that the code is only available in the form of a module. But the module itself is in that weird filesystem type. A bit of a “chicken and the egg” dilemma. To read the module you would need to load the module…but you can’t load the module until you read the module.
Thus, although you could try to boot straight to your normal boot environment, there is instead a bit of an adapter known as the “initial ramdisk”, a.k.a., the “initrd”. Every kernel knows how to boot to a limited self-contained boot environment running purely in RAM and without any filesystem type at all. It is literally just a gzip’d list of files that look like a tiny Linux installation.
That installation is good because no filesystem driver is needed. If you’ve copied the minimal set of drivers to read your advanced experimental filesystem to the
initrd, then it means this temporary ramdisk system can load the module. The
init (the first program a kernel executes other than itself) of the initrd does nothing more than basically the same thing the bootloader does: It reads everything needed and then overwrites itself again, but this time with the actual full Linux operating system after having loaded the module which provides for your test filesystem type. The initrd is an adapter for cases when required boot drivers are in the form of a module and the module is not normally reachable without extra effort.
I don’t know, but OverlayFS probably needs some such information available to it within an initrd, but can’t say for certain. If the main kernel is unable to load the required OverlayFS code, then it would be typical to use an initrd first, and use the initrd to hand off to the main Linux kernel. This might not be needed, but it is the first thing I examine when I can’t boot correctly due to a non-conventional filesystem issue.
If you look at “
/boot/extlinux/extlinux.conf”, and if the boot entry has an “
INITRD” key/value pair naming an image, then it means your system is starting with an initrd and not just booting directly to your expected kernel. If there is an
INITRD entry, then you might look at the OverlayFS documentation and see what it needs for use in an initrd. If you get specific questions, then probably someone here can answer.