This article explains the way to configure standard Fatdog so that it consumes the minimum amount of RAM; to allow it to run in memory-constrained systems (small desktop systems, virtual environments, etc).
The point is to have a fully functional operating system with minimum amount of memory footprint. Once you have configured as such, you are free to start adding applications and services that you really use; making sure that RAM is made available for those applications (rather than for the operating system).
In here I stated that a standard Fatdog can run graphical desktop with 170MB or less, and a CLI environment in 100MB or less.
In this article, I'm going to show you how you can get CLI Fatdog to run with 44MB (in a virtual qemu environment, with Linux 4.4.21 kernel).
There is only two requirements - Fatdog must be able to access the disk it is booting from without needing any additional kernel modules. This includes the disk that will contain Fatdog's savedir/savefile. This is usually the case for standard SATA and USB disks.
To test, simply boot Fatdog with the parameter "earlyshell".
When you have booted into a shell, type cat /proc/partitions
and make sure your boot disk/partition is listed there.
If yes, you can continue. If no, you need to figure out which kernel module is needed and rebuild the kernel to have those modules built-in.
The second requirement is that Fatdog must have already been installed. It can in internal harddisk, it can be on USB flash drive, as long as it has been installed then it's good. You cannot use this method to perform diskless boot (not without some variations).
Fatdog is already designed to run with minimum memory usage from the ground up (this is not true for many general purpose distros, especially 64-bit ones); but to support general purpose hardware it sacrifices this feature. The steps we're going to take is to "restore" this feature, by sacrificing the general-purpose-ness a little.
Firstly, we will forego graphical boot (Xorg, the window manager, panel, desktop manager all add a good couple of megabytes). This can be done easily by adding "pfix=nox" to the boot parameter.
Secondly, we want to get the basesfs (fd64.sfs) out of initrd. This will immediately drops the memory requirement by the size of basesfs (typically ~ 250MB). This can be done by extracting initrd, moving out fd64.sfs somewhere, and then re-packing initrd.
When you do this, don't forget to specify "basesfs" boot parameter to tell Fatdog where to find its basesfs (now that it's no longer contained in its initrd).
Thirdly, we want to move kernel-modules.sfs out of initrd. This
will drop the memory requirement by the size of that file, typically
around ~ 45MB. To do this, extract initrd again, move kernel-modules.sfs
somewhere. Then copy the file usr/share/blank.sfs
(this file is
available inside the extracted initrd) and rename it to kernel-modules.sfs.
Then repack initrd.
After you do this, please specify "extrasfs" boot parameter to tell Fatdog where to find this extracted kernel-modules.sfs
Upon the completion of this step, Fatdog will perform its initial boot without using any extra drivers - hence the requirement that Fatdog must be able to find its boot disk without needing to load additional kernel modules.
Finally, we want to disable services that we don't need. A standard Fatdog usually comes with the follwing services activated:
Services | Function | Disable? |
00sys_logger | system and kernel logger | Don't |
08-messagebus | DBUS system message bus | Maybe |
10-acpid | Respond to ACPI events | Maybe |
20-ram-save | Periodically save RAM layer to permanent storage | Yes |
40-preload-fonts-icons | As its name says | Yes |
50-Wpagui | Start default network services | No unless you have setup network using net-setup.sh |
56-mdns | Run ZeroConf/Bonjour services | Maybe |
70-cups | CUPS printing system | Maybe |
85-bluetoothd | Bluetooth support | Maybe |
91-autochownd | Make sure items in "spot" is owned by "spot" | Maybe |
99-alsa | Restore sound volume at boot | Maybe |
Those marked "maybe" means you can disable them depending on your needs. E.g
Note: Disable them by removing the executable bit (chmod -x
).
That's it, really! Screenshots of final result:
Yes. Most of that 44 MB is used by the kernel. You can reduce this number by removing unnecessary kernel components - usually by removing built-in driver which aren't needed, etc.
E.g. in virtualised environments, if you never need to use any USB, you can leave out all USB-related modules, for example.
But this requires re-compile of the kernel and furthermore it is very system-specific, so I'm going to leave it out.
Because minimising RAM usage comes with trade-off.
For one thing, the default setup of basesfs being inside initrd means you're basically running an OS with its system files in RAM at all times. Leaving it outside means you're now loading the system files from disk - which is slower.
Another thing is, it puts severe restriction on Fatdog's boot-ability. You cannot, for example, boot off and uses savefile located in an LVM or encrypted partition. You also cannot perform diskless boot using PXE.
So this is an obvious trade-off. If you can live with restrictions and happy to use the extra RAM for other things - go ahead. But if you're after performance, then perhaps you should not do these things.
The default Fatdog distribution opts for versatility and performance.