Etherbooting memdisk

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.

• Plenty of RAM in the target diskless client (DC). As a general rule, the amount of ram required for booting an OS from memdisk is the minimum hard disk space required by the OS plus the RAM required by the OS and applications on top. In the win98 example below, the hard disk space required for a minimum installation is around 210MB and the recommended RAM size is 128MB, then 384MB would be about the least required for our example. However, for a useable win98 PC with the most common windows components (including IE, Outlook Express, etc), 512MB is the recommended minimum based on the author's experience. Some windows experts claimed they managed to trim win98's footprint to less than 100MB but here, we want to make life easier at the cost of bigger RAM size.
• The next checklist of sub-items are etherboot specific. The etherboot user manual (which will end up somewhere in this wiki later **) is the authoritative reference for setting them up. Here, we start by assuming that these are all up and running as a working network of diskless linux clients.
  • Network services
    • DHCP-server
    • tftp-server
    • NFS-server
  • our target diskless computer (already fully functional as a linux diskless client)
    • Etherboot ROM (version 5.3.7, others see the notes on top of this document)
    • Linux kernel (2.4.20, but that does not matter too much) NBI image in the tftp server above
    • root fs mounted through nfs or initrd
    • access to plenty of linux utilities
    • temporary harddisk and/or diskette drive where needed (for building and uploading disk images)
• mknbi-1.4.3 sources (/usr/local/src/mknbi-1.4.3 at the server), tarball available
• mknbi-1.4.3-memdisk.path
• syslinux-2.08 source (/usr/local/src/syslinux-2.08 at the server), tarball available
• a bootable DOS diskette (some license-free DOS diskette images available here

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:

• Upgrade mknbi to 1.4.3 if it is not already (Note: mknbi-1.4.3 and earlier versions needs a patch to get round some problems in booting memdisk. Currently, only 1.4.3 has such a patch available. Hopefully, future releases will have this built-in by default.)
• Apply mknbi-1.4.3-memdisk.patch (already downloaded and saved in /usr/local/src/mknbi-1.4.3) and rebuild mknbi:

       [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

• Look into syslinux-2.08 source for a binary file syslinux-2.08/memdisk/memdisk. This will be our kernel in all net boot images here. We'll copy it to our tftpd-root for convenience:

  [root@server mknbi-1.4.3]# cp usr/local/src/syslinux-2.08/memdisk/memdisk /tftpdir/memdisk

• Prepare the initrd. This is the only OS-specific component among all etherboot/memdisk net boot images. For our first memdisk recipe here, it is our DOS diskette listed above.
• Upload the diskette image and (optional but why not) gzip it:

       [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

• Build the net boot image (nbi):

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

• Finally, reconfigure dhcpd to tell xterm to tftp /tftpdir/dos.nb next time when it boots. In our server:/etc/dhcpd.conf, comment out this line:

       filename "/tftpdir/xterm.nb";

  and insert this in its place:

       filename "/tftpdir/dos.nb"; 

  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:

• it does not support network booting natively and
• it uses PC BIOS int 13 for local harddisk access

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.

Descriptions available for

• MS-DOS and compatible
• Windows 98

• Do I really need my Diskless Cient running on linux first, as suggested above, in order to boot memdisk?
  No, you don't as long as you have other means of building and uploading your target OS image (normally from a local disk). However, it's a good indication that your network services are all set for etherboot and the etherboot rom in you DC is OK. Then, for the purpose of this article, it's also easier to modify an existing entry in dhcpd.conf than to create a new one from scratch for our memdisk client.
• mkelf-linux complained: 'Unknown option: rdnopad'
• memdisk booted but complained: 'Decompression error output buffer overrun'
  Make sure your mknbi is 1.4.3 (not earlier) and is patched with mknbi-1.4.3-memdisk.patch available here. Future versions might have this fixed already.
• memdisk complained 'Decompression error invalid compressed format (err=2)'
• memdisk booted but the system hung after saying '. . . booting . . .'
• memdisk booted but instead of booting to the OS in ram disk, the system simply recycled between etherboot and memdisk
• The system booted into the OS in ram disk at last but it was nothing like what I used to see when it lived in a hard disk
  Most likely you had a corrupted ram disk. This could happen if you used the –rdbase=asis|0xnnnnnnnn option when building your nbi with mkelf-linux (1.4.3 or older versions). Try set 0xnnnnnnnn to a higer address or simply leave this option out to use the default (top of memory). The –rdbase=asis option must not be used for booting memdisk.

• An 'MBR virus' warning message keep popping up every time when win98 starts up, what is it and how do I get rid of it?
  It is memdisk. To Win98, it looks like an MBR virus because they are both loaded by the boot loader, and they both claim some DOS memory. When Win98 finds some of its memory being claimed by something it didn't load, it will warn the user of MBR virus. Normally, we only have to acknowledge such a warning once on a harddisk system. A key in the win98's registry would then be set and remembered. With ram disk however, we need to do that before building our initrd. Try this if you don't get better advice elsewhere as to which key to set:

  [HKLM\System\CurrentControlSet\Control\FileSystem]"LastBootPMDrvs"=hex:00

• Can I build the memdisk/win9x nbi once and use the same image for many other diskless clients? Technically yes, but, there are a few things you should bear in mind:
  • M$ Windows is not free. You need to ensure every DC booting into 'M$ ANYTHING' is covered by a valid license. The same principle applies to all commercial applications running on top of it as well.
  • All DC's sharing the same nbi must be identical (in hardware) to the original win9x workstation whose harddisk you used for building the nbi.
  • Very likely, your DC's would all inherit the same 'Computer Name' in the nbi on startup because Win9x doesn't seem clever enough to obtain a different name through DHCP. You might want some tricks to resolve NETBIOS name conflicts in your windows network.

• Etherboot homepage
• Syslinux/pxelinux/memdisk homepage
• http://clic.mandrakesoft.com/documentation/pxe
• GRUB information
• Ultimate Boot CD (a collection of ready-made boot disk images and system utilities suggested by Tim Fletcher)

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.