There are several ways to handle PXE booting. PXE is a fairly broad specification, and allows for use of certain DHCP options to tell the client where to grab the necessary boot files. According to the documents, the version 3 of the ISC DHCP server is required to work properly with PXE, though apparently certain work arounds can be done for version 2 of the server.
Also, a separate PXE service can be run in conjunction with a DHCP server on the local network. The DHCP server must support certain options for this arrangement to work. In my environment, I do not have direct control over the DHCP server on my subnet, but the DHCP server works fine with a separate PXE server. PXE runs on another machine on my network.
My clients are configured to boot up and attempt to boot off the network using PXE. The rough process for booting is:
BIOS initialization, etc
DHCP Request
PXE Broadcast
Load the PXE environment
Based user input, either boot locally or boot over the network.
By default, my environment will currently boot locally. This has the implication of unloading the PXE environment, and handing everything off to a more traditional method of booting. If booting locally, our interest in the boot process (from a PXE perspective) ends here.
If the user interrupts the process, then the configuration will determine what happens next, and what the options are. By default, this is a "Remote Install Linux" option.
Load the next stage.
This is a swing point. The first set of instructions I used led to the use of NBP (network boot prompt.) This is an extremely limited and limiting environment.
With some encouragement, I moved to pxelinux, which is a network version of the ever popular syslinux boot loader.
Do whatever the configuration says.
From here on out things depend completely on what the boot loader is configured to do. But, from the PXE booting viewpoint, once we've reached this point, we've done most of the interesting stuff with regards to PXE booting.
Assuming the DHCP server is fine, configuring the PXE server starts with installing a few packages. The quick fix method is to install the pxe rpm:
yum install pxe
|
At this stage it is a good idea to read through the README that comes with the package: /usr/share/doc/pxe-0.1/README
This README covers the basics on how to get a PXE environment up and running. The main "equipment" it notes as being necessary are the DHCP server, a PXE server, and TFTP/MTFTP daemons. It's instructions include the setting up of the NBP for PXE clients.
After the installation of the pxe service, if tftp is not installed, install it:
yum install tftp
|
Then, install the pxelinux stuff. This is done mostly by hand. From http://syslinux.zytor.com/pxe.php, follow the download links and grab the latest syslinux tar ball.
Just to clear up any potential confusion, pxelinux and the pxe service are different entities. It is also probably important to note that PXE proper is a specification, not actual code. Even though some of the derivative products use the term "PXE", they are the sum total of what PXE is, just an implementation of PXE.
The Linux pxe service helps the PXE client get to the files it needs, pxelinux is a boot loader along the same lines of syslinux. It is small, simple and works rather well for PXE boot loading.
The pxe rpm installs a default configuration file and the binary that is the NBP. The NBP is a base line boot loader as well. For the purposes of my configuration, I removed the linux.0 (to avoid confusion), and replaced it with the pxelinux.0 found in the syslinux tar ball. Just copying the file from the tar ball to /tftpboot/X86PC/UNDI/linux-install sufficed.
To get the PXE server to access the pxelinux boot loader, some modifications to the default configuration file were necessary, specifically, the section of the /etc/pxe.conf that looked like:
# Image file name for Linux install boot server type
# format : <min layer #> <max layer #> <base file name>
[X86PC/UNDI/linux-install/ImageFile_Name]
0
2
linux
|
Was changed to look like:
# Image file name for Linux install boot server type
# format : <min layer #> <max layer #> <base file name>
[X86PC/UNDI/linux-install/ImageFile_Name]
0
0
pxelinux
|
Also, the pxelinux configuration file was created. This is looked for in a directory named pxelinux.cfg rooted in the same location as the pxelinux.0 file is found. The file name for a client is related to the IP address of the client, with the filename of default applying to clients that have no explicit match.
My default file looks like:
default linux
timeout 0
prompt 1
serial 0 9600
display display.msg
label linux
kernel vmlinuz-7.3
append initrd=initrd-7.3.img
label 7.3
kernel vmlinuz-7.3
append initrd=initrd-7.3.img
label 8.0
kernel vmlinuz-8
append initrd=initrd-8.0.img lang= lowres devfs=nomount ramdisk_size=9216
|
To accommodate the pxelinux configuration file, all the filenames (kernels and initrds) must be present in the same directory as the pxelinux.0. This is the directory structure relevant to the pxe booting.
$ ls -R
.:
display.msg initrd-8.0.img pxelinux.0 vmlinuz-7.3 vmlinuz-8.0
initrd-7.3.img initrd.img pxelinux.cfg vmlinuz-8
./pxelinux.cfg:
default
|
The kernels and the initrd files were gathered from the respective distribution's images/pxeboot directories.
Once all the files are in the right places, the pxe service can be started, along with the tftp service.
service pxe start
chkconfig pxe on
service xinetd start
chkconfig xinetd on
chkconfig tftp on
|
Following this, start testing by booting the client, watching log files and packet dumps, swearing, and tweaking.
A general list of thoughts and considerations for building this environment.
Intel's Preboot Execution Environment (PXE) Specification
ftp://download.intel.com//labs/manage/wfm/download/pxespec.pdf
README from the PXE server installation.
/usr/share/doc/pxe-0.1/README
Syslinux/PXElinux homepage.
http://syslinux.zytor.com/pxe.php