How LTSP Netboots Diskless Clients from a Single Template

Updated

LTSP (Linux Terminal Server Project) boots LAN clients over the network from one template installation — a VM image, a chroot on the LTSP server, or the server root itself (chrootless). The client downloads a kernel and initrd via iPXE, then mounts a compressed copy of that template as its root filesystem, with a per-client writable overlay on top. The practical result: maintaining tens or hundreds of diskless clients is as easy as maintaining a single PC. This applies to the redesigned LTSP (rewritten from scratch in 2019 to support systemd, modern desktops, Wayland, and UEFI); the older codebase is now called LTSP5 and is in minimal maintenance mode.

The boot chain, step by step

Each stage hands off to the next, so a failure at any point stops the client before it reaches a desktop.

  1. Network boot loader (iPXE). The client's firmware (PXE) fetches iPXE, which shows the initial client boot menu and loads the kernel/initrd.
  2. DHCP or ProxyDHCP. dnsmasq or isc-dhcp-server assigns IPs to clients. If another DHCP server already exists on the LAN (for example, a router), LTSP uses a ProxyDHCP server instead so it can supply boot information without conflicting with the existing one.
  3. TFTP transfer. dnsmasq or tftpd-hpa sends the iPXE binary, kernel, and initrd to the client.
  4. Compressed template image. mksquashfs creates a compressed copy of the template image/chroot/VM, which becomes the client's root /.
  5. Image delivery. NFS or NBD serves that squashfs image to the network.
  6. Writable root. tmpfs and overlayfs make the read-only squashfs image temporarily writable for each client, similar to how a live CD works.
  7. Home directory and authentication. NFS or SSHFS provides access to the user's /home directory on the server; SSH, SSHFS, or LDAP authenticates users against the server.

Optional pieces include dnsmasq as a DNS server for caching or blacklisting.

Why one template scales to hundreds of clients

The key mechanism is that clients never hold their own installed operating system. They boot a shared, compressed snapshot of the template and write changes only to a temporary per-client overlay. Update the template once, regenerate the squashfs image, and every client sees the new state on its next boot — there is no per-machine patching.

Component Role Tool used
Boot loader Client boot menu, loads kernel/initrd iPXE
IP assignment DHCP, or ProxyDHCP alongside an existing server dnsmasq or isc-dhcp-server
Boot file transfer Sends iPXE/kernel/initrd dnsmasq or tftpd-hpa
Template compression Compressed client root / mksquashfs
Image serving Delivers squashfs over the network NFS or NBD
Writable layer Temporary per-client writes tmpfs + overlayfs
Home directories Access to server-side /home NFS or SSHFS
Authentication User login against the server SSH, SSHFS, or LDAP

What this means in practice

  • Storage and state: clients are diskless; their writable changes live in RAM-backed tmpfs and disappear on reboot, so treat client state as ephemeral by design.
  • Single point of maintenance: the template (VM image, chroot, or server root) is the only thing you update.
  • Existing network infrastructure: if a router already runs DHCP, LTSP can coexist via ProxyDHCP rather than replacing it.
  • Modern platform support: the 2019 rewrite targets systemd, updated desktop environments, Wayland, and UEFI.

To go further, the project's documentation covers preparation, installation, Raspberry Pi OS, the Personal Package Archive, netboot clients, and man pages for ltsp, ltsp.conf, ltsp-dnsmasq, ltsp-image, ltsp-info, ltsp-initrd, ltsp-ipxe, ltsp-kernel, ltsp-nfs, and ltsp-remoteapps. The installation page is the natural next step once you understand the boot chain above.