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.
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
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
runsalmost 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.)
spartanenvironment 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
castratedenvironment. (It's evident at once, how the term booting evoked.)
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*
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
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=trashfills 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.
Actually one would also expect
mknod /dev/fuse c 10 229 chmod 666 /dev/fusein 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.