{"id":25017,"date":"2026-10-19T10:29:05","date_gmt":"2026-10-19T10:29:05","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=25017"},"modified":"2026-10-19T10:29:57","modified_gmt":"2026-10-19T10:29:57","slug":"pxe-boot-bare-metal-os-installation","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/ar\/pxe-boot-bare-metal-os-installation\/","title":{"rendered":"PXE Boot Explained: Automating Bare Metal OS Installs"},"content":{"rendered":"

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

What Is PXE Boot, and Where Does Installation Begin?<\/span><\/h2>\n

PXE stands for <\/span>Preboot Execution Environment<\/b>, commonly pronounced \u201cpixie.\u201d It provides a standard way for compatible firmware to start software obtained from a network.<\/span><\/p>\n

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.<\/span><\/p>\n

Network boot, OS installation, and first-boot configuration<\/span><\/h3>\n

These stages have different jobs:<\/span><\/p>\n\n\n\n\n\n\n\n\n
Stage<\/b><\/th>\nMain task<\/b><\/th>\nResult<\/b><\/th>\n<\/tr>\n<\/thead>\n
Network boot<\/span><\/td>\nObtain and run boot software<\/span><\/td>\nAn installer or live environment starts<\/span><\/td>\n<\/tr>\n
OS installation<\/span><\/td>\nApply the storage layout and install system files<\/span><\/td>\nAn OS exists on the intended disk<\/span><\/td>\n<\/tr>\n
First-boot configuration<\/span><\/td>\nApply supported initialization settings<\/span><\/td>\nThe installed system has its required initial configuration<\/span><\/td>\n<\/tr>\n
Handoff checks<\/span><\/td>\nCheck access, networking, and system state<\/span><\/td>\nThe server is ready for its agreed next task<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/span><\/p>\n

When PXE fits a bare metal workload<\/span><\/h3>\n

PXE is useful when we repeatedly install servers with known configurations. Examples include cluster nodes, development labs, replacement machines, and approved OS rebuilds.<\/span><\/p>\n

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.<\/span><\/p>\n

For one remote server, virtual media through a management controller may require less setup. For the wider deployment process, see our <\/span>bare metal provisioning guide<\/span><\/a>.<\/span><\/p>\n

What Does a PXE Boot Environment Need?<\/span><\/h2>\n

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.<\/span><\/p>\n

Server firmware, network access, and boot files<\/span><\/h3>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

The main components are:<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Component<\/b><\/th>\nPurpose<\/b><\/th>\n<\/tr>\n<\/thead>\n
DHCP service<\/span><\/td>\nSupplies network settings to the client<\/span><\/td>\n<\/tr>\n
Boot information service<\/span><\/td>\nTells the client which boot program to request<\/span><\/td>\n<\/tr>\n
Network boot program<\/span><\/td>\nStarts the next boot stage<\/span><\/td>\n<\/tr>\n
Installer files<\/span><\/td>\nProvide the environment that installs the OS<\/span><\/td>\n<\/tr>\n
Installation source<\/span><\/td>\nSupplies the OS content or packages<\/span><\/td>\n<\/tr>\n
Answer file<\/span><\/td>\nDefines supported unattended installation choices<\/span><\/td>\n<\/tr>\n
Deployment record<\/span><\/td>\nTracks the intended machine, profile, and outcome<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The deployment record is an operating control. It is not a requirement built into the PXE protocol.<\/span><\/p>\n

TFTP, HTTP, and HTTPS<\/span><\/h3>\n

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.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n
Service<\/b><\/th>\nTypical traffic<\/b><\/th>\nDetail to check<\/b><\/th>\n<\/tr>\n<\/thead>\n
DHCP over IPv4<\/span><\/td>\nUDP 67 and 68<\/span><\/td>\nClient access and any relay path<\/span><\/td>\n<\/tr>\n
TFTP<\/span><\/td>\nInitial request to UDP 69<\/span><\/td>\nTransfer uses negotiated UDP ports afterward<\/span><\/td>\n<\/tr>\n
HTTP<\/span><\/td>\nTCP 80<\/span><\/td>\nFile paths and reachability<\/span><\/td>\n<\/tr>\n
HTTPS<\/span><\/td>\nTCP 443<\/span><\/td>\nCertificate trust in the client that fetches the files<\/span><\/td>\n<\/tr>\n
Deployment-specific PXE service<\/span><\/td>\nMay use UDP 4011<\/span><\/td>\nRequired only for applicable implementations<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/span><\/p>\n

How Does PXE Boot Work, Step by Step?<\/span><\/h2>\n

The first stages establish network access and load a boot program. Installation begins only after the selected software takes control.<\/span><\/p>\n

1. The server starts network boot<\/span><\/h3>\n

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.<\/span><\/p>\n

At this point, check that the intended port has a link and reaches the installation network.<\/span><\/p>\n

2. The client receives network settings and boot information<\/span><\/h3>\n

The client requests network configuration. It also identifies information relevant to network boot, including its architecture.<\/span><\/p>\n

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.<\/span><\/p>\n

3. The client loads a compatible boot program<\/span><\/h3>\n

The boot service directs the machine to an appropriate file. The client downloads it and transfers control to it.<\/span><\/p>\n

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.<\/span><\/p>\n

4. The boot program starts the installation environment<\/span><\/h3>\n

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

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.<\/span><\/p>\n

5. The installer applies its instructions<\/span><\/h3>\n

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.<\/span><\/p>\n

This is the stage where storage can be changed. The selected disks must match the approved installation profile.<\/span><\/p>\n

6. The system returns to normal boot<\/span><\/h3>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

DHCP options, proxyDHCP, and relays<\/span><\/h3>\n

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 <\/span>next-server<\/span> also have meanings that should be checked against the selected server software.<\/span><\/p>\n

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. <\/span>Microsoft’s routed PXE documentation<\/span><\/a> explains its requirements.<\/span><\/p>\n

PXE vs iPXE vs UEFI HTTP Boot<\/span><\/h2>\n

These names describe related boot paths and software. They are not three complete OS deployment systems.<\/span><\/p>\n\n\n\n\n\n\n\n
Approach<\/b><\/th>\nHow it starts<\/b><\/th>\nUseful capability<\/b><\/th>\nMain check<\/b><\/th>\n<\/tr>\n<\/thead>\n
Traditional PXE path<\/span><\/td>\nFirmware obtains and runs a network boot program, commonly through TFTP<\/span><\/td>\nStarts an installer without local media<\/span><\/td>\nBoot-file and firmware compatibility<\/span><\/td>\n<\/tr>\n
iPXE<\/span><\/td>\nRuns as network boot firmware or a loaded boot program<\/span><\/td>\nAdds scripts, menus, and supported network transports<\/span><\/td>\nBuild features, drivers, and trust configuration<\/span><\/td>\n<\/tr>\n
UEFI HTTP Boot<\/span><\/td>\nCompatible UEFI firmware retrieves a boot application through HTTP Boot support<\/span><\/td>\nCan start a network boot chain without a TFTP first stage<\/span><\/td>\nFirmware support and application compatibility<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What iPXE adds<\/span><\/h3>\n

iPXE lets us express boot decisions in scripts. A script can select files, pass installer arguments, offer a menu, and handle a failed request.<\/span><\/p>\n

An existing PXE implementation can load iPXE as its next program. This is called <\/span>chainloading<\/b>.<\/span><\/p>\n

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 <\/span>iPXE project’s chainloading guide<\/span><\/a> describes ways to avoid this behavior, including different responses for iPXE clients and embedded scripts.<\/span><\/p>\n

UEFI and Secure Boot<\/span><\/h3>\n

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.<\/span><\/p>\n

The iPXE project provides a <\/span>documented Secure Boot path<\/span><\/a> 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.<\/span><\/p>\n

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.<\/span><\/p>\n

How Do You Automate the OS Installer?<\/span><\/h2>\n

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.<\/span><\/p>\n

Select the correct configuration format<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n
System or task<\/b><\/th>\nCommon method<\/b><\/th>\nBoundary<\/b><\/th>\n<\/tr>\n<\/thead>\n
Ubuntu Server with Subiquity<\/span><\/td>\nAutoinstall YAML<\/span><\/td>\nMatch the format and delivery method to the release<\/span><\/td>\n<\/tr>\n
RHEL and compatible Anaconda installers<\/span><\/td>\nKickstart<\/span><\/td>\nCheck distribution and release support<\/span><\/td>\n<\/tr>\n
Debian Installer<\/span><\/td>\nPreseed<\/span><\/td>\nDo not substitute it for current Ubuntu Server autoinstall<\/span><\/td>\n<\/tr>\n
Windows deployment<\/span><\/td>\nWindows PE plus the selected installation or image workflow<\/span><\/td>\nStarting WinPE alone does not install Windows<\/span><\/td>\n<\/tr>\n
Supported system initialization<\/span><\/td>\ncloud-init<\/span><\/td>\nIts role depends on the image and deployment workflow<\/span><\/td>\n<\/tr>\n
Ongoing configuration<\/span><\/td>\nAnsible or another configuration tool<\/span><\/td>\nRequires the access and software needed by that tool<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Canonical’s documentation<\/span><\/a> identifies autoinstall as Ubuntu’s automated installation format. <\/span>Red Hat’s installation documentation<\/span><\/a> covers Kickstart and its installer options.<\/span><\/p>\n

Define the server profile before changing storage<\/span><\/h3>\n

A useful profile answers six questions:<\/span><\/p>\n

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

    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.<\/span><\/p>\n

    A MAC address can help select a profile, but it is not strong proof of identity. Network access controls and deployment authorization still matter.<\/span><\/p>\n

    Example Workflow: An Unattended Ubuntu Server Installation<\/span><\/h2>\n

    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.<\/span><\/p>\n

    Record the environment<\/span><\/h3>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    The lab should have remote console access. This lets us inspect a failure before SSH or another OS-level service exists.<\/span><\/p>\n

    Prepare the files and boot path<\/span><\/h3>\n

    Host the required installation files at known paths. Check permissions and access from the installation network.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Run one controlled installation<\/span><\/h3>\n

    Confirm that the target contains no data that must be retained. If it does, complete and check the required backup before proceeding.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Keep the first run visible. It should establish whether the installer completes with the intended inputs, not merely whether it can start.<\/span><\/p>\n

    Check the result and reboot again<\/span><\/h3>\n

    Use a written acceptance record:<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Check<\/b><\/th>\nExpected result<\/b><\/th>\n<\/tr>\n<\/thead>\n
    OS release<\/span><\/td>\nMatches the selected image<\/span><\/td>\n<\/tr>\n
    \u0627\u0644\u062a\u062e\u0632\u064a\u0646<\/span><\/td>\nUses the intended disk and partition layout<\/span><\/td>\n<\/tr>\n
    Network<\/span><\/td>\nHas the expected address, routes, and DNS<\/span><\/td>\n<\/tr>\n
    Access<\/span><\/td>\nAccepts the approved administrative access<\/span><\/td>\n<\/tr>\n
    Initialization<\/span><\/td>\nRequired first-boot tasks have finished<\/span><\/td>\n<\/tr>\n
    Deployment state<\/span><\/td>\nNo longer eligible for automatic installation<\/span><\/td>\n<\/tr>\n
    Second reboot<\/span><\/td>\nStarts the installed OS without reinstalling<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Retain redacted console output and relevant logs. Record any manual corrections so they can become explicit configuration or checks before the next run.<\/span><\/p>\n

    Secure the Boot Path and Prevent Accidental Reinstalls<\/span><\/h2>\n

    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.<\/span><\/p>\n

    Protect network access and files<\/span><\/h3>\n

    Use a controlled installation network with a documented DHCP owner. Avoid introducing a competing DHCP server onto a shared production network.<\/span><\/p>\n

    Restrict access to answer files and boot configuration. These files can expose account information, internal addresses, or instructions that change storage.<\/span><\/p>\n

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

    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.<\/span><\/p>\n

    Make installation permission temporary<\/span><\/h3>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Troubleshoot PXE Boot by the Last Successful Stage<\/span><\/h2>\n

    The most useful first question is: <\/span>What was the last stage that worked?<\/b> A DHCP failure and an installer storage failure need different evidence.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Symptom<\/b><\/th>\nStage to inspect<\/b><\/th>\nFirst checks<\/b><\/th>\n<\/tr>\n<\/thead>\n
    No network lease<\/span><\/td>\nNetwork settings<\/span><\/td>\nLink, VLAN, DHCP scope, relay path<\/span><\/td>\n<\/tr>\n
    Address received, no boot program<\/span><\/td>\nBoot selection<\/span><\/td>\nBoot filename, service response, architecture policy<\/span><\/td>\n<\/tr>\n
    TFTP timeout<\/span><\/td>\nInitial file transfer<\/span><\/td>\nFile path, permissions, negotiated UDP traffic<\/span><\/td>\n<\/tr>\n
    iPXE repeatedly reloads<\/span><\/td>\nChainloading<\/span><\/td>\niPXE client handling and second-stage script<\/span><\/td>\n<\/tr>\n
    Signature or unsupported-image error<\/span><\/td>\nFirmware handoff<\/span><\/td>\nArchitecture, firmware mode, trusted signing chain<\/span><\/td>\n<\/tr>\n
    Kernel starts, source download fails<\/span><\/td>\nInstaller networking<\/span><\/td>\nNIC driver, route, DNS, URL, certificate trust<\/span><\/td>\n<\/tr>\n
    Installer asks for input<\/span><\/td>\nAnswer-file handling<\/span><\/td>\nFile delivery, format, boot arguments, interactive settings<\/span><\/td>\n<\/tr>\n
    Installed system does not boot<\/span><\/td>\nLocal boot<\/span><\/td>\nDisk layout, bootloader, firmware entry<\/span><\/td>\n<\/tr>\n
    Installation runs again<\/span><\/td>\nDeployment state<\/span><\/td>\nInstall eligibility, completion record, boot order<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Match the logs to the failure<\/span><\/h3>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Keep retries controlled. Restarting every service at once can remove evidence and leave the original fault unexplained.<\/span><\/p>\n

    Plan Capacity for Multiple Server Installs<\/span><\/h2>\n

    Total installation time includes firmware startup, file transfer, disk operations, package installation, and post-install tasks. Network speed alone cannot predict the finish time.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

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

    PXE or IPMI Virtual Media: Which Fits the Job?<\/span><\/h2>\n

    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.<\/span><\/p>\n\n\n\n\n\n\n\n
    Method<\/b><\/th>\nSuitable task<\/b><\/th>\nDependency to check<\/b><\/th>\n<\/tr>\n<\/thead>\n
    PXE or iPXE<\/span><\/td>\nRepeated installs across approved machines<\/span><\/td>\nBoot services and installation-network access<\/span><\/td>\n<\/tr>\n
    Remote virtual media<\/span><\/td>\nOne-off installation or recovery<\/span><\/td>\nManagement-controller support, permissions, and any license requirement<\/span><\/td>\n<\/tr>\n
    Local USB media<\/span><\/td>\nLocal installation or recovery<\/span><\/td>\nPhysical access and suitable installation media<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    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.<\/span><\/p>\n

    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 <\/span>IPMI management guide<\/span><\/a> explains the remote-access side.<\/span><\/p>\n

    PXE Boot Questions<\/span><\/h2>\n

    Can a server use PXE without an installed OS?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Does PXE boot need internet access?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Does PXE boot erase the hard drive?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Can PXE work across VLANs?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Does iPXE work with Secure Boot?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Can PXE install Linux and Windows?<\/span><\/h3>\n

    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.<\/span><\/p>\n

    Check These Items Before Your First Install<\/span><\/h2>\n

    Before enabling unattended installation, confirm that:<\/span><\/p>\n