Neo_78 wrote: Thu Feb 22, 2024 10:37 pm
Thanks for your feedback @jamesbond.
So the temporary solution would be to use the "medium initrd" option during the remastering option instead of the default, large "humongous initrd"?
https://distro.ibiblio.org/fatdog/web/f ... nitrd.html
What are the exact implications of booting with the "medium inird"? Are there any essential Kernel modules missing that might limit the functionality of the running system?
Did anything in Kernel version 6 change regarding module size that explains the observed size limitation? 
Hi @Neo_78
There are a plethora of ways in which to structure/boot Fatdog. Humongous has the main filesystem (as stored in fd64.sfs) contained within the initrd file.
The bootloader reads the vmlinuz (Linux Kernel) and initrd into memory and then runs the vmlinuz which then runs the initrd that prepares the fd64.sfs and then runs that (via a switch-root, that is somewhat similar to a chroot).
The difference between having fd64.sfs in the initrd or elsewhere is that it doesn't have to be found. Useful for if you use the likes of PXE (boot via your network card) to boot Fatdog.
Much of choice of the style of structure/boot is directed by how you prefer to run things, how much ram you have, whether you want to save changes or not, or optionally save or not, whether you want to be able to dynamically load/unload sfs's (additional programs) ...etc.
Generally there are no differences to whether you opt to have fd64.sfs in the initrd, or not. Either way generally works, excepting for instance if you were using PXE to boot.
For the humongous there's a risk on systems with lower memory where everything is being run in ram of running out of ram space earlier than other choices. When fd64.sfs is inside the initrd that also gets copied as part of initrd into ram at bootup. When the initrd is then extracted in ram, there's another copy of fd64.sfs. If during operation all files were changed, such as if you 'touched' all file dates, then yet another copy of all of the files will be created in the save area. All running in ram however and things will be quicker than if a mechanical HDD driver was being used as part of the setup.
At the other end you could just run with a small initrd, have no fd64.sfs - but instead have all of the fd64.sfs filesystem pre-extracted into a HDD folder, that is then chroot into, in which case no save folder/file is required as changes are preserved as/when they occur. If you preferred not to have changes preserved, then instead you could extract the fd64.sfs into zram and use that, or perhaps use admin processes that made backup copies of the system and restored that after (or before) each session.
Flexibility of choices. There is no single right or wrong way. A common choice is to set up a layered filesystem where the fd64.sfs is at a lower/bottom layer and is read only, with another layer where all changes are recorded, and where those changes are either preserved, or not, according to your preference. Generally having fd64.sfs outside of initrd is perhaps the more common/better approach - very generally, but also very subjectively. Save areas can be a file, folder, in ram on disk ...etc. again flexibility of choices.
The size limitations haven't in themselves generally changed, however as newer versions of programs come out ... time passes, so code (size) tends to increase, needs more ram/space/processing power. Earlier Fatdog versions might have required 200MB, that has progressively increased and nowadays requires more than twice that, as more programs code/drivers/firmware etc. have been added over time. It's somewhat proportional however, if not even a relatively reducing factor, in 200MB days maybe 1GB of ram was the more common, whereas now at 450MB 16GB of ram is common.
In Fatdog extracting/moving fd64.sfs out of the initrd is easy, you just click on initrd and it opens up, and you can drag/drop (move) fd64.sfs out of that, and then click the close option and the initrd is repacked without the fd64.sfs inside it. That new initrd along with the fd64.sfs should then be used to boot with (which means you have to add additional boot parameters to point to where the fd64.sfs is located).
