8. Reducing root filesystem size
One of the main problems with building bootdisks is getting everything to fit into one (or even two) diskettes. Even when files are compressed this can be very difficult, because Linux system components keep growing. Here are some common techniques used to make everything fit.
8.1. Increase the diskette density
By default, floppy diskettes are formatted at 1440K, but higher density formats are possible. Whether you can boot from higher density disks depends mostly on your BIOS. fdformat will format disks for the following sizes: 1600K, 1680K, 1722K, 1743K, 1760K, 1840K, and 1920K. See the fdformat man page and /usr/src/linux/Documentation/devices.txt.
But what diskette densities/geometries will your machine support? Here are some (lightly edited) answers from Alain Knaff, the author of fdutils.
This is more an issue of the BIOS rather than the physical format of the disk. If the BIOS decides that any sector number greater than 18 is bad, then there is not much we can do. Indeed, short of disassembling the BIOS, trial and error seems to be the only way to find out. However, if the BIOS supports ED disks (extra density: 36 sectors/track and 2.88MB), there's a chance that 1722K disks are supported as well.
Superformatted disks with more than 21 sectors/track are likely not bootable: indeed, those use sectors of non-standard sizes (1024 bytes in a sector instead of 512, for example), and are likely not bootable. It should however be possible to write a special bootsector program to work around this. If I remember correctly, the DOS 2m utility has such a beast, as does OS/2's XDF utilities.
Some BIOSes artificially claim that any sector number greater than 18 must be in error. As 1722K disks use sector numbers up to 21, these would not be bootable. The best way to test would be to format a test DOS or syslinus disk as 1722K and make it bootable. If you use LILO, don't use the option linear (or else LILO would assume that the disk is the default 18 sectors/track, and the disk will fail to boot even if supported by the BIOS).
8.2. Replace common utilities with BusyBox
Much root filesystem space is consumed by common GNU system utilities such as cat, chmod, cp, dd, df, etc. The BusyBox project was designed to provide minimal replacements for these common system utilities. BusyBox supplies one single monolithic executable file, /bin/busybox, about 150K, which implements the functions of these utilities. You then create symlinks from different utilities to this executable; busybox sees how it was called and invokes the correct code. BusyBox even includes a basic shell. BusyBox is available in binary packages for many distributions, and source code is available from the BusyBox site.
8.3. Use an alternate shell
Some of the popular shells for Linux, such as bash and tcsh, are large and require many libraries. If you don't use the BusyBox shell, you should still consider replacing your shell anyway. Some light-weight alternatives are ash, lsh, kiss and smash, which are much smaller and require few (or no) libraries. Most of these replacement shells are available from http://www.ibiblio.org/pub/Linux/system/shells/. Make sure any shell you use is capable of running commands in all the rc files you include on your bootdisk.
8.4. Strip libraries and binaries
Many libraries and binaries are distributed with debugging information. Running file on these files will tell you ``not stripped'' if so. When copying binaries to your root filesystem, it is good practice to use:
objcopy --strip-all FROM TO |
 | When copying libraries, be sure to use strip-debug instead of strip-all. |
8.5. Move files to a utility disk
If some of your binaries are not needed immediately to boot or login, you can move them to a utility disk. See Section 9.2 for details. You may also consider moving modules to a utility disk as well.