Understanding PXE

PXE is a specification created by Intel to enhance the original network boot protocols: BOOTP, TFTP and DHCP.

BOOTP, RARP and TFTP were created by the IETF to enable systems to automatically retrieve their network configuration and initial bootloader from a server.

The initial BOOTP standard was limited to a number of fixed fields in which client and server could exchange information. A client could supply its hardware address in chaddr, and request a specific type of file, and would receive its ip address as yiaddrand a servername sname. Combined with the server IP address field (siaddr) and the gateway IP address field, and the returned boot file name (file) this would tell the boot client where to retrieve its boot image, using TFTP.

BOOTP Fields

ciaddr 4 client IP address yiaddr 4 your IP address siaddr 4 server IP address giaddr 4 gateway IP address chaddr 16 client hardware address

sname 64 optional server host name, null terminated string.

file 128 boot file name, null terminated string;

vend n n=64 in original BOOTP, starts with the 4 byte DHCP ’magic’ number.

Over time networks and IT infrastructure became more complicated and requirements more demanding. To allow clients to provide more information about themselves and to retrieve tailored information, BOOTP received the BOOTP Vendor Informa-tion Extensions [RFC 1048], which in turn was enhanced with a new protocol, DHCP. DHCP extended BOOTP with a number of standard options, defining different types of messages. Some DHCP options may overlap with standard BOOTP fields, and should contain the same value in that case.

Note

A DHCP message is a BOOTP packet (request or response) with a special 4 byte value (the DHCP magic cookie) in the BOOTP "Vendor Information Field". Following that are DHCP options, consisting of a single byte option type, a length field, and lengthbytes of option content.

This rule has two exceptions: Padding (0) and End of Options (255) are just one byte in length and lack a length field.

Finally, Intel introduced PXE, to enhance the BOOTP/DHCP protocol even further, in an attempt to standardise the way clients can identify themselves. This allows boot clients and servers to minimize the number of packets that needs to be exchanged before they can decide on the correct parameters and the boot program needed to get going.

A PXE boot request starts with a DHCP Discover message including at least five options, of which three are PXE-specific:

(53) DHCP Message type (DHCP Discover), (55) Parameter Request List,

(93) Client System Architecture, (94) Client Network Device Interface, (97) UUID/GUID-based Client Identifier

Options 93, 94, and 97 are defined in the PXE specification. In addition, option 55, the Parameter Request List, must *also*

request options 128 through 135, even though a server is not required to provide a response to them. This list and the three options listed above act to identify the client as PXE aware.

Proxy DHCP for PXE

Not every DHCP server (especially those embedded in network equipment) will be able to process a PXE request.

The PXE specification allows PXE-aware DHCP servers to co-exist with simple DHCP servers, where the default DHCP server provides the basic network detail. The PXE-aware server can then provide additional detail for the actual TFTP boot process.

This is called proxy-DHCP.

It is even possible to separate DHCP services on the same server, in which the proxy DHCP service is expected to listen to UDP port 4011.

Example DHCP request

See below for an example DHCP Discover message, including requests for standard network detail such as (1) Subnet Mask, (3) Router, (6) Name server, (12) Host Name, (15) Domain Name, etc.

Example 2.2 DHCP Discover message

Parameter Request List Item: (6) Domain Name Server Parameter Request List Item: (12) Host Name

Parameter Request List Item: (13) Boot File Size Parameter Request List Item: (15) Domain Name Parameter Request List Item: (17) Root Path Parameter Request List Item: (18) Extensions Path

Parameter Request List Item: (22) Maximum Datagram Reassembly Size Parameter Request List Item: (23) Default IP Time-to-Live

Parameter Request List Item: (28) Broadcast Address

Parameter Request List Item: (40) Network Information Service Domain Parameter Request List Item: (41) Network Information Service Servers Parameter Request List Item: (42) Network Time Protocol Servers Parameter Request List Item: (43) Vendor-Specific Information Parameter Request List Item: (50) Requested IP Address

Parameter Request List Item: (51) IP Address Lease Time Parameter Request List Item: (54) DHCP Server Identifier Parameter Request List Item: (58) Renewal Time Value Parameter Request List Item: (59) Rebinding Time Value Parameter Request List Item: (60) Vendor class identifier Parameter Request List Item: (66) TFTP Server Name

Parameter Request List Item: (67) Bootfile name

Parameter Request List Item: (97) UUID/GUID-based Client Identifier Parameter Request List Item: (128) DOCSIS full security server IP [TODO]

Parameter Request List Item: (129) PXE - undefined (vendor specific) Parameter Request List Item: (130) PXE - undefined (vendor specific) Parameter Request List Item: (131) PXE - undefined (vendor specific) Parameter Request List Item: (132) PXE - undefined (vendor specific) Parameter Request List Item: (133) PXE - undefined (vendor specific) Parameter Request List Item: (134) PXE - undefined (vendor specific) Parameter Request List Item: (135) PXE - undefined (vendor specific) Option: (97) UUID/GUID-based Client Identifier

1. Name all four user-mode processes, one of which the kernel will try to execute as the final step in the boot process.

In the final step in the boot process, the kernel will try to execute one of the following programs as the first user-mode process: /sbin/init, /etc/init, /bin/init and /bin/sh.First user-mode process[45]

2. The parent of all processes init can be found running in one of eight runlevels. What type of levels are the runlevels 2, 3, 4, and 5?

These runlevels are multi-user runlevels.Multi-user runlevels[45]

3. What does it mean when the action field in the file /etc/inittab contains the string wait?

The process specified in the fourth field of the same line will be started just once when the specified runlevel is entered and init will wait for its termination.The file /etc/inittab[46]

4. What type of files do the directories /etc/rc*contain?

These directories contain symbolic links to scripts in /etc/init.d starting with either an S or a K which will call the script with either a start or a stop parameter.The /etc/init.d/rc script[47]

5. What is the purpose of the Linux Standard Base (LSB) standard?

It ensures that a program compiled in an LSB compatible environment will run on any distribution that supports the LSB standard (within a certain processor architecture).The LSB standard[49]

6. What is chain-loading?

Chain-loading implies that GRUB will be used to boot the system, and in turn will load and run the proprietary systems bootloader, which then boots the operating system.GRUB chain-loading[53]

7. What is the purpose of the grub-install command?

The grub-install command is used to install stage 1 to either the MBR or within a partition. The command grub-install [56]

8. Which command enables you to switch to a different runlevel?

This is done via the telinit command.The command telinit[56]

9. During boot a filesystem check fails. You read something like fsck failed. Please repair manually followed by CONTROL-D will exit from this shell and continue system startup. How do you proceed?

If you do not press CTRL-D but enter the root password, you will get a shell, in fact /sbin/sulogin is launched, and you should be able to run fsck and fix the problem if the root filesystem is mounted read-only. When fsck is started but fails [57]

Chapter 3