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. 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).
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.
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.
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. |
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.
|
|