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
static
|-- [   142728]  ash
|-- [        3]  init -> ash
|-- [    29941]  insmod
|-- [      600]  modprobe
`-- [        3]  sh -> ash

0 directories, 5 files

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

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*

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

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.

• example of a syslinux.cfg
• fragments from linuxrc
• essentials from /static (about 33 KByte)
• dito for server (about 102 KByte)

Supplement

Actually one would also expect

	mknod /dev/fuse c 10 229
	chmod 666 /dev/fuse