Etherboot loading Etherboot

Technically speaking, you could have Etherboot load Etherboot load Etherboot load Etherboot etc. etc. (depending on how many different criteria you can come up with to differentiate different versions of Etherboot to load), but we will only detail having an older version of Etherboot load a newer version of Etherboot. The differentiating factor in this scenario is the fact that older versions of Etherboot did not send the Vendor Class Identifier to the DHCP server when requesting an IP address and configuration information. Consequently, we cannot use this differentiation for future versions of Etherboot since they will be sending VCI information. We would have to depend on a versioning scheme or something else to make a difference that we can use to send the newest version of Etherboot to the booting client. This time, we will use the fact that older Etherboot versions do not send VCI information to configure the dhcpd.conf file to be aware of the request from the non-VCI aware version of Etherboot and send a response that contains a new version of Etherboot that does send VCI information. The old version of Etherboot will execute the new version of Etherboot, which when requesting IP information from the DHCP server will send VCI information. The actual Vendor Class Identifier information that is sent to the DHCP server from Etherboot is (what do you know!) the string "Etherboot". You can contrast this with a PXE client that sends the string "PXEClient" for its Vendor Class Identifier. The "Etherboot" string will be used to match incoming requests from general or specific clients as your needs may be.

In the scenario that I had to do this, since there were only two different kinds of network cards with one kind being broken at the BOOTROM level (i.e., an older version of Etherboot was acting up causing kernel panics by generating spurious interrupts) and the client not monetarily able to fix the problem by replacing/reprogramming the BOOTROM's, I was able to get away with having all incoming DHCP requests funneled through a single if {...} else {...} block that checked for the VCI string equal to "Etherboot" or not and served the appropriate image, either a new version of Etherboot for those requests that don't send VCI information or the Etherboot tagged kernel image.

Now of course, you would like a dhcpd.conf configuration sample. Well, here is the generic case where all incoming requests are checked:

ddns-update-style none;
 
subnet 192.168.0.0 netmask 255.255.255.0
{
  range dynamic-bootp 192.168.0.100 192.168.0.200;
  option domain-name-servers 192.168.0.254;
  option routers 192.168.0.254;
  next-server 192.168.0.254;
 
  if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
    filename "/tftpboot/lts/vmlinuz.generic";
  }
  else {
    filename "/tftpboot/lts/rtl8139.rom.nbi";
  }
 
  group
  {
    use-host-decl-names on;

    ...
  }
}

Notice in this example that a very specific file is downloaded in the case where the DHCP request does not have the VCI information set to "Etherboot". That file is an NBI tagged ROM image, and that image is only for an RTL8139 chipset based network card. Obviously, this configuration is not very useful if you have more than just Realtek cards in your network of thin-clients and/or any other machines that retrieve their IP settings via DHCP. Of course the other DHCP clients on your network that are not using DHCP settings with which to boot will not be affected, since they should just throw away the 'filename' value and are not running that file anyway.

The next question you are doubtless to ask is how to create an NBI tagged ROM image for your network card(s). All you need is the mknbi utility -- that is downloadable in source or RPM and other formats from etherboot.sourceforge.net -- and the Etherboot ROM image for your network card. Install the mknbi utility, and a symbolic link to mknbi-rom will be created (among other symbolic links to mknbi that do other tagging functions). Download the Etherboot ROM image from www.rom-o-matic.net for your network card (or alternatively download and install the latest version of the Etherboot project and build your network card ROM from it). Use mknbi-rom to generate an NBI tagged version of the Etherboot ROM for your network card:

mknbi-rom --output=/tftpboot/lts/rtl8139.rom.nbi rtl8139.rom

That's all there is to generating the NBI tagged ROM. This will wrap a new version of Etherboot with the tagging information necessary to allow another version of Etherboot to download it and see it as a properly tagged format and execute it.

You can obviously put the generic check into specific host entries in order to hand out different NBI tagged Etherboot ROM images for all the different network cards you might have. Something similar to the following would be necessary in dhcpd.conf:

  host ws001 {
      hardware ethernet     00:02:B3:25:45:56;
      if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
          filename "/lts/vmlinuz.generic";
      } else {
          filename "/lts/ne2000.rom.nbi";
      }
  }

  host ws002 {
      hardware ethernet     00:02:B3:25:56:78;
      if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
          filename "/lts/vmlinuz.generic";
      } else {
          filename "/lts/sis900.rom.nbi";
      }
  }

...

I used mknbi-1.2. I'm not sure if the same technique can be applied with older versions of mknbi, but I would think so. You will also definitely need ISC DHCP 3.0 or better or a DHCP server that can recognize the 'vendor-class-identifier' option.

Hope this has been helpful.

Jason A. Pattie ltsp@pcxperience.com