The journey from a cold, powered-off diskless workstation to a fully operational system with a login prompt is a remarkable orchestration of protocols, each dependent on the successful completion of those before it. This process, refined over decades of networked computing, represents one of the most elegant applications of the layered protocol approach.

A diskless workstation has no local storage—no hard drive, no SSD, no flash memory for the operating system. Everything it needs must come from the network. Yet within 15-60 seconds of power-on, the screen displays a login prompt, the keyboard responds, and the user can begin working. How does this transformation occur?

This page traces the complete bootstrap pathway, from the initial electrical pulse through the network cable to the execution of the first user-space process.

The bootstrap process begins in hardware. Every network-bootable system contains a Boot ROM (also called a Boot PROM, Option ROM, or PXE ROM)—a small piece of persistent memory containing just enough code to initiate the network boot process.

Physical Implementation:

Boot ROM Contents:

1. POST diagnostics: Basic hardware checks
2. NIC initialization: Configure the network interface
3. Protocol stacks: Minimal implementations of required protocols
4. User interface: Status display, configuration menu
5. Boot logic: Decision making for boot source selection

Protocol Stack in Boot ROM:

A typical Boot ROM includes minimal implementations of:

+-------------------+
|   Boot Logic      |  <- Orchestrates the boot process
+-------------------+
|   TFTP Client     |  <- Downloads boot image
+-------------------+
|   BOOTP/DHCP      |  <- Obtains IP configuration
+-------------------+
|   UDP             |  <- Transport for BOOTP/TFTP
+-------------------+
|   IP              |  <- Network layer
+-------------------+
|   ARP             |  <- Address resolution
+-------------------+
|   Ethernet Driver |  <- NIC-specific driver
+-------------------+
|   Hardware Init   |  <- NIC initialization
+-------------------+

Constraints on Boot ROM Code:

The first network task is obtaining an IP address and boot configuration. This phase uses BOOTP (or DHCP in modern environments) to transform the workstation from 'knows nothing' to 'knows enough to download its operating system.'

Pre-BOOTP State:

• Has: MAC address, boot ROM code
• Needs: IP address, subnet mask, gateway, boot server, boot filename

BOOTP Request/Reply Exchange:

Post-BOOTP State:

After a successful BOOTP exchange, the client now knows:

Address Configuration:

The Boot ROM configures the minimal IP stack:

1. Set IP address to 192.168.1.100
2. Set subnet mask to 255.255.255.0
3. Add default route via 192.168.1.1
4. Populate ARP table with known addresses

With this configuration, the workstation can now communicate with the TFTP server to download its boot image.

With address configuration complete, the next phase is downloading the boot image using TFTP (Trivial File Transfer Protocol). TFTP was designed specifically for this use case—it's simple enough to implement in a Boot ROM while capable of transferring multi-megabyte files.

Why TFTP, Not FTP or HTTP?

TFTP Operation:

TFTP uses a simple read request / data / acknowledgment pattern:

1. Client sends Read Request (RRQ) for boot filename
2. Server sends Data block 1 (512 bytes)
3. Client sends Acknowledgment for block 1
4. Server sends Data block 2
5. Client sends Acknowledgment for block 2
6. ... repeat until final block (< 512 bytes)

TFTP Packet Types:

Transfer Time Calculation:

For a 4 MB boot image on a 100 Mbps network:

File size: 4 MB = 4,194,304 bytes
Block size: 512 bytes
Number of blocks: 4,194,304 / 512 = 8,192 blocks

Per-block transfer (100 Mbps):
  - Data packet: 512 bytes = ~41 microseconds
  - ACK packet: ~20 bytes = ~1.6 microseconds
  - Round-trip latency: ~1 millisecond (typical LAN)
  - Per-block time: ~1-2 milliseconds

Total transfer time: 8,192 × 2 ms ≈ 16 seconds

With modern optimizations (TFTP options):
  - Block size: 1428 bytes (max without fragmentation)
  - Number of blocks: ~2,937
  - Transfer time: ~6 seconds

TFTP Options (RFC 2347, 2348, 2349):

Boot Image Types:

Memory Loading:

As blocks arrive, the Boot ROM loads them into specific memory locations:

Memory Layout (x86 example):
+------------------+ 0x00000000
| Interrupt Table  |
+------------------+ 0x00000400
| BIOS Data Area   |
+------------------+ 0x00000500
| Free (boot image)| <- TFTP data loaded here
+------------------+ 0x0007FFFF
| ...              |
+------------------+ 0x00100000
| Extended Memory  | <- Large images loaded here
+------------------+

Once the boot image is loaded into memory, the Boot ROM transfers control to it. This marks a transition from the simple, constrained Boot ROM environment to a more capable boot loader that can download additional files and present configuration options.

The Boot Handoff:

Boot ROM execution flow:
1. Download boot image via TFTP
2. Verify image integrity (checksum if supported)
3. Set up execution environment
4. Jump to boot image entry point
5. Boot ROM code no longer executes

Information Passed to Boot Loader:

The Boot ROM typically communicates configuration to the boot loader via:

Common Network Boot Loaders:

PXELINUX (Syslinux project):

• Standard for x86 BIOS systems
• Reads configuration from pxelinux.cfg/ directory
• Supports menus, kernel parameters, automated boot
• Downloads kernel and initrd via TFTP

GRUB2 (for UEFI):

• Modern boot loader with PXE support
• Reads grub.cfg configuration
• Supports multiple file systems, protocols
• Can use HTTP, TFTP, or other protocols

iPXE (Enhanced PXE):

• Replaces vendor PXE with extended capabilities
• Scripts, HTTP/HTTPS support, iSCSI boot
• Can be loaded as a boot image itself

Boot Loader Tasks:

1. Parse configuration: Read menu options and kernel parameters
2. Display menu (optional): Allow user selection
3. Download kernel: Fetch vmlinuz or equivalent
4. Download initramfs: Fetch initial ramdisk
5. Set up kernel parameters: Command line arguments
6. Load and execute kernel: Pass control to the OS

When the boot loader transfers control to the kernel, a new phase begins. The kernel must initialize the system, configure networking, and mount its root filesystem—all without any local storage.

Kernel Boot Parameters for Network Boot:

vmlinuz initrd=initrd.img ip=dhcp root=/dev/nfs 
    nfsroot=192.168.1.1:/export/client1 rw

Parameter Reference:

Kernel Initialization Sequence:

1. Decompress kernel (if compressed)
2. Initialize CPU and memory management
3. Initialize core subsystems (interrupts, timers, etc.)
4. Initialize device drivers (from initramfs)
5. Configure network interface (from kernel parameters or DHCP)
6. Mount root filesystem (NFS for diskless)
7. Execute init (systemd, sysvinit, etc.)

The Initramfs Role:

For network boot, the initramfs (initial RAM filesystem) is critical. It contains:

• Network drivers for the NIC
• NFS client code
• DHCP client
• Scripts to configure networking and mount NFS root

Initramfs contents (simplified):
/
├── bin/
│   ├── busybox
│   └── sh -> busybox
├── etc/
├── init (initialization script)
├── lib/
│   └── modules/ (network driver .ko files)
├── proc/
├── sys/
└── sbin/
    └── mount.nfs

NFS Root Mount:

The kernel (via initramfs) mounts the NFS-exported root filesystem:

mount -t nfs -o vers=4,rw 192.168.1.1:/export/client1 /sysroot

NFS Export Configuration (Server Side):

# /etc/exports on NFS server
/export/client1    192.168.1.100(rw,sync,no_root_squash,no_subtree_check)
/export/client2    192.168.1.101(rw,sync,no_root_squash,no_subtree_check)
/export/shared     192.168.1.0/24(ro,sync,no_subtree_check)

Critical Export Options:

Let's trace through a complete network boot with realistic timings. This timeline assumes a modern 1 Gbps network with optimized configurations.

Factors Affecting Boot Time:

Common Bottlenecks:

1. Spanning Tree: Can add 30-50 seconds if PortFast not enabled
2. Large initramfs: Every MB adds ~1 second on 100 Mbps
3. Slow NFS: Remote NFS across WAN dramatically slows boot
4. Complex init: Many startup services extend boot time

Network boot involves multiple components that must all work correctly. Systematic troubleshooting identifies the failing phase.

Failure Point Identification:

Diagnostic Tools:

1. Packet Capture (Wireshark/tcpdump):

# Capture all BOOTP/DHCP and TFTP traffic
tcpdump -i eth0 -w boot-capture.pcap 
    'port 67 or port 68 or port 69'

2. TFTP Testing:

# Manual TFTP test from another machine
tftp 192.168.1.1
> get /tftpboot/pxelinux.0
> quit

3. NFS Testing:

# Check NFS exports
showmount -e 192.168.1.1

# Test mount
mount -t nfs 192.168.1.1:/export/root /mnt/test

4. DHCP Server Logs:

# ISC DHCP server logs
journalctl -u isc-dhcp-server -f

# Check for lease assignments
cat /var/lib/dhcp/dhcpd.leases

We have traced the complete journey from power-on to operating system. Let's consolidate the key phases and concepts:

What's Next:

In the final page of this module, we will explore the historical context and evolution of bootstrap protocols—from RARP through BOOTP to modern DHCP. Understanding this evolution illuminates why protocols work the way they do and provides insight into the design decisions that shaped modern network auto-configuration.