This wiki page documents the author's recent experience in making an etherbootable image (nbi) of memdisk. At its best, it is only a temporary reference for those who want to boot memdisk from etherboot directly. It is temporary because the etherboot project team are reviewing some of the features in the current release 1.4.3 of mknbi. Depending on the results of their review, some bugs might have been fixed and new features might have been added to the next and/or future releases. At the end, some, if not all, of the contents in this document might no longer be valid. Therefore, the readers should take care in using the materials here for any purpose. They are doing that at their own risk.
It is not the purpose of this article to talk about memdisk in detail. For the more curious readers, there is a more memdisk-specific and authoritative document at the SysLinux Homepage. Here, the following paragragh, which was stolen from the published memdisk documentation, should suffice as an introduction:
MEMDISK simulates a disk by claiming a chunk of high memory for the disk and a (very small - 2K typical) chunk of low (DOS) memory for the driver itself, then hooking the INT 13h (disk driver) and INT 15h (memory query) BIOS interrupts.
Most ram disks known today are not bootable because they all live on top of an OS and rely on the OS to get loaded. MEMDISK is unique in being loaded by a boot loader, i.e. it is there well before any OS comes into existence. This OS-independence makes possible the simulation of a bootable disk, hence an ideal bridge between ETHERBOOT and those OS'es which do not support network booting natively.
As a network boot loader, ETHERBOOT has a long list of bootables to talk about in the Etherboot documentations. However, many of today's (and yesterday's, in the case of DOS and Win98) most popular OS'es either do not natively support booting from network or lack the support for building network bootable images for etherbooting. By chaining MEMDISK to ETHERBOOT, any OS that supports booting from disks (memdisk at least) would then automatically become a possible etherboot target. That effectively lifts the barrier which has prevented users of these OS'es from going diskless.
As of today, there are more than one ways of booting memdisk under the two main-stream net boot environments, Intel PXE and Etherboot. We do not intend to go through them in detail but are listing them here in order not to mislead our readers into thinking that ETHERBOOT being the only network loader for MEMDISK.
n this regime, a PXE rom loads an intermediate loader PXElinux which then loads memdisk. Since both pxelinux and memdisk are available within one single package (syslinux), this appears to be the most logical solution if but only if a PXE boot rom is available in the booting PC.
This solution differs from the last only in the 2nd stage loader being used (pxegrub vs. pxelinux). To the end user, the difference is mainly that of the user interfaces (the boot menu) between SysLinux (pxelinux) and grub (pxegrub).
This is identical to the PXE-pxegrub-memdisk combination above except a change of the netboot environment from PXE to Etherboot.
Compared with the others, this appears to be the only solution which does not involve an intermediate stage loader. It does require some little tricks for getting round minor incompatibilities between etherboot (mknbi-1.4.3 and earlier) and memdisk though, hence the subject of this article.
As from 5.3.7, etherboot offers a new feature of simulating a PXE. Etherboot thus becomes an ideal open source substitude for PXE code which is not always available free.
The following are basic requirements for setting up etherboot/memdisk regardless of the type of OS to boot at the end of the boot loader chain. Other OS-specific requirements will be elaborated in the Memdisk Recipes section later. Software versions, where indicated, are those having been tested to work. Earlier and later version should also, with some limitations perhaps which will be highlighted where appropriate.
To ETHERBOOT, MEMDISK is just 'yet another linux kernel'. Since we already have our network services (dhcpd, tftpd, etc.) up and our DC already running as a linux client, our task here is to replace the linux kernel there with memdisk. For simplicity, we assume everything had been setup exactly according to the Etherboot User Manual under Section heading Setting up a diskless boot. This is important because we want the readers to have the same understanding when network nodes, directories, files, server settings, etc. are referenced. For convenience, in the context below, we'll reference our DC and server as xterm and server respectively. To the end user, etherbooting memdisk is only an infrastructure, a stepping-stone for booting some target OS at the end. For a quick start, we'll pick a simple target (DOS on small ram disk) here to highlight those things we do only once to setup this infrastructure. Sounds trivial but the same infrastructure will be reused later as we go on to deal with other different OS'es. Now, let's logon to our server (locally or from another linux box having access to the same resources through nfs, telnet, ssh, etc.) Then:
[root@server root]# cd /usr/local/src/mknbi-1.4.3 [root@server mknbi-1.4.3]# patch -p0 < mknbi-1.4.3-memdisk.patch [root@server mknbi-1.4.3]# make [root@server mknbi-1.4.3]# make install
[root@server mknbi-1.4.3]# cp usr/local/src/syslinux-2.08/memdisk/memdisk /tftpdir/memdisk
[root@server root]# dd if=/dev/fd0 of=/tftpdir/dos [root@server root]# gzip -9 /tftpdir/dos
Now, we should have a compressed DOS diskette ready at server:/tftpdir/dos.gz
[root@server root]# cd /tftpdir [root@server tftpdir]# mkelf-linux --ip=rom --rdnopad memdisk dos.gz > dos.nb
Note the use of –rdnopad option which mknbi-1.4.3 requires for booting memdisk (this option is still under review, might change in future releases of mknbi). The more advanced users might want –ip=rom for the target OS to reuse the BOOTP/DHCP answer etherboot got from the server. Otherwise, the –ip option is there only to suppress a warning message from mkelf-linux.
and insert this in its place:
then restart dhcpd for the change to take effect.
If everything goes well, we should get the usual DOS prompt and a small ram disk (drive A) the next time we boot xterm. The memdisk documentation and the FAQ section below might help if problems arise. Although a trivial example, it is our etherboot/memdisk foundation. In the more serious examples in the MEMDISK Recipes section below, we'll skip everything except the only OS-specific item, i.e. initrd.
This is meant to be a growing section. Theoretically, any OS could be a potential target for a memdisk recipe here if:
We'll start it off with another example on DOS, this time cloning (a portion of) a harddisk. Then, we'll go on to a more useful target of booting win98 which is the only OS the author had tried other than DOS. Thereafter, we'll leave it to others to add in new recipes based on their experience on other systems. Again, we'll reuse our DC and server (xterm and server respectively) as before.
This document owes its existence to the etherboot project team and the author of memdisk. Without the information from these wonderful people, the author should never have managed to pull etherboot and memdisk together. Therefore, they are the people to be remembered if anyone by any chance finds this document useful.