Netbooting a room of identical machines with kentonv/lanparty

Twenty-two identical desktops, one storage server

The scenario behind this repository is narrow and specific: a house with 22 identical machines used for LAN parties. The stated problems were ordinary ones. Every machine would need updating before each event, and with games that ship multi-GB patches that job would take a very long time. Guests would also break machines, and the recovery path was to wipe the disk and start over, which took even longer.

The author also names the intended audience beyond his own use: office machines, internet cafes and school computer labs. That list is worth reading carefully, because it defines the constraints the design accepts. The machines are identical, they are on a private network, they are wiped after use, and one person owns the whole room. Nothing in the approach assumes a machine must keep its state, and nothing assumes a mixed hardware fleet.

The repository itself is small. The top level holds a LICENSE file, README.md, guide.md, an executable named lanparty, and a photos directory. The project is written in shell, and there are no GitHub releases attached to the repository, so there is no published version history to consult; the guide and the script are the artefacts you actually get.

The homepage link in the README points to lanparty.house, which describes the house the setup runs in.

The boot path: DHCP, tftp, iPXE and iSCSI

The machines in this setup do not use their own disks. The README says they netboot over iSCSI from a single server that manages all the storage. The boot chain that makes that possible is spelled out in the list of things the repository helps you do: configure DHCP, tftp, iPXE and iSCSI for netboot.

Each of those pieces has a distinct job. DHCP hands a client the address of a network boot service, tftp serves the small bootstrap file the machine downloads first, iPXE is the firmware-level boot loader that runs it, and iSCSI carries the actual block-level disk traffic once the client is pointed at a remote volume. The client ends up presenting a remote iSCSI target as its local disk, and the operating system that boots from it has no idea it is running on a network device.

That arrangement is the heart of the trick, and it is also its main cost. The storage server is on the data path for every read and every write of every machine, not just for the boot. The README does not document any tuning of iSCSI parameters, any caching policy, or any way to measure the bandwidth the fleet consumes, so anyone sizing this has to work that out from the workload rather than from the project.

The optional private DNS server is a smaller, separate concern. Its purpose is to let the machines address each other by name, which matters when a game or a lobby needs to discover peers on the LAN. It is listed as optional in the README, so a setup where machines only talk to a server can leave it out.

A master image and one copy-on-write overlay per machine

Storage is organised around a single master image plus a private overlay for each game machine, built on LVM. The README describes the semantics in plain terms. Writes originating from one machine land only in its own overlay. Reads consult the overlay first, and if the data has not been modified there, the read is served directly from the master image.

The consequences are what make the design attractive for a party. Overlays start empty, so they can be created at the start of an event without copying the full contents of the disk, which the author notes would otherwise take forever. At the end of an event the overlays are deleted, which discards everything the guests did to the machines. Each overlay only has to hold the changes made during a session, and the README puts 20GB per overlay as plenty even when the master image is terabytes in size.

That size figure is the one number in the repository worth holding on to, because it is an assumption rather than a measurement. The storage budget for a session is proportional to how much a guest writes, not to how large the image is, but a session that installs a large game or writes a lot of local save data will exceed 20GB, and the README does not describe what happens when an overlay fills.

There is also a subtle point about the master image. It is not read-only. After an update session the overlay is merged back into the master, so the master changes over time and carries the accumulated result of every merge. The README does not document a backup, a snapshot or a rollback for the master volume, and that gap matters more here than in most projects, because the master is the only copy of the installed operating system and every game.

Updates run through an overlay, then merge back into the master

The update path is the reason the whole thing exists, and it is described in one line: updates are still installed using an overlay, and once the updates are complete that overlay is merged back into the master image. The result stated in the README is that updates are installed once and become immediately available to all the machines, with no need even to clone the disk image.

Read as a workflow, an update session runs like this. The operator creates a working overlay, installs the updates into it, and then merges that overlay into the master. The merge is the risky step, because it mutates the single copy of the installed system. If the merge is interrupted, the master is in a state that the README does not describe any way to recover from.

What this design buys is worth stating plainly, because it is not a small gain. Twenty-two machines that each needed a multi-GB patch would need twenty-two installations of it. Here, one installation serves everyone, and the clients pick it up at their next boot because they read through the master.

The cost is a different kind of coupling. The fleet shares one boot image, so an update that breaks a game breaks it for the whole room at once, and there is no per-machine rollback because there is no per-machine copy. A setup that needs to pilot a change on one machine before releasing it to the others cannot use this flow as written.

What the lanparty script automates and what the guide covers

The repository separates the automation from the explanation. The executable named lanparty is the tool the author uses to manage the computers; guide.md is the document that walks a reader through building an equivalent setup. The README points readers to the guide for getting started, and the guide is not reproduced in the project description, so the exact commands the script accepts are not visible from the outside.

The scope of the script is described in the list of jobs the repository helps with: creating a master volume and space for overlays using LVM, configuring DHCP, tftp, iPXE and iSCSI, optionally setting up the private DNS server, and setting up and tearing down overlays for parties, including arranging the installation of updates. Installing Windows 10 directly to an iSCSI device is listed as a supported task as well.

That last item is a signal about the audience. Netbooting a Windows install to a remote iSCSI volume is a fiddly sequence of firmware, driver and partitioning steps, and the fact that it is offered as a documented outcome suggests the guide is aimed at people willing to do that kind of work rather than at a general sysadmin audience.

One point of confusion is worth flagging for a newcomer. The README says the house has 22 machines, but a later sentence talks about maintaining twelve machines used by random guests. The two numbers are not reconciled anywhere in the visible text, so treat the exact fleet size as a detail of the author's own house rather than a specification of the script. The README also does not document command line flags, a configuration file format, or a dry-run mode for the lanparty script.

Where the single-server design breaks down

The architecture concentrates risk in one place, and the README does not address that. One server holds the master image, serves the overlays, and provides the boot services to every client. If it goes down, none of the machines can start, and none of them can be repaired by the person standing in front of them. There is no replication, no failover and no mention of a second storage node. Whether that is acceptable depends entirely on the site: for a weekend at a house with a spare machine in a cupboard, yes; for a school lab that has to open on Monday, less so.

A second limit is the homogeneity assumption. Because every client boots the same master, differences in hardware, disk geometry or firmware have to be handled outside this setup, and the README does not describe a mechanism for per-machine variation. It also says the machines do not use their own disks at all, so local storage is not a fallback.

A third limit is network dependence. The clients are doing disk I/O over the network for the whole session, including a game's read and write pattern, which is heavier than a boot-only workload. The README does not report any measurement of that traffic or state a recommended switch or cabling standard.

Finally, the security question sits outside the documentation. iSCSI targets are normally protected by some form of access control, and the machines in this setup are handed to guests. The README lists DHCP, tftp, iPXE, iSCSI and DNS as the services to configure, but it does not describe authentication for the storage target, and a boot environment on a local network hands out addresses and boot code to anything that asks.

Licence, release history and the cost of taking it over

The licence is MIT, which is permissive enough that the script and the guide can be reused in a commercial or internal setting with attribution and preservation of the licence text, and without any requirement that derivative work be published. This is a description of the published terms rather than legal advice.

On maintenance, the repository is not archived and the last push was on 2026-08-28. There are no GitHub releases, so there is no version to pin, no upgrade notes and no changelog to read; the only artifacts are the guide and the script in the default branch, which means you either copy them into your own infrastructure and maintain them, or you track the branch and absorb changes as they land. For a shell script driving LVM, DHCP, tftp and iPXE on your own network, copying and owning the code is usually the more predictable arrangement.

The upgrade cost is mostly operational rather than technical. A new version of the script may assume a different layout of volumes, boot files or services than the one you built, and the guide that explains those assumptions is part of the same repository, so version skew between the copy of the script you run and the copy of the guide you followed is a realistic failure mode.

One last detail that shapes the whole project: the photos directory and the lanparty.house link show a specific physical room, and the guide is written around that hardware. Reproducing the result means reproducing the assumptions, not just copying the script.

Editorial conclusion

lanparty is a good fit for a room of identical machines that a stranger will touch for a weekend, such as a LAN party hall, a school lab or an internet cafe, provided the host is comfortable with iSCSI, LVM and PXE. It is a poor fit for mixed hardware, for machines that must hold state between events, or for a site that cannot give one server and one storage array the job of being the single source of every disk. Before adopting it, read guide.md end to end and confirm that your network will carry a full boot image plus a game's disk traffic for every client, and check whether the master volume has enough headroom for the merge step that follows an update.

Frequently asked questions

Official sources

1. Issues
2. kentonv/lanparty on GitHub
3. License: MIT
4. README