This topic describes the process for Intel/AMD x86 computers, Intel/AMD x86-64 bit computers based on the
UEFI standard, SUN SPARC and IBM® PowerPC® machines
based on the OpenBoot standard.
A network boot application is different from any other program
for a number of reasons:
- It is invoked by the BIOS during the initial bootstrap of the
computer, before any operating system or disk boot manager.
- It depends on the presence of a special chip on the network card,
the PXE boot ROM.
- It is capable of communicating with a server over the network
thanks to a programming interface provided by the bootrom. PXE is
the informal standard for this kind of programming interface.
- It is downloaded from a special OS deployment server, and does
not depend on any local storage device. It can work on computers without
hard disk, CD or diskette devices. If a local storage device is present
on the computer, it is accessible to the network boot application.
However, a network boot application does not fail if the storage device
is corrupted or broken.
- It gets its parameters (IP address and other boot parameters)
from a central DHCP server.
A typical network-boot sequence goes through the following phases:
- Starting up: A user or a wake-up event starts the remote-boot
computer up.
- Network boot: The BIOS configuration (boot order), a hot
key (for example, F12), or the wake-up event instructs the computer
to boot on the network.
- IP address discovery: The remote-boot target broadcasts
a DHCP request for an IP address. Any DHCP server which knows the target (that
is, recognizes its hardware address) or which has a pool of freely
distributable dynamic addresses sends an IP address. The target takes
the first answer and confirms it to the server. In addition to the
IP address, the server gives some other network parameters to the target and
information about the boot procedure to follow.
- OS deployment server discovery: In the case of PXE remote-boot,
the target computer then proceeds to the discovery of the OS deployment server.
The OS deployment server is responsible for delivering a network boot
program to the target. It
is not necessarily the same computer as the DHCP server. The target responds
to the first OS deployment server which replies and downloads a small
program using a simple multicast protocol (MTFTP).
- Server connection: If the network boot program is the deployment
engine, it establishes a secure (encrypted) connection to the OS deployment server and
receives instructions from the server to determine the name of the
program to run.
- Pre-OS configuration: The deployment engine then downloads
from the file server everything required by the OS configuration specified
by the system administrator. These file transfers are done using a
secure, robust and efficient unicast or multicast protocol. Many actions
can be performed at this stage: installing an operating system from
scratch, repairing a corrupted operating system, or performing an
inventory.
- OS booting: When instructed by the OS configuration, the
deployment engine removes itself from memory and allows the computer
start the operating system, as if the target is booting
normally from the hard disk. This ensures full compatibility with
the operating system and avoids all problems of the traditional diskless
remote boot.
Note: Tivoli® Provisioning Manager for OS Deployment features a fault-tolerant server architecture, with the OS
deployment server always available to the target. However,
in case of severe network failure, targets can be configured to work
in offline mode, without network access. In this scenario, the deployment
engine is stored on a permanent storage medium, such a hard disk partition
or a CD, and started from that medium instead of being loaded from
the network.