Skip Headers
Oracle® Enterprise Manager Lifecycle Management Administrator's Guide
12c Release 4 (12.1.0.4)

E27046-27
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

D Understanding PXE Booting and Kickstart Technology

This appendix explains PXE booting and kickstart technology in the following section:

D.1 About PXE Booting and Kickstart Technology

One of the key requirements of provisioning is the hardware server's ability to boot over the network instead of a diskette or CD-ROM. There are several ways computers can boot over a network, and Preboot Execution Environment (PXE) is one of them. PXE is an open industry standard supported by a number of hardware and software vendors. PXE is part of the "Wired for Management" (WfM) specification, which is part of a bigger PC98 specification defined by Intel and Microsoft in 1998. A detailed document on PXE specification can be found at http://www.pix.net/software/pxeboot/archive/pxespec.pdf.

PXE works with Network Interface Card (NIC) of the system by making it function like a boot device. The PXE-enabled NIC of the client sends out a broadcast request to DHCP server, which returns with the IP address of the client along with the address of the TFTP server, and the location of boot files on the TFTP server. The following steps describe how it works:

  1. Target Machine (either bare metal or with boot sector removed) is booted.

  2. The Network Interface Card (NIC) of the machine triggers a DHCP request.

  3. DHCP server intercepts the request and responds with standard information (IP, subnet mask, gateway, DNS etc.). In addition, it provides information about the location of a TFTP server and boot image (pxelinux.0).

  4. When the client receives this information, it contacts the TFTP server for obtaining the boot image.

  5. TFTP server sends the boot image (pxelinux.0), and the client executes it.

  6. By default, the boot image searches the pxelinux.cfg directory on TFTP server for boot configuration files on the TFTP server using the following approach:

    First, it searches for the boot configuration file that is named according to the MAC address represented in lower case hexadecimal digits with dash separators. For example, for the MAC Address "88:99:AA:BB:CC:DD", it searches for the file 01-88-99-aa-bb-cc-dd.

    Then, it searches for the configuration file using the IP address (of the machine that is being booted) in upper case hexadecimal digits. For example, for the IP Address "192.0.2.91", it searches for the file "C000025B".

    If that file is not found, it removes one hexadecimal digit from the end and tries again. However, if the search is still not successful, it finally looks for a file named "default" (in lower case).

    For example, if the boot file name is /tftpboot/pxelinux.0, the Ethernet MAC address is 88:99:AA:BB:CC:DD, and the IP address 192.0.2.91, the boot image looks for file names in the following order:

    /tftpboot/pxelinux.cfg/01-88-99-aa-bb-cc-dd
    /tftpboot/pxelinux.cfg/C000025B
    /tftpboot/pxelinux.cfg/C000025
    /tftpboot/pxelinux.cfg/C00002
    /tftpboot/pxelinux.cfg/C0000
    /tftpboot/pxelinux.cfg/C000
    /tftpboot/pxelinux.cfg/C00
    /tftpboot/pxelinux.cfg/C0
    /tftpboot/pxelinux.cfg/C
    
  7. The client downloads all the files it needs (kernel and root file system), and then loads them.

  8. Target Machine reboots.

    The Provisioning application uses Redhat's Kickstart method to automate the installation of Redhat Linux on target machines. Using kickstart, the system administrator can create a single file containing answers to all the questions that will usually be asked during a typical Red Hat Linux installation.

    The host specific boot configuration file contains the location of the kickstart file. This kickstart file would have been created earlier by the stage directive of the OS image based on the input from user.

D.2 Subnet Provisioning Usecases

Following are examples of subnet provisioning usecases:

Subnet of size 256

IP Prefix: 192.168.1.0

Subnet Mask: 255.255.255.0

Covers IPs from 192.168.1.0 - 192.168.1.255

Subnet of size 16

IP Prefix: 192.168.1.0

Subnet Mask: 255.255.255.240