I promise I will leave it alone but I couldn’t resist the temptation of adding the option to install Windows 7 and Windows 2008 to the menu option. Thanks to the instructions below (and the very handy exe files to do it all automatically for you that are available at the same location – http://diddy.boot-land.net/pxe/files/winpe.htm), the longest part of the process was to download the Windows 7 Automated Installation Kit (WAIK), and I was then up and running in a flash. First create a WinPE 3.0 image using the installed WAIK (it does install fine on Windows XP, wasn’t sure I didn’t need Windows 2003 but it was fine), then deploy it to the tftp install – all that automated through 2 scripts! Awesome job, and it does work!
Once WinPE 3.0 is booted, it is a matter of mapping the location of the Windows 7 or Windows 2008 installer via the command prompt and run setup.exe. Hey presto, one network install coming right up!
Following my previous set-up (and its limitations), I became curious about booting a “normal” OS (not an OS loading in memory, a full-blown OS which I could customize) from the network (i.e. a remote disk).
In order to serve the disk over the network, I went with iSCSI and for the free version of the Star Wind iSCSI San software – http://www.starwindsoftware.com/starwind-free. In a nutshell, the free version allows you to create virtual drives (.img files) and to serve them as SAN drives over the network. Easy to install but note you need Windows Server 2003 to install it on (XP won’t do and this is not clearly stated anywhere). Also note that since the .img files are created on that machine, you need to plan for size – about 11G for my vanilla version of Windows 2003 then 4GB for Red Hat and Fedora each, 8 GB very minimum for Windows 7.
Once you have created your virtual drive served by StarWind, it can then be chainloaded from the PXE server itself. I am still using gPXE for that. Despite figuring out it is out of date and has officially been replaced by iPXE http://www.ipxe.org, I decided to stick with it because it works, there is more documentation and with rom-a-matic, you can compile your executables over the web and download the binaries without having to build on your own machine.
It is also worth noting that,whichever OS you install on SAN is still tied to the machine you installed it to (“on”) in terms of drivers, interface names… Having the OS available on the SAN doesn’t mean it is bootable by any machine on your network unfortunately,unless they have all the exact same configuration.
I installed Fedora 14 to SAN without issues following the instructions on the gpxe website. The Red Hat 5.5 installer has a bug and I had to actually take the harddrive out, then go through the installer for the grub loader to be saved to the SAN drive rather than the local drive (if it gets saved to the local drive, nothing will work). Same steps for Windows 7 to be installed over the SAN. I did several attempts at both sets of instructions (both on the ipxe and gpxe websites) to get Windows XP to work from a SAN drive but to no avail.