PXE Boot Explained: Automating Bare Metal OS Installs

PXE boot lets a server load boot software over a network before an operating system starts. To automate a bare metal OS installation, that boot environment must also start an installer and supply its configuration. PXE provides the starting point. The installer performs the disk changes.

This distinction explains why a server can reach a network boot menu but still require manual input. It also explains why a successful installation can start again after a reboot if the deployment system still treats the machine as an installation target.

We need to control the whole path: identify the server, load the correct boot files, apply the intended OS configuration, and return the machine to normal local boot.

What Is PXE Boot, and Where Does Installation Begin?

PXE stands for Preboot Execution Environment, commonly pronounced “pixie.” It provides a standard way for compatible firmware to start software obtained from a network.

The target does not need a working OS on its local disks. It does need compatible firmware, a supported network interface, and access to the required boot services.

Network boot, OS installation, and first-boot configuration

These stages have different jobs:

Stage	Main task	Result
Network boot	Obtain and run boot software	An installer or live environment starts
OS installation	Apply the storage layout and install system files	An OS exists on the intended disk
First-boot configuration	Apply supported initialization settings	The installed system has its required initial configuration
Handoff checks	Check access, networking, and system state	The server is ready for its agreed next task

A PXE boot can also start diagnostics or a rescue environment without installing anything. Network boot alone does not mean that a disk will be erased.

When PXE fits a bare metal workload

PXE is useful when we repeatedly install servers with known configurations. Examples include cluster nodes, development labs, replacement machines, and approved OS rebuilds.

The initial work includes network design, boot-file maintenance, and installer configuration. That investment becomes useful when it replaces repeated manual work across multiple deployments.

For one remote server, virtual media through a management controller may require less setup. For the wider deployment process, see our bare metal provisioning guide.

What Does a PXE Boot Environment Need?

A working environment needs compatible boot software, reachable services, and a clear installation target. Several services can run on one host in a small lab.

Server firmware, network access, and boot files

Record the target’s firmware mode and CPU architecture before selecting a boot program. A file intended for legacy BIOS cannot simply replace a UEFI application. An x86-64 EFI application is not an ARM64 boot program.

Also identify the physical NIC and switch network used for installation. A server with several interfaces may attempt network boot through a port that has no access to the boot services.

The main components are:

Component	Purpose
DHCP service	Supplies network settings to the client
Boot information service	Tells the client which boot program to request
Network boot program	Starts the next boot stage
Installer files	Provide the environment that installs the OS
Installation source	Supplies the OS content or packages
Answer file	Defines supported unattended installation choices
Deployment record	Tracks the intended machine, profile, and outcome

The deployment record is an operating control. It is not a requirement built into the PXE protocol.

TFTP, HTTP, and HTTPS

Traditional PXE commonly uses TFTP to retrieve the initial boot program. Later stages can use other transports, including HTTP or HTTPS, depending on the boot software and installer.

Service	Typical traffic	Detail to check
DHCP over IPv4	UDP 67 and 68	Client access and any relay path
TFTP	Initial request to UDP 69	Transfer uses negotiated UDP ports afterward
HTTP	TCP 80	File paths and reachability
HTTPS	TCP 443	Certificate trust in the client that fetches the files
Deployment-specific PXE service	May use UDP 4011	Required only for applicable implementations

This is a starting point for an IPv4 design, not a universal firewall ruleset. IPv6 boot has separate requirements. Check the selected platform’s network documentation before applying access rules.

How Does PXE Boot Work, Step by Step?

The first stages establish network access and load a boot program. Installation begins only after the selected software takes control.

1. The server starts network boot

Firmware selects the network interface and starts its network boot process. We can select it through a boot menu or use a supported one-time boot setting through remote management.

At this point, check that the intended port has a link and reaches the installation network.

2. The client receives network settings and boot information

The client requests network configuration. It also identifies information relevant to network boot, including its architecture.

The address allocation and boot information can come from the same service or separate services. A proxyDHCP design can provide boot information while an existing DHCP server continues to assign addresses.

3. The client loads a compatible boot program

The boot service directs the machine to an appropriate file. The client downloads it and transfers control to it.

This program may load another bootloader, display a menu, or start an installation environment. A DHCP lease alone does not prove that the correct program was selected.

4. The boot program starts the installation environment

For a Linux installer, this commonly involves a kernel and an initial RAM filesystem, often named initrd. The installer may then retrieve more files from a repository or installation image.

Network settings can change at this handoff. Firmware network access does not prove that the installer has a working NIC driver, route, or DNS configuration.

5. The installer applies its instructions

An unattended configuration supplies choices such as disk layout, packages, hostname, and authorized access. Without the appropriate configuration, the installer may stop for input or use defaults.

This is the stage where storage can be changed. The selected disks must match the approved installation profile.

6. The system returns to normal boot

After installation, the workflow must remove the machine’s permission to receive another destructive install. The server then starts its installed OS and completes its handoff checks.

Treat a second successful local reboot as part of the acceptance check. A working first login does not prove that the next boot will preserve the installation.

DHCP options, proxyDHCP, and relays

Options 66 and 67 commonly describe a boot server and boot filename. They are not the only way to deliver boot information. DHCP configuration directives such as next-server also have meanings that should be checked against the selected server software.

Across routed networks, broadcasts need suitable relay handling. Microsoft’s Configuration Manager guidance recommends IP helpers for its supported cross-subnet PXE design. That product guidance should not be treated as the only possible design for every PXE implementation. Microsoft’s routed PXE documentation explains its requirements.

PXE vs iPXE vs UEFI HTTP Boot

These names describe related boot paths and software. They are not three complete OS deployment systems.

Approach	How it starts	Useful capability	Main check
Traditional PXE path	Firmware obtains and runs a network boot program, commonly through TFTP	Starts an installer without local media	Boot-file and firmware compatibility
iPXE	Runs as network boot firmware or a loaded boot program	Adds scripts, menus, and supported network transports	Build features, drivers, and trust configuration
UEFI HTTP Boot	Compatible UEFI firmware retrieves a boot application through HTTP Boot support	Can start a network boot chain without a TFTP first stage	Firmware support and application compatibility

What iPXE adds

iPXE lets us express boot decisions in scripts. A script can select files, pass installer arguments, offer a menu, and handle a failed request.

An existing PXE implementation can load iPXE as its next program. This is called chainloading.

That path needs a clear second stage. If iPXE requests boot information and receives its own binary again, the machine can keep reloading iPXE. The iPXE project’s chainloading guide describes ways to avoid this behavior, including different responses for iPXE clients and embedded scripts.

UEFI and Secure Boot

UEFI support does not automatically mean that a boot file will run with Secure Boot enabled. The executable and later boot components must fit the machine’s trust policy.

The iPXE project provides a documented Secure Boot path with signed release components. Check the relevant architecture and downstream OS requirements. Do not assume that any locally compiled EFI file will work with the same settings.

Also separate transport security from boot-code trust. Plain HTTP does not encrypt downloads. HTTPS protects supported network transfers when certificate checks work. Secure Boot applies trust checks to executable stages in the boot chain.

How Do You Automate the OS Installer?

The answer file belongs to the installer. A boot script can point to that file, but it does not replace the installer’s storage and configuration logic.

Select the correct configuration format

System or task	Common method	Boundary
Ubuntu Server with Subiquity	Autoinstall YAML	Match the format and delivery method to the release
RHEL and compatible Anaconda installers	Kickstart	Check distribution and release support
Debian Installer	Preseed	Do not substitute it for current Ubuntu Server autoinstall
Windows deployment	Windows PE plus the selected installation or image workflow	Starting WinPE alone does not install Windows
Supported system initialization	cloud-init	Its role depends on the image and deployment workflow
Ongoing configuration	Ansible or another configuration tool	Requires the access and software needed by that tool

Canonical’s documentation identifies autoinstall as Ubuntu’s automated installation format. Red Hat’s installation documentation covers Kickstart and its installer options.

Define the server profile before changing storage

A useful profile answers six questions:

1. Which physical machine may run this installation?
2. Which OS release and boot mode should it use?
3. Which disks may the installer change?
4. Which network settings should the installed system receive?
5. Which users and keys may access it?
6. What proves that the installation is complete?

Use a stable disk identifier supported by the installer where possible. Do not assume that the first listed disk is always the intended OS disk.

A MAC address can help select a profile, but it is not strong proof of identity. Network access controls and deployment authorization still matter.

Example Workflow: An Unattended Ubuntu Server Installation

The following is a reference workflow for planning a controlled lab installation. It is not a report of an Atal hardware test or a universal configuration recipe.

Record the environment

Start with one disposable x86-64 UEFI target on an isolated IPv4 installation network. Record the selected Ubuntu Server LTS release, firmware version, Secure Boot state, DHCP owner, and intended disk.

Keep the OS image, kernel, and initramfs aligned with the selected release. Record their origins and checksums so the same inputs can be used again.

The lab should have remote console access. This lets us inspect a failure before SSH or another OS-level service exists.

Prepare the files and boot path

Host the required installation files at known paths. Check permissions and access from the installation network.

Configure the first-stage boot program for the target’s firmware and architecture. If using iPXE, give the client a second-stage script that leads to the installer rather than back to the iPXE binary.

Supply the autoinstall configuration using a method supported by the chosen release. Define storage, networking, and authorized access deliberately. Keep credentials out of publicly accessible files and logs.

A boot menu that loads the installer is one completed checkpoint. Successful retrieval of its configuration is another. Check both before treating the workflow as unattended.

Run one controlled installation

Confirm that the target contains no data that must be retained. If it does, complete and check the required backup before proceeding.

Trigger a one-time network boot and observe the console. Check that the machine selects the expected profile and installation source. During initial development, inspect the proposed storage behavior before permitting unattended disk changes.

Keep the first run visible. It should establish whether the installer completes with the intended inputs, not merely whether it can start.

Check the result and reboot again

Use a written acceptance record:

Check	Expected result
OS release	Matches the selected image
Αποθηκευτικός χώρος	Uses the intended disk and partition layout
Network	Has the expected address, routes, and DNS
Access	Accepts the approved administrative access
Initialization	Required first-boot tasks have finished
Deployment state	No longer eligible for automatic installation
Second reboot	Starts the installed OS without reinstalling

Retain redacted console output and relevant logs. Record any manual corrections so they can become explicit configuration or checks before the next run.

Secure the Boot Path and Prevent Accidental Reinstalls

An installation service can change a machine before its normal OS protections are active. Control who can reach that service and what it is allowed to install.

Protect network access and files

Use a controlled installation network with a documented DHCP owner. Avoid introducing a competing DHCP server onto a shared production network.

Restrict access to answer files and boot configuration. These files can expose account information, internal addresses, or instructions that change storage.

Use supported HTTPS transfers with a working certificate trust chain where appropriate. The iPXE cryptography documentation explains its trust and cryptographic capabilities. Do not assume that the preboot client trusts the same certificates as an administrator’s browser.

Check the origin of installation artifacts as well as their integrity. A checksum from the same untrusted location as a modified image does not establish that the image is authentic.

Make installation permission temporary

Treat installation as a job with a beginning and an end. An approved machine receives a specific profile. A completed machine loses its eligibility for another automatic install.

Use both one-time boot controls, where supported, and server-side job state. Boot order alone is a weak safeguard if an operator later selects network boot again.

Unknown machines should receive a non-destructive response. Failed jobs should retain logs and wait for a controlled retry rather than repeatedly erase and reinstall.

Troubleshoot PXE Boot by the Last Successful Stage

The most useful first question is: What was the last stage that worked? A DHCP failure and an installer storage failure need different evidence.

Symptom	Stage to inspect	First checks
No network lease	Network settings	Link, VLAN, DHCP scope, relay path
Address received, no boot program	Boot selection	Boot filename, service response, architecture policy
TFTP timeout	Initial file transfer	File path, permissions, negotiated UDP traffic
iPXE repeatedly reloads	Chainloading	iPXE client handling and second-stage script
Signature or unsupported-image error	Firmware handoff	Architecture, firmware mode, trusted signing chain
Kernel starts, source download fails	Installer networking	NIC driver, route, DNS, URL, certificate trust
Installer asks for input	Answer-file handling	File delivery, format, boot arguments, interactive settings
Installed system does not boot	Local boot	Disk layout, bootloader, firmware entry
Installation runs again	Deployment state	Install eligibility, completion record, boot order

Match the logs to the failure

DHCP logs help explain address and boot-information responses. TFTP or web-server logs show which files were requested. Installer logs explain configuration and storage errors. The remote console shows the transition between these stages.

A successful download from your laptop does not prove that firmware or the installer can fetch the same file. The client may use a different network, lack a route, or have a different certificate trust store.

Keep retries controlled. Restarting every service at once can remove evidence and leave the original fault unexplained.

Plan Capacity for Multiple Server Installs

Total installation time includes firmware startup, file transfer, disk operations, package installation, and post-install tasks. Network speed alone cannot predict the finish time.

For example, if ten targets each fetch 4 GB through one shared 1 Gbps link, the aggregate payload is 40 GB. At the full nominal rate, transfer alone takes about 320 seconds, before protocol overhead or other work. This is an illustrative lower bound, not a deployment benchmark.

Measure one installation before increasing the batch size. Then check shared uplinks, file-server storage, repository access, DHCP capacity, and job tracking under a small batch.

Local mirrors or caches may reduce repeated downloads. They also need version control so a new package or image does not silently change the next build.

For larger fleets, a provisioning platform can manage machine state, boot actions, and deployment jobs. Keep platform selection tied to the wider bare metal provisioning process, rather than treating a PXE service as the whole system.

PXE or IPMI Virtual Media: Which Fits the Job?

PXE supplies a network boot path. IPMI is a remote-management interface implemented by a server’s management controller; virtual media depends on the controller’s features and access rights. These capabilities can work in the same deployment.

Method	Suitable task	Dependency to check
PXE or iPXE	Repeated installs across approved machines	Boot services and installation-network access
Remote virtual media	One-off installation or recovery	Management-controller support, permissions, and any license requirement
Local USB media	Local installation or recovery	Physical access and suitable installation media

A remote-management system may select a one-time PXE boot, while a network service supplies the installer. It may also mount an ISO when network boot is unavailable.

Check these options before renting hardware. Access to the server OS does not imply permission to run DHCP or attach a private installation network. Our IPMI management guide explains the remote-access side.

PXE Boot Questions

Can a server use PXE without an installed OS?

Yes. Compatible firmware can start network boot before a local OS exists. The server still needs working hardware, a supported network interface, and access to the boot services. A missing local OS is different from missing network boot support.

Does PXE boot need internet access?

No. An installation can use local boot services, media, and repositories. Internet access becomes necessary only when the chosen workflow depends on external files or services. Check package sources, configuration URLs, and certificate-related dependencies before planning an offline build.

Does PXE boot erase the hard drive?

PXE itself does not erase storage. The software started through PXE may do so. An unattended installer can repartition disks according to its configuration. Check the selected profile and target disks before allowing installation to proceed.

Can PXE work across VLANs?

Yes, with a suitable design. The client needs access to network configuration and boot information across the routed boundary. It must also reach the file services used by later stages. The required relays and access rules depend on the deployment platform.

Does iPXE work with Secure Boot?

It can, using a supported signed boot path and compatible later components. Check the iPXE release, CPU architecture, firmware trust settings, and OS requirements. An EFI filename alone does not prove that the complete boot chain will be accepted.

Can PXE install Linux and Windows?

PXE can start suitable boot environments for either. Each OS still needs its own supported installation files, drivers, and automation workflow. A shared boot menu does not make one answer file suitable for every operating system.

Check These Items Before Your First Install

Before enabling unattended installation, confirm that:

• The physical target is identified and approved.
• The firmware mode and boot program match.
• DHCP ownership and relay behavior are clear.
• Installation files come from trusted sources.
• The installer can change only the intended storage.
• The answer file matches the selected OS release.
• Console access and logs are available.
• Completion removes installation eligibility and permits normal local boot.

Planning network-based OS installs? Share your server count, OS, region, storage layout, and recovery needs with Atal Networks. Review our bare metal server configurations and ask which boot methods and network access options are available for your deployment.