Booting from net

Booting from net isn't realy an issue at all on linux. Therefore the way, which is presented here, can only be of interest for a few eccentrics, since the solely right way, to boot from net, was already discovered many times.

Because the 3.5''-disk meanwhile has become cranky too, it will be used as imaginary or even real original boot device. I.e. it determines the size. The content may just as good reside on a CD-ROM. You'll put everything in the ROM of a nic, if you like to avoid any discussions, whether it isn't realy booting from floppy.

As server a httpd is brought into action (running just as good under windows). It's surely no surprise, that the address of the server is hard coded. At the moment the httpd must be reachable by IP.

The connection to the client should be fast ethernet. The client gets its IP by means of DHCP, therefore the net has to employ a DHCP-server somewhere. (That is very, very easy to change (with a static IP for the client). But than it's a great deal worse to set up several clients. Furthermore a gateway may very soon become a closed gate.)

The client demands 128 MByte RAM (of course it mainly depends on your remaining system) and must be enabled to boot from the imaginary floppy. A (hard) disk isn't a necessity.

In theory only the cloop file of a KNOPPIX-CD is moved from the CD to the server and than gets again local available by means of httpfs. In case of a KNOPPIX-3.7-CD 700 MByte would be moved to the server and only linux24, minirt24.gz and the boot loader would stay on the client.

sh-2.05b# tree -s static
|-- [   142728]  ash
|-- [        3]  init -> ash
|-- [    29941]  insmod
|-- [      600]  modprobe
`-- [        3]  sh -> ash

0 directories, 5 files
A closer look on minirt24 (eventually httpfs should be incorporated) very soon reveals, that there runs almost nothing until it is possible to access the cloop file. Specially the configuration of the network is postponed into the comfortable environment of the cloop. (Of course it wouldn't be quite easy to bring up the net without the modules for the network interface from the cloop file.)

If KNOPPIX doesn't find its cloop file, than it reveals the spartan environment of pure minirt24, which not even offers ls. Even if httpfs wouldn't have any other reliance (fusermount), it nevertheless depends on a well configured ethernet. That demands for e.g. ifconfig and route. But it is unlikely, that these programs execute without further support in such a castrated environment. (It's evident at once, how the term booting evoked.)

Assuming about 1 MByte for the kernel linux24, there are approximately 400 MByte left for minirt24 (and 0 for the boot loader: boot.msg, ldlinux.sys and syslinux.cfg). For this calculation the size of a floppy (roughly 1.4 MByte) is taken as the (rather sporty than technical) limit. That's after all too little, even if you are willing to delete the modules for booting from CD, USB etc. in minirt24. Fortunately it's enough to additional move fuse.o, fusermount and httpfs to the server. So the original methods of booting are untouched. (There's even some space left for other nic drivers.)

It may seem absurd, to move httpfs of all things from minirt24 to the server, to free space for the network setup, which just httpfs demands, but that's booting: With a wget of only 426 Byte (< 0.5 KByte) the missing parts are loaded from the server to the unziped ramdisk minirt24. (The unziped ramdisk has plenty of free space. By the way, the ramdisk is nearly wiped out when the cloop file takes command, because for e.g. /etc the space is again necessary.)

content of static:
139.4k  ash*
 50.3k  udhcpc*
  1018  ls*
   763  cp*
   504  ps*
   502  ifconfig*
   485  rm*
   426  wget*
   320  ping*
   260  udhcpc.sh*
   255  mkdir*
   217  reboot*
   165  chmod*
   142  ln*
     8  route -> ifconfig*
     6  halt -> reboot*
     6  poweroff -> reboot*
     3  init -> ash*
     3  sh -> ash*
The extensions in minirt24 are additional modules for the network in /modules and changes in linuxrc to use them. Furthermore there are a few more binaries in /static. (There was nothing deleted, but it's another Knoppix version.)
The unbelievable tiny binaries (not shell scripts) come from asmutils. They are assembler programs, which call kernel functions directly. Therefore the C-library is not necessary. Additional they were striped - in a way impossible with strip.(file yields 'ERROR: Corrupted section header size' for all of them.) Eventually they don't have even the basic power of the linux programs of the same name.

wget e.g. can only be called as wget IP path/file. Even than http://IP/path/file is only saved , if the directory path already exists. It's realy a lucky coincidence, that these programs are deleted in the boot process.

On the other hand the DHCP-client udhcpc is an ordinary program, that - nomen est omen - was statically compiled/linked against uclibc. It has not been compressed with upx, since that wouldn't work (- not generally, but in minirt24).

For a minirt24 of 4500 KByte you have to expect a size of 2000 KByte for the compressed minirt24.gz - unless minirt24 mainly contains one single byte repeated many times. But that isn't anymore the case after some experiments, since also deleted files leave some traces.

To achieve a size of minirt24.gz of roughly 50% of the size of the occupied memory of minirt24, the free space has to be homogeneous.

	dd if=/dev/zero of=trash
fills the ramdisk to the end with '0'. After an umount everything is saved. Afterwards trash can (and should) be erased.

The benefit of all this is a floppy or its equivalent respectively, which allows to boot from an ordinary web server. And working on this server is even faster than working on a CD - at least with a suitable LAN. But the LAN-speed is not always as important as the RAM-size of the client. Perhaps it's worth a try to reduce the blocksize of the cloop file to 16 KByte.

(If there are any reliances, than kernel 2.4.27 and gcc 2.95.4 are assumed.)


Actually one would also expect

	mknod /dev/fuse c 10 229
	chmod 666 /dev/fuse
in linuxrc, if the modul fuse.o has to be fetched from the server. (The asmutils also have a solution for that.) But it's easier - if one edits minirt24 anyway - to prebuild the device in /dev.