4.1.4 PXELinux Configuration

If you have not already installed syslinux, you should do so:

# yum install syslinux

If you have SELinux enabled, you must also install the syslinux-tftpboot package to make sure that files are given the correct SELinux context:

# yum install syslinux-tftpboot

Copy the PXELinux binary, the menu system and the multiboot com32 module from the syslinux package to your tftp server root (/tftpboot by default):

# cp /usr/share/syslinux/pxelinux.0 /tftpboot/
# cp /usr/share/syslinux/vesamenu.c32 /tftpboot/
# cp /usr/share/syslinux/mboot.c32 /tftpboot/

Note

The pxelinux.0, vesamenu.c32 and mboot.c32 files must match the kernel requirements of the DHCP/PXE server. In our example, we use vesamenu.c32 to present a graphical boot menu and mboot.c32 to boot the installer into a Xen environment, however it is possible to simply use the mboot.c32 image on its own to perform the same function without a graphical menu. In all cases, these files should be copied from the syslinux package specific to your Oracle Linux installation where you intend to run the PXE server. Do not attempt to use the mboot.c32 or vesamenu.c32 files from an alternate location.

Create the pxelinux.cfg directory.

# mkdir /tftpboot/pxelinux.cfg

Create a PXE Menu configuration file at /tftpboot/pxelinux.cfg/pxe.conf containing the following configuration:

MENU TITLE  PXE Server 
NOESCAPE 1
ALLOWOPTIONS 1
PROMPT 0
menu width 80
menu rows 14
MENU TABMSGROW 24
MENU MARGIN 10
menu color border               30;44      #ffffffff #00000000 std

Create the /tftpboot/pxelinux.cfg/default PXE configuration file. Your configuration options may vary depending on your requirements. The following presents a guideline configuration:

DEFAULT vesamenu.c32 
TIMEOUT 800
ONTIMEOUT BootLocal 
PROMPT 0
MENU INCLUDE pxelinux.cfg/pxe.conf
NOESCAPE 1
LABEL BootLocal
        localboot 0
        TEXT HELP
        Boot to local hard disk
        ENDTEXT
LABEL OVS
        MENU LABEL OVS
        KERNEL mboot.c32
        # Note that the APPEND line should be unbroken, the \\ delimiter is used
        # to indicate that these line breaks should be removed
        APPEND ovs/xen.gz --- ovs/vmlinuz ip=dhcp \\
               dom0_mem=max:128G dom0_max_vcpus=20 \\
               ksdevice=eth0 ks=nfs:n.n.n.n:/srv/install/ks.config \\
               method=nfs:n.n.n.n:/srv/install/ovs --- ovs/initrd.img
        TEXT HELP
        Install OVM Server
        ENDTEXT

Replace n.n.n.n with the IP address of the DHCP/PXE server.

The default behavior on timeout is to boot to the local hard disk. To change the default behavior to force an install, you can change the ONTIMEOUT parameter to point to the OVS menu item. The important thing to remember here is that when an install is completed, the server reboots and if this option is not changed back to BootLocal, the server enters into an installation loop. There are numerous approaches to handling this, and each depend on your own environment, requirements and policies. The most common approach is to boot the servers using one configuration, wait for a period until they are all in the install process and then change this configuration file to ensure that they return to local boot at the time that they reboot.

The KERNEL location points to the mboot.c32 module. This allows us to perform a multiboot operation so that the installer loads within a Xen environment. This is necessary for two reasons. First, it is useful to establish that the Xen hypervisor is at least able to run on the hardware prior to installation. Second, and more importantly, device naming may vary after installation if you do not run the installer from within the Xen hypervisor, leading to problems with device configuration post installation.

Other things to note in the APPEND line:

The Xen hypervisor is loaded first and this is located within the path ovs/xen.gz in the TFTP server root. This is set up in the next step in this section.
The installer kernel is located within the path ovs/vmlinuz in the TFTP server root. This is set up in the next step in this section.
The IP address for the installer kernel is acquired using DHCP as configured earlier in this section.
Limits are applied to dom0 for the installer to ensure that the installer is stable while it runs. This is achieved using the parameters dom0_mem=max:128G and dom0_max_vcpus=20. These parameters are used by default when the installer is loaded from CDROM and it is recommended that they are used if you intend to perform a network install.
The Kickstart device is set to eth0. This is technically dependent on how your servers are cabled and configured. In some cases, detection of Ethernet devices may be unpredictable. You may find it more sensible to specify the ksdevice option to point to a particular MAC address using: ksdevice= 00:14:4f:ec:ad:80.
The Kickstart configuration path is specified pointing to an NFS server, which we configure and set up later in this section. The content of this file is also discussed in more detail in Section 4.2, “Using Kickstart to Automate Installation Options”. You could equally use HTTP or HTTPS for this, but in this example we set up an NFS server for this purpose.
The method is specified as using NFS and an export is also listed. This is the location of the content of the entire Oracle VM Server installation ISO, that will be used to copy the packages required for the installation. You could equally use HTTP or HTTPS for this, but in this example we set up an NFS server for this purpose.
The initial ramdisk image is located within the path ovs/initrd.img in the TFTP server root. This is set up in the next step in this section.
Although we have broken the APPEND line across multiple lines for readability, using the \\ delimiter to show that the line breaks, the entire APPEND statement must be on a single line.