I'm aware that the following is somewhat utterly pointless: we all know that one needs at least 48 MB RAM for a current TC system (and 32 MB RAM for a MC one). But I found the question whether it is at least in principle possible to lower said minimum when using a so called "scatter installation" (i.e. extraction of the initrd to a hard disk) nevertheless intriguing. After a bit of probing and prodding I believe I can now offer such a prove of concept.
First off all my testing was done with virtual systems (e.g. QEMU as well as VBox), as even I don't own any piece of equipment that I could limit to 16 MB RAM. As it is clear that TC (or even MC) can't be booted of a CD-ROM on such a limited system I went on a hunt for a floppy based Linux system that has comes with just enough support to get the job done. After not having much luck with some other attempts I finally settled on
one that I've found in the
rescue system section of 'ibiblio.org'. Furthermore I decided that for this test a 40 MB disk image would be just enough.
So "armed" with these three devices (i.e. a boot floppy, a TC 3.8 CD-ROM and the target hard disk) I started the test system for the first time:
qemu -m 16 -hda scatter_40M_A.img -cdrom tinycore_3.8.iso -fda ramf-120.img.bin -boot aAs it turns out the boot floppy contains a (legacy) GRUB installation (which will come in very handy in a moment) and offers the option to 'Boot Linux rescue system'. So after doing that (and choosing an appropriate key map) one ends up in the (root) shell of a Linux 2.4.21 system. That is indeed not quite current anymore, but it still gets the job done. I then went ahead and
- wiped the entire hard disk,
- created a (single) primary partition, formated it with EXT2, and mounted it,
- copied the GRUB 'stage' files from the floppy to the hard disk,
- created a GRUB configuration file on the hard disk, and
- copied the TC kernel and extract the TC initrd
A scripted version of these steps is attached, and to save myself some trouble I've just copied that script onto the boot floppy (which had just enough room to allow for this). As the floppy is of MS-DOS format this step can be done with the help of pretty much any OS available. Therefore what I actually did was in the root shell to mount the floppy (e.g. via
mount /dev/fd0 /mnt/floppy -t vfat) and execute the script (e.g. via
sh /mnt/floppy/cr_scatter-install_ram120.sh).
At this stage I should note that depending on the QEMU version (and maybe the choice of disk image format) the initrd extraction process can take a while. I've noticed that it took ca. 16 minutes when using my usually preferred version (i.e. v0.11.1 with KQEMU), whilst it was rather faster in ca. 16 seconds with a typically slower, but more recent release (i.e. v0.14.1, either one ran on a WinXP host).
Nevertheless the hard disk had received as planned a "scatter installation" of TC, but was still lacking the proper GRUB setup (albeit the 'stage' files and the GRUB configuration were already in place). So I started the whole system again (e.g. via
reboot), but this time went straight to the GRUB command mode (by pressing 'c' instead of 'Enter'). At this level I was able to finalize the GRUB installation via a
root (hd0,0) command followed by
setup (hd0) (please note that the former refers to the partition, whilst the latter refers to the entire disk).
After that I choose to shut down the system (e.g. via
halt) to then remove the surplus media (i.e. the floppy and the CD-ROM) which in the world of this VM just meant that I used
qemu -m 16 -hda scatter_40M_A.imginstead of the command from above.
So, after all these steps what does one end up with? Well, the system boots (as requested via a 'text' boot code) to the "usual" shell. Unfortunately (but not in the least bit surprising) there is only ca. 1 MB RAM left (taking the
free output as indicator for that piece of information). Even when executing
sudo cache-clear ; free the result is not vastly better (i.e. ca. 5.5 MB free). Either way the system is IMHO rather "useless", as it is not even able to run 'startx' without ending up in a segmentation fault. Again, none of this is really significant as I'm not suggesting that anyone would want to run an X server in that situation. I'm just using this as an example of the limitations which make any real practical use virtually impossible.
Finally, I'd like to state that I enjoyed playing around with this sort of "challenge". It gave me the opportunity to learn details (e.g. about this particular GRUB installation method) I had no prior knowledge about. Before I figured out the way that I've presented here, I had for example planned to "patch" the MBR directly and thought to have sorted out (almost) all the issues on that way. Only when (for some still unknown reason) my "brute force" method to identify the sector of the 'stage2' file failed to work did I go back and found out more about the capabilities of the GRUB command mode.
A notable mention should also go to the
Tiny Slitaz builder. This is a web page which allows to create a floppy (or CD-ROM) image to boot a pretty minimal system. One gets to chose between different flavours of (minimal) kernels, the set of modules and a set of additional packages. I assume all this is derived from the "proper" Slitaz. Even though the samples and documentation suggest that it would operate with as little as 16 MB RAM, in my attempts I found that it needs at least 17 MB RAM nowadays. Which unfortunately disqualified it for my aim, but might be nevertheless quite a neat option for a floppy-based minimal Linux 2.6 system if the bar is set a little bit higher.
EDIT: Change of the attachment and a minor image name change.
Welcome
FAQ
Downloads
Wiki
