NetBooting a Mac

Most machines network-boot with PXE. A Mac does not. Apple hardware speaks BSDP — Boot Service Discovery Protocol — and a PXE server that does not implement it is simply not offered as a boot option, however correct the rest of the setup is.

Why PXE is not enough

PXE and BSDP both ride on DHCP, and both use the vendor-specific option space. They disagree about what goes in it.

A PXE server answers a discovery with a boot file name and a server address. A Mac's firmware is looking for something else: a list of boot images, each with an identifier and a name, from which it makes a selection and then asks for that specific image. A PXE reply carries none of that, so the firmware concludes there is nothing to boot from and moves on to the internal disk.

Holding the N key at power-on makes a Mac look for a network boot; holding Option shows a picker that includes network images it has been offered. Neither shows anything if the server only speaks PXE.

The conversation

It happens in two rounds, and both are needed.

List. The Mac broadcasts an informational request carrying a BSDP option that says "tell me what you have". The server answers with one or more boot images, each with an identifier, a name and a priority, and marks one as the default.

Select. The Mac chooses an image — the default, or one the user picked in the boot picker — and sends a second request naming that identifier. The server acknowledges with the address to fetch from and the file to fetch.

After that it is ordinary: the firmware pulls the booter over TFTP and runs it.

What AnotherOS does with it

Once the Mac's firmware has fetched and run a booter, the rest of the chain is the same one every other machine uses: a bootloader with a menu, a kernel, and a root filesystem fetched over the network.

The full chain is proven end to end, and the load-bearing evidence is that the kernel mounts its root over NFS. Nothing earlier in the chain speaks NFS at all — not the firmware, not the intermediate loader — so an NFS mount request arriving from the machine can only mean the AnotherOS kernel ran, brought up a network interface, took a lease and mounted its own root.

A trap worth knowing about

A machine that boots from a disk image carries its own boot configuration inside that image.

That means it does not pick up changes made to the server's boot menus. Every other client tracks the server; this one tracks the image it was given. If the image is not refreshed it goes stale silently — the machine boots perfectly, into an old kernel, while every other machine on the network has moved on.

If a Mac is behaving like an older build than everything else, this is almost always why.

Status

The chain works and has been reproduced on separate occasions rather than once.

What is not yet proven is what happens after the desktop should appear: there is no photographic record of the panel for these boots, so "it boots and mounts its root" is claimed here and "the desktop composites and the machine stays up" is not.

That distinction is the whole point of stating it. A boot that reaches the root mount is not the same claim as a machine you can use, and the second needs somebody standing in front of it.