We’ve shown you how to network boot the Ubuntu LiveCD. In this article we’ll show how to make some other utilities network bootable, which will give you the knowledge to replicate the procedure for other utilities you may be using.
Note: this article is not geared at beginners, though you’re welcome to keep reading!
Image by Steve Jurvetson
Overview
This guide aims to give you the tools with which, you will be able to convert utilities, to be PXEable. While unfortunately, it will not be possible to convert any tool under the sun, we wouldn’t be geeks if we didn’t at least try.
As mentioned on the “How To Network Boot (PXE) The Ubuntu LiveCD” guide, If you are not already using Ubuntu as your number one “go to” for troubleshooting, diagnostics and rescue procedures tool, what are you waiting for?
With that said, one has to acknowledge that there are things that simply cannot be done within the Ubuntu LiveCD (like BIOS upgrades), or that you are already using a different tool that you like and would rather keep on using for whatever reason.
Recommendations, Assumptions and Prerequisites
It is assumed that you have already setup the FOG server as explained in our “What Is Network Booting (PXE) and How Can You Use It?” guide. You will see the “VIM” program used as the editor, this is mainly because it is widely available on Linux platforms. You may use any other editor that you’d like. The Ultimate Boot CD (UBCD) is used as an example, as unlike some other utility collections, it is free to download and the programs it bundles are free to use.
Why not just use ISO over PXE?
This is often the first question asked when talking about PXEing. The short answer is that while technically it is possible to take an ISO image and PXE it to the client machines, almost always the content of said ISO, will be expecting to have the physical manifestation of itself accessible in the physical CDROM drive. Therefore, what ever the content of said ISO may be, it will try to look for the “post boot-sector” files in the physical CDROM drive of the client machine, will not find them and fail to boot.
The two ways to overcome this problem are:
Burn the ISO and put it in the CDROM drive of the client machine – While simple, Not using CDs, is exactly what we are trying to avoid… Open the ISO and change the way the program works within it, so that it uses a CDROM driver that knows how to look for the ISO in RAM – Fairly complex, and different for every type of bootable program. I. E. not the same procedure for Linux, WinPE or UBCD to mention a few.
As both of the above defeat the goal of “just using an ISO”, this is why we do not recommend pursuing this endeavor.
The Kernel method
While very rare, sometimes the program your trying to boot may only need a Kernel to function. One typical example of this is “memtest86+”. Memtest comes bundled with most Linux distributions installation CDs and with FOG. As Memtest only needs to be able to communicate with the most basic capabilities of the hardware tested, I.E. the memory (RAM), and can work just fine without even fully supporting the hardware it is running on (I.E. it will test the memory, even if it doesn’t know it’s type, speed & etc’) it has no need for anything else and can work completely autonomously.
The PXE menu entry for memtest may look as simple as:
In this example, the “LABEL Run Memtest86+“ sets the name of the entry, the “kernel fog/memtest/memtest” tells PXElinux where to take the kernel that will be sent to the client from and “append –“ tells PXElinux to ignore additional boot options from *inheritance.
*Note: depending on your setup, this may not even be required and actually in FOG it is not used.
The Kernel + Initrd method
This method is by far the most commonly used and widely spread for a couple of reasons:
A lot of utilities nowadays come from the Linux world. Because Linux has great hardware support and is free to use, more and more companies realize that Linux is an excellent base to build their proprietary programs on.
Lets use UBCD’s CPUstress utility as an example.
On the UBCD file structure, this utility is located in the directory “ubcd/boot/cpustress”. The files we are looking for, are called “bzImage” which is the “kernel”, and “initrd.gz” which is the “initial ram disk”. If you’re using the FOG setup we created, we recommend that you copy the directory under “/tftpboot/howtogeek/utils”. Once that’s done, edit the “/tftpboot/howtogeek/menus/utils.cfg” file and add to it the boot entry found on the UBCD’s menu entries. this can be found in “ubcd/menus/syslinux/cpu.cfg”. With the adjustments for the FOG setup, the menu entry should look like:
Where :
MENU LABEL – sets the name of the entry TEXT HELP – This optional directive, gives help text that will be shown in the menu to provide information on the entry selected. KERNEL – Specifies the location of the “kernel” file in the TFTPD directory. INITRD – the same as above only for the “initrd” file. APPEND – Specifies additional parameters that should be passed to the booted program.
A couple of things to note are:
Hardcore geeks would notice that we replaced the original directive of “LINUX” with “KERNEL”. This is because: A. this makes the example easier to read. B. In this example it doesn’t really matter. With that said, usually when the directive “LINUX” is used, it is better to leave it that way because it tells pxelinux/syslinux that we are not using just any kernel but a Linux one. We have deliberately taken the “quiet” directive out of the appended parameters. This is due to a change in how Syslinux handles the “quiet” parameter in recent versions. It is possible to change the operation of the “StressCPU” program, by simply changing the appended parameter “ubcdcmd”. So in order to use the other functions, one needs only to copy the entry and replace “stresscpu2” to be: cpuinfo, cpuburn or mprime24.
While this is a very simple example, it should be enough to get you going.
The Kernel + Initrd + NFS method
This method, is the one we used on the “How To Network Boot (PXE) The Ubuntu LiveCD” guide. This method builds on the previous one and utilizes the fact that some Linux distributions support having their “root filesystem” mounted from NFS. The Ubuntu guide is an excellent example, but rest assured that we already have another one planned for the near future. “Keep your eyes open for a Black Mushroom”.
The MEMDISK method
MEMDISK is a utility that is distributed with the Syslinux package. The purpose of this utility is to enable you to emulate a “disk” (mainly referring to floppies) using it’s image. The way this utility works, is to hook into the location in RAM that specifies how to communicate with the floppy drive (A.K.A. Interrupt handler) and points it to a new location that is handled by the MEMDISK program. With this method, the “kernel” is the MEMDISK utility and the “initrd” is the floppy image (.img) file.
The one thing to note is, that FOG comes with a “memdisk” version that is compatible to the pxelinux.0 version it uses. Therefore, it is recommended to not copy the “memdisk” file accompanying the “img” file from their source.
As this method is already wildly used, even for regular utilities and BootCDs, most of the time it is a simple matter of finding the “IMG” file on the BootCD, copying it to the PXE’s server TFTPD directory and copying the ISOlinux menu entry to the PXElinux menu. They say “talk is cheap” so lets have a look at how can we adapt one of the utilities that use the MEMDISK method from UBCD, to work from PXE.
The TestMemIV utility, can be found on the UBCD file structure at “ubcd/images/testmem4.img.gz”. As we already have the memdisk disk utility, one only needs to copy the “img” file to the “howtogeek/utils/” directory. With the adjustments for the FOG setup, the menu entry should look like:
While this is an example of a self contained floppy image file from UBCD, most of the other UBCD programs, use the same base image to start working (fdubcd.img.gz) and use the “ubcdcmd” appended parameter to autostart a program from the CDROM post boot. This means you will not be able to convert most of their utilities to be network bootable without some major reverse engineering. While such a reverse engineering is possible (as can be seen here) and is an excellent geek exercise, it is beyond the scope of this guide.
With the above said, you now have the tools to perform this procedure for that esoteric OEM diagnostic or BIOS upgrade utility.
And so, locked beyond the Gateway of Blood and past the Hall of Fire, Valor awaits for the Hero of Light to awaken…
