PXE boot: why mass server installation breaks
Mass server installation over the network breaks not at the start, but at scale. PXE boot is a chain consisting of a DHCP response with a pointer to the bootloader, image delivery over TFTP, and a package source over HTTP.
One discrepancy inside it is enough — an outdated pointer, a wrong path, a diverged configuration file — and part of the fleet goes into error instead of installing, while the engineer walks the racks with a console.
After that, time is eaten by manual work: unattended answer templates are edited directly on a live deployment, and the next batch of hardware gets the previous batch's fingerprint — someone else's partitions, someone else's network address, someone else's access key.
Board and firmware revisions differ, BIOS and UEFI modes have to be selected manually, and manual image builds live on one engineer's workstation. Provisioning automation in such a scheme rests on people's memory, not on verifiable rules.
Deployed assets are tracked in a spreadsheet, and it diverges from reality after the very first disk replacement or reinstall.
Reinstallation takes hours: first you need to understand what is in the rack, which configuration is current for it, and which of the templates applies to it.
We break down how this is closed: a single source of templates and images, binding configuration to specific hardware through inventory, automatic selection of boot mode, and accounting for each installation as a separate event rather than a row in a spreadsheet.
What a unified network installation framework provides
A unified installation framework is when a server of any role gets its address, bootloader, and profile from one common description, rather than from a USB stick in the hands of the duty engineer.
The engineer adds an entry to the inventory, the machine on power-up contacts the addressing scope itself, pulls the image over the network, and applies its profile.
Server commissioning time drops from several hours of manual work to 10–15 minutes per machine, and without a person at the console.
Image templates provide the main effect: the base system and roles are described once. Changes to disk layout, network parameters, or package composition are made in one file — and the next installation already uses it.
A whole class of errors leaves the fleet: "snowflakes" with manual differences, because of which it later becomes impossible to reproduce a failure and replicate a working server.
Count the engineer's freed-up time per batch: installation runs in parallel, machines do not queue for a single storage medium.
On a fleet of several dozen servers, this is the difference between one shift and work stretched over days, where the specialist is busy with the network, hardware, and profiles rather than clicking "Next" at every rack.
Configuration repeatability is verified by the same framework: comparing the reference with actual state, unified rules for layout, accounts, and services.
A new server differs from a previously installed one only by what is defined in the template, not by who installed it and in what order.
Deployment profiles: comparison of boot modes
A deployment profile is a combination of boot mode, image, and answer template: disk layout, package set, kernel parameters, host joining the domain.
The more precisely the profile describes the node's role, the fewer manual edits after first boot — but the more templates have to be versioned and synchronized with images.
| Profile | When it fits | Limitations |
|---|---|---|
| Unified universal | Homogeneous fleet, roles hardly differ, replacements are rare | Extra services on all nodes; every deviation is manual tuning |
| By roles: compute, DBMS, storage, load balancers | Roles need their own disk layout and their own software set | Template matrix grows; versioning discipline is required |
| By segments and sites | Different networks, local mirrors, their own regulations | Template duplication if there is no inheritance from a base |
| Auto-selection by inventory | Large fleet, frequent commissioning and replacement of nodes | An up-to-date database is required: if it diverges, the node goes to the default profile |
Boot mode is selected separately from the profile. Classic network boot is sufficient for small and isolated segments; HTTP boot delivers large images faster and does not require local storage; batch installation in a single batch saves time per rack.
Installation scenarios differ by fleet size and speed requirements — so we start with one default profile, and connect the rest as the fleet grows.
Implementation stages: from network audit to handover
Implementation proceeds in queues, and the order of stages is fixed: an error in addressing or boot options breaks not only a new installation, but also machines already running in the same segment. Therefore we start not with server configuration, but with a description of the network and fleet.
-
Network and fleet audit. We collect the addressing scheme, virtual networks, DHCP relay agents, broadcast domain boundaries, server models, and boot modes. The output is a map of segments where network boot works and a list of exceptions.
-
Boot scheme design. We determine what we serve via DHCP — the bootloader address and image file, where the images themselves are stored, how hardware profiles are separated, and how boot is restricted by hardware address so the test cycle does not go to a production rack.
-
Boot server configuration. We bring up the menu, lay out images and unattended installation files, and bind disk layout, network, and the base package set to the profile. The first run is on one machine in an isolated segment.
-
Test installation on a spare node. We go through the full cycle: power-on, address acquisition, boot, layout, configuration, first start. We measure time to a ready node and the number of manual steps.
-
Failure scenario verification. Interruption mid-installation, repeated run, rollback to the previous image, behavior when the boot server is unavailable — everything must bring the node to a known state, not a half-configured one.
-
Handover. We provide documentation on the addressing scheme and profiles, configure access and roles, and show the duty shift how to add a new profile and how to disable boot for a specific node. After that, any menu edits go through the same test framework.
What remains with you: configurations and procedures
The package is handed over so that PXE boot in your network does not depend on one engineer: configurations are stored in a repository with edit history, diagrams are kept up to date rather than "on a napkin", and procedures describe routine operations — adding a new server model, decommissioning a node, rolling back a failed build. Below is what exactly remains with your team after handover.
- Boot server configurations — address allocation rules, boot menu description, binding images to hardware groups. With comments explaining why each block is needed and what will break if it is removed.
- Addressing and segment diagrams — which subnets the boot server serves, where network zone boundaries lie, how the route to image storage is arranged and what must be available before provisioning starts.
- Access rights policies — which engineers change the menu and images, who works only with logs, how automation service accounts are issued and revoked.
- Deployment documentation — step-by-step order for bringing the stand up from scratch: preparing images, enabling services, post-start verification.
- Change procedure — how a new image version enters circulation, who approves, how to return to the previous build in one step.
- Diagnostic procedure — checklist for typical failures: client did not get an address, did not find the boot file, hung on the menu. What to look at first and which logs to collect.
- Dependency map — which services must respond before mass power-on begins so the simultaneous start of hundreds of machines does not turn into blind debugging.
These artifacts live in your environment: edits are made according to the described procedure rather than from a specific person's memory, so maintenance can be handed to your team or another contractor without rebuilding the logic from scratch.
Case: heterogeneous fleet and one template set
Before: each hardware generation had its own recipe
The fleet was assembled over years, so racks housed servers of different generations and vendors — with different disk controllers and network cards. For each type they kept a separate folder with images and a separate set of answers at the boot stage.
Node commissioning took almost a day: the engineer manually selected the profile, monitored the layout, and delivered missing drivers after the system was already installed.
After: one template and profiles for the hardware
Boot was described once: the node identifies itself by MAC address, receives an address and an instruction on where to pull the image from, and then Ansible brings it to a working state by role.
Differences between generations are moved into variables — disk layout, driver set, and package list are set by the profile, not by a copy of the template. Before publishing to the common repository, the profile is run on a test node.
Metrics after the transition: server commissioning is 15–20 minutes instead of several hours, without the engineer's constant presence. The share of machines built from the common template set reached 90%, the rest is rare hardware, for which separate profiles are retained.
Failures on first installation almost disappeared: a profile failure is caught on the test stand, not on a production node.
Rollback also became predictable: the profile is versioned together with the template, and the previous working version is returned by one edit in the repository.
How does PXE boot differ from disk cloning?
Disk cloning copies an already installed system: an image is taken from the reference machine — and deployed to ten machines.
PXE boot works differently: the server boots over the network, receives a prepared image from storage, and deploys on bare metal without operator involvement. The difference shows not on the first machine, but on the hundredth.
Cloning breaks where the fleet stops being homogeneous. A different disk controller, a different network card — and the system does not come up or loses a device. Plus the copies inherit the reference machine's identifiers: host keys, names, network settings.
They have to be fixed manually on each node, and it is precisely this tuning that eats the entire gain from fast imaging.
Network boot is built around preparing images as a separate process. The reference is assembled automatically from a description rather than captured from a live machine, so it has no accumulated cruft or traces of past settings.
Configuration is bound to a specific node: role, layout, network parameters — the server receives exactly the set it is supposed to have, including unique identifiers generated on first start.
The differences between the approaches are visible at the point of edit. With cloning, a fix is made on every already running server, and the reference gradually diverges from reality.
With network boot, a fix is made once in the image description, and all new nodes come into operation already corrected.
Cloning remains reasonable for a one-time migration of several identical machines; regular server commissioning is handled predictably by network boot and without manual tuning.
Technical doubts: security, rollback, compatibility
Concerns around network boot are concrete: it operates before the operating system, and an error in the menu boots the wrong node. Below are answers to what engineers most often clarify before putting the scheme into operation.
Who can actually boot over the network?
DHCP boot options are given only to nodes from the agreed MAC list; others receive a regular address without options 66/67. Images are signed, and the checksum is verified before installation starts. Menu edits go through roles, and each edit remains in the log with the author.
How does this not affect running servers?
Provisioning is enabled by explicit confirmation and only for nodes marked free — running machines do not appear in the menu. We move the service segment to a separate VLAN, DHCP relay is configured for specific ports, and staging and production do not mix profiles.
What about rollback if an image turns out broken?
Each menu configuration is a separate versioned profile; switching the pointer returns the previous one within minutes. A failed image is unpublished, and the node completes using the old profile until investigation.
What about different models and firmware?
We run UEFI and Legacy BIOS via different boot chains; on a mixed fleet we install iPXE first. We test non-standard network adapters on a pilot batch and only then expand to the entire fleet.
Let's discuss your network installation task
To make the assessment based on facts rather than "roughly", a few inputs suffice. For PXE boot they are typical — they show how many configurations will have to be described and where divergences with the current infrastructure will begin.
- Machine inventory: model, roles, and MAC addresses of ports — templates are bound to specific hardware by them.
- Network diagram: subnets, who hands out addresses, whether a separate VLAN is needed for provisioning service traffic.
- Target systems and disk layout: file systems, software RAID arrays, encryption, data mount points.
- What to install after first boot: roles, packages, and settings by machine groups.
- Naming and addressing rules: how the machine gets its name and address, whether there is accounting of what was assigned.
- Access: console or remote management, distribution server, right to create records — a test stand is enough.
- Pilot window: two or three machines that can be reimaged without risk to running services.
We build the rollout plan incrementally: a pilot on two or three machines, where we test templates and verify repeatability of the run, then one rack entirely, then the fleet in parts.
We store descriptions in a repository and keep them declarative — via Ansible or a similar tool — so that a repeated run brings the machine to the same state.
We will return with a project assessment as a plan: stages, scope of work, what we do and what remains on the customer side, risks, and rollback points. Describe the task in free form — we will discuss the scope of fleet network installation and the order of work.