Community Hub0 Subscribers
Community hub
Network booting
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (June 2014) |
Network booting, shortened netboot, is the process of booting a computer from a network rather than a local drive. This method of booting can be used by routers, diskless workstations and centrally managed computers (thin clients) such as public computers at libraries and schools.
Network booting can be used to centralize management of disk storage, which supporters claim can result in reduced capital and maintenance costs. It can also be used in cluster computing, in which nodes may not have local disks.
In the late 1980s/early 1990s, network boot was used to save the expense of a disk drive, because a decently sized harddisk would still cost thousands of dollars, often equaling the price of the CPU.[citation needed]
Hardware support
[edit]Contemporary desktop personal computers generally provide an option to boot from the network in their BIOS/UEFI via the Preboot Execution Environment (PXE). Post-1998 PowerPC (G3 – G5) Mac systems can also boot from their New World ROM firmware to a network disk via NetBoot.[1] Old personal computers without network boot firmware support can utilize a floppy disk or flash drive containing software to boot from the network.
Process
[edit]The initial software to be run is loaded from a server on the network; for IP networks this is usually done using the Trivial File Transfer Protocol (TFTP). The server from which to load the initial software is usually found by broadcasting a Bootstrap Protocol or Dynamic Host Configuration Protocol (DHCP) request.[2] Typically, this initial software is not a full image of the operating system to be loaded, but a small network boot manager program such as PXELINUX which can deploy a boot option menu and then load the full image by invoking the corresponding second-stage bootloader.
Installations
[edit]Netbooting is also used for unattended operating system installations. In this case, a network-booted helper operating system is used as a platform to execute the script-driven, unattended installation of the intended operating system on the target machine. Implementations of this for Mac OS X and Windows exist as NetInstall and Windows Deployment Services, respectively.
Legacy
[edit]Before IP became the primary Layer 3 protocol, Novell's NetWare Core Protocol (NCP) and IBM's Remote Initial Program Load (RIPL) were widely used for network booting. Their client implementations also fit into smaller ROM than PXE. Technically network booting can be implemented over any of file transfer or resource sharing protocols, for example, NFS is preferred by BSD variants.
See also
[edit]- Wake-on-LAN (WoL)
References
[edit]- ^ NetBoot 2.0: Boot Server Discovery Protocol (BSDP). Apple Inc.
- ^ Preboot execution environment (PXE) specification. Intel Corporation. 1999.
External links
[edit]- PXE specification – The Preboot Execution Environment specification v2.1 published by Intel & SystemSoft
- Remote Boot Protocol Draft – draft of the PXE Client/Server Protocol included in the PXE specification
- NetBoot – NetBoot 2.0: Boot Server Discovery Protocol (BSDP)
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Booting firmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||
Network booting
View on Grokipediafrom Grokipedia
Concepts and Basics
Definition and Overview
Network booting, also known as netbooting or PXE booting, is a process that enables a client device to load its operating system or boot image from a remote server over a network interface, such as Ethernet, without relying on local storage devices like hard disks, SSDs, USB drives, or other mass storage devices.[1] This method is particularly useful for diskless workstations, thin clients, and automated deployment scenarios where local boot media is unavailable or impractical.[4] The technique assumes the client has no pre-installed operating system and depends on firmware, such as BIOS or UEFI, to initiate the network interface and begin the boot sequence.[6] Key components in network booting include the client device, which broadcasts requests for boot information; the server, which provides the necessary boot files and configuration; and the network infrastructure, encompassing switches for connectivity and protocols like DHCP for dynamic IP address assignment.[1][4] Common types of network booting encompass the Preboot Execution Environment (PXE), a standard for x86 architecture that extends DHCP and TFTP for booting; legacy BOOTP combined with TFTP, which allows diskless clients to discover IP addresses, server details, and bootfile names via UDP/IP broadcasts; and iPXE, an open-source enhancement to PXE that adds support for protocols like HTTP, iSCSI, and scripting capabilities for more flexible boot menus.[6][7][8] In a basic workflow, the client firmware initializes the network interface and sends a broadcast request, typically a DHCPDISCOVER packet, to obtain an IP address and boot server information; the server responds with details pointing to the boot file location, after which the client downloads the image—often via TFTP—and executes it to load the operating system.[1][4] This process requires compatible hardware, such as a PXE-enabled network interface card, and server-side services like DHCP and TFTP to function effectively.[9]Benefits and Limitations
Network booting offers significant advantages in environments requiring efficient management of multiple devices. Centralized image management allows administrators to maintain a single repository for operating system images, reducing dependency on local hardware storage and enabling consistent configurations across devices. This facilitates rapid deployment of operating systems to numerous machines simultaneously, minimizing manual intervention and errors in large-scale setups. For instance, in data centers, network booting supports stateless computing by sharing boot images among nodes, optimizing storage usage—for example, a root filesystem image of around 100 MB can serve multiple clusters without duplication.[10] In educational laboratories, network booting enables diskless workstations, where hundreds of PCs can boot uniformly from a central server, ensuring identical software environments and simplifying updates without local storage needs. This approach cuts costs by repurposing older hardware as thin clients and enhances security by keeping data in the cloud or server. Enterprise IT benefits from its scalability, supporting virtual desktop infrastructure (VDI) for consistent desktops across sites, remote troubleshooting, and simultaneous updates for hundreds of nodes, which improves efficiency in distributed operations.[11] Despite these benefits, network booting has notable limitations stemming from its reliance on infrastructure. It requires a reliable, high-speed network; latency or instability can lead to boot failures. Dependency on servers like DHCP and TFTP creates single points of failure—if these services are unavailable, booting halts entirely. Security risks are prominent due to unencrypted protocols like TFTP over UDP, making it vulnerable to man-in-the-middle attacks or rogue boot servers intercepting transfers.[12] Network booting is unsuitable for offline or low-bandwidth scenarios, as it cannot function without constant connectivity. Performance-wise, boot times typically range from 30 to 120 seconds depending on image size (e.g., 50-500 MB) and network conditions, with TFTP downloads being a primary bottleneck—optimized settings can reduce this phase from about 24 seconds to under 10 seconds for a 201 MB file. Compared to local SSD booting, network booting is generally 4.5 to 10 times slower due to transfer overhead, trading speed for the flexibility of centralized maintenance.[3][5]Supporting Technologies
Network Protocols
Network booting relies on standardized protocols to enable clients to obtain network configuration and transfer boot files without local storage. The Dynamic Host Configuration Protocol (DHCP) serves as the primary mechanism for dynamic IP address assignment and boot server discovery. Operating over UDP, DHCP uses port 67 on the server side and port 68 on the client side to exchange messages, allowing clients to request and receive essential network parameters.[13] Complementing DHCP, the Trivial File Transfer Protocol (TFTP) facilitates the simple, low-overhead transfer of boot images and executables from the server to the client. TFTP runs exclusively over UDP on port 69, eschewing authentication and directory navigation for speed and minimal resource use, which suits pre-boot environments.[14] The Preboot Execution Environment (PXE), specified by Intel, builds on these protocols to create a standardized framework for network booting. Version 2.1 of the PXE specification, released in 1999, extends DHCP by defining vendor-specific options, including option 66 for the boot server host name and option 67 for the boot file name, to guide clients to the correct resources. PXE also incorporates support for multicast transmissions, enabling efficient discovery of boot servers and concurrent file distribution to multiple clients, thereby reducing network congestion. Later adaptations integrate PXE capabilities directly into UEFI firmware, enhancing compatibility with modern systems.[2][15] Earlier protocols laid the groundwork for these developments. The Bootstrap Protocol (BOOTP), outlined in RFC 951 and published in 1985, preceded DHCP and supported static IP assignments for diskless clients in rudimentary network environments.[16] Contemporary extensions address evolving needs for security and flexibility. The iPXE open-source firmware augments PXE by supporting HTTP and HTTPS for file transfers, allowing encrypted communication over the web. Meanwhile, the Internet Small Computer Systems Interface (iSCSI) protocol provides block-level access to remote storage devices, enabling clients to boot from networked disks as if they were local.[8][17] These protocols interact in a coordinated sequence to initiate booting. A client broadcasts a DHCPDISCOVER packet to solicit responses, receiving a DHCPOFFER from the server that includes PXE options for IP assignment and boot details. The client then issues a DHCPREQUEST to confirm the offer, followed by a TFTP read request for the Network Boot Program (NBP), which loads the initial executable into memory.[13][2] Security considerations extend protocol functionality to mitigate risks in shared networks. iPXE's HTTPS implementation encrypts boot image transfers and verifies server authenticity using trusted certificates. VLAN segmentation further isolates boot traffic, confining broadcasts and transfers to dedicated network segments to prevent interference or eavesdropping.[18]Boot Firmware
Boot firmware on client devices serves as the foundational layer that initiates network booting by providing the necessary low-level interfaces to network hardware before an operating system loads. In legacy BIOS systems, network booting relies on Option ROMs embedded in network interface cards (NICs), which hook into the boot process via interrupt handlers such as INT 1Ah to enable network access through the Universal Network Driver Interface (UNDI).[2] These ROMs allow the BIOS to discover and utilize PXE-capable NICs during the boot sequence, emulating boot devices without local storage.[2] In contrast, Unified Extensible Firmware Interface (UEFI) systems employ more modular boot services, including the EFI PXE Base Code Protocol, which builds on UNDI for network operations and integrates with UEFI's boot manager for secure and extensible loading.[19] UEFI firmware exposes network capabilities via protocols like the Simple Network Protocol (SNP) and Managed Network Protocol (MNP), facilitating PXE boot in both IPv4 and IPv6 environments without relying on legacy interrupts.[20] This shift from BIOS's interrupt-driven model to UEFI's driver-based approach enhances compatibility with modern hardware and supports features like secure boot during network initialization.[20] The network boot ROM, typically an Option ROM in both BIOS and UEFI environments, intercepts the boot process after power-on self-test (POST) and before control passes to the boot device. It loads the UNDI driver, which provides a standardized interface for the protocol stack, including DHCP discovery and TFTP file transfers essential for PXE.[19] In legacy BIOS, the ROM scans for PCI devices and installs UNDI entry points to handle network I/O, while in UEFI, it produces a device path and protocol handles for the boot services table.[2] This interception ensures the firmware can attempt network boot if local devices fail or are absent.[20] Configuration of boot firmware for network booting occurs primarily through BIOS or UEFI setup menus, where users enable the network option and adjust the boot order to prioritize it over local storage. For instance, setting the boot sequence to favor "Network" or "PXE Boot" allows the firmware to invoke the ROM during initialization.[21] UEFI systems additionally support chainloading, where one firmware module loads another, enabling flexible boot paths such as selecting between multiple network protocols or fallback options without restarting the setup process.[22] Enhancements to stock boot firmware often involve replacing the vendor-provided PXE ROM with advanced open-source alternatives like iPXE, which extends capabilities to include scripting for automated boot flows, such as menu-driven selection of operating systems or diagnostic tools.[8] iPXE, derived from the open-source gPXE project, supports HTTP, iSCSI, and custom scripts executed via a simple command language, allowing dynamic configuration beyond basic PXE.[23] These replacements are flashed onto the NIC or loaded as chainloaders, providing greater control in enterprise deployments.[8] For UEFI systems, NICs typically support UNDI version 3.x for compatibility with the Simple Network Interface, ensuring the firmware can interface with the hardware abstraction layer for packet transmission and reception. In x86 environments, this is standard for most Ethernet controllers, but for embedded systems on ARM or RISC-V architectures, equivalents like U-Boot provide network boot support through TFTP and DHCP commands, initializing the bootloader to fetch kernels or ramdisks over the network. U-Boot's cross-platform design accommodates these architectures by supporting device trees for hardware description and environment variables for boot scripting. Legacy BIOS PXE requires UNDI 1.0 or 2.0.[24][19] A key limitation of boot firmware is the total space for legacy option ROMs limited to 128 KB in the memory range C0000-DFFFF, with individual ROMs typically 16-32 KB to fit within this shared allocation.[25] This often necessitates minimal implementations, pushing advanced features to chainloaded modules like iPXE to avoid exceeding the available space.[2] In UEFI, while the overall firmware image can be larger, individual driver modules face similar embedded ROM limits on add-in cards.[20]Hardware and Software Requirements
Client-Side Components
Client-side components for network booting encompass the hardware and firmware on the booting device that enable it to connect to the network, request boot files, and load an operating system image remotely. These components are designed to operate with minimal resources, as the primary goal is to initiate the boot sequence without dependence on local mass storage. Key elements include a compatible network interface, a compatible CPU, and firmware support for boot protocols. Essential hardware begins with a Network Interface Card (NIC) featuring Preboot eXecution Environment (PXE) or Universal Network Driver Interface (UNDI) support to handle the initial network communication. For instance, the Intel Ethernet Connection I219 series provides PXE boot functionality in UEFI environments, allowing devices to perform remote booting.[26] Similarly, Broadcom BCM57xx Gigabit Ethernet controllers, such as those in the NetXtreme family, include built-in PXE support for legacy and UEFI modes, enabling network-initiated boots via TFTP.[27] The client also requires sufficient RAM—around 1 GB for loading basic boot images into memory during the process.[28] Local storage is not required, as the entire boot image is fetched over the network; however, a small disk or flash drive may be present for hybrid configurations that fallback to local booting if network access fails. Software prerequisites are confined to the device's built-in firmware, such as BIOS or UEFI, which must include a network boot option to prioritize the NIC during startup. This firmware loads a minimal network stack and PXE client without needing a pre-installed operating system.[4] Network booting demands adherence to established compatibility standards, primarily IEEE 802.3 Ethernet for physical layer connectivity at minimum speeds of 10/100/1000 Mbps to ensure reliable data transfer during boot file downloads.[29] IPv4 support is ubiquitous in traditional PXE implementations, while IPv6 integration has become more prevalent with UEFI 2.5, which introduces HTTP Boot capabilities over IPv6 networks for enhanced remote provisioning.[30][31] Representative examples illustrate the versatility of client-side components across device types. Standard PCs and enterprise servers, such as Dell PowerEdge models (e.g., R740), incorporate integrated PXE support in their onboard NICs, facilitating seamless network booting in data center environments.[32] Embedded systems like the Raspberry Pi 4 and 5 leverage U-Boot or EEPROM-based firmware for network booting over Ethernet, using TFTP to fetch initial boot files without an SD card; note that this uses non-standard PXE methods adapted for ARM architecture.[33] Troubleshooting client-side issues often involves addressing NIC-related failures, such as incomplete PXE handshakes, which can be resolved by updating the NIC firmware with vendor tools like Broadcom's Diagnostic Utility or Intel's NVM Update Utility to ensure compatibility with boot servers.[29][34]Server-Side Components
Server-side components form the backbone of network booting infrastructure, primarily consisting of DHCP and TFTP servers that provide essential configuration and file delivery services to clients. The DHCP server assigns IP addresses to clients and supplies boot server details via options such as 66 (next-server) and 67 (boot file name), enabling the client to locate and request the initial boot loader. Examples include the open-source ISC DHCP server, which supports PXE extensions through configuration in/etc/dhcp/dhcpd.conf for subnet declarations and PXE-specific options, and Microsoft's DHCP server, integrated with Windows Server for seamless PXE support in enterprise environments.[35][36] The TFTP server then delivers the boot files, such as the PXE loader, over UDP port 69; common implementations include tftpd-hpa on Linux distributions, which handles file transfers for initial boot stages with minimal overhead.[37]
For hosting larger boot images beyond the TFTP limit, HTTP or NFS servers are employed to serve kernel images, initramfs, and full installation trees. HTTP servers, like Apache or nginx, provide scalable access to repositories (e.g., via inst.repo=http://server/path), while NFS allows mounting of root filesystems for diskless booting, configured by exporting directories such as /var/www/html/images. PXE-specific daemons, such as pxelinux from the Syslinux project, manage boot menus and configurations stored in the TFTP root, allowing dynamic selection of images based on client architecture.[37][38]
Integrated software stacks simplify deployment; open-source options like the FOG Project offer a complete PXE imaging solution with built-in DHCP, TFTP, and HTTP services for cloning and OS management across networks. Serva provides a lightweight, free Windows-based alternative for PXE serving without full server overhead. Commercial solutions include Microsoft Windows Deployment Services (WDS), which bundles PXE with multicast deployment for Windows environments, and Altiris Deployment Solution (now part of Symantec), enabling automated imaging with PXE boot integration for enterprise-scale operations.[39][40][41][42]
To handle scalability in large environments, load balancers distribute TFTP requests across multiple instances, mitigating single-server bottlenecks during mass deployments and preventing timeouts in high-concurrency scenarios. ProxyDHCP servers complement existing DHCP infrastructure by providing only PXE boot options (e.g., via UDP port 4011) without interfering with IP assignment, ideal for networks where modifying the primary DHCP is not feasible.[43][44]
Security is enhanced through IP and MAC address restrictions on TFTP/DHCP services to limit access to authorized clients, VLAN segmentation to isolate boot traffic from production networks, and encrypted protocols like FTPS for secure transfer of sensitive boot images where TFTP's limitations apply.[45][46][47]
Basic setup involves configuring DHCP options 66 and 67 to point to the TFTP server IP and boot file (e.g., pxelinux.0), then placing boot files like pxelinux.0, vmlinuz, and initrd.img in the TFTP root directory, typically /var/lib/tftpboot or /tftpboot, followed by enabling and starting the services.[37][48]