PXE Boot OS and configuration

Our systems install via PXE boot whenever possible. Much faster than DVD/CD, floppies and alike. I have been fighting with PXELINUX (part of the excellent SYSLINUX package of boot loaders with menus) trying to get it working the way I want it to. This is important for JackRabbit and our compute clusters.

Of course I was using the native SYSLINUX package, something around version 2.09 or something like that. I had pxegrub loading, but then it would basically hang while working with the network. Well, not hang, but largely come to a grinding halt … with an occasional packet every now and then. This is frustrating, as I really want a single unified menu using grub to handle local and remote loads, booting, and diagnostics. From what I can see grub is not up to the task. Or put more correctly, pxegrub is not up to the task. It would be nice if grub were up to the task, but alas, again it is not. Grub, or more correctly grub-legacy has been stuck in limbo since 2005-ish, with new development going on for Grub2. Looking over the project pages for grub2, I am not sure that it is ready for prime time. So, we write grub off. Hopefully someone will either revive that project or a better one will come along and replace it. Unfortunately, in writing grub off, we have to think about the potential impact upon our clusters, compute and storage. How do we present a single menu to the end user? The Syslinux 2.09 package didn’t have that capability. So we started looking at doing a diskless boot and then reconfiguring the boot loader based upon menu choices. A little hackish, but workable. Unfortunately setting up Linux to diskless boot was not as easy as I had hoped. Still working on it, but we should have what we need together soon. This is helpful in diagnostic mode. Think of something like booting pxeknife/UBCD via PXE, as well as other tools. So looking over the syslinux, I noticed on pxelinux, all these new menu.c32 type things in the boot directory. Some googling and … … sonofagun … Modern syslinux (3.36 I think) does what I want. No changes to the menus, and the menus can be nested, and somewhat complex. All righty then … We might still be able to have one base menu for all units. This is goodness. With this set up, we will work on NFS, iSCSI, AoE, and other booting (can we boot over CIFS, or even better, can we boot Windows images?)