How (not) to netboot

HTTP is cool – if it works

• software

Last month, I had a disk image that I wanted to boot on another device.

So, how does that work?

the past

In the nineties, as part of Wired for Management, Intel invented the Preboot Execution Environment (PXE).¹

This worked roughly in the following way (remember that there was no UEFI back in the days):

1. the firmware executes an option ROM stored on the network card as part of the normal boot process
2. the ROM makes a DHCP request
3. the DHCP offer contains the IP address of a TFTP² server and a path
4. the ROM fetches the file via TFTP and begins executing

PXE transfers and executes single binaries. You can’t put a whole disk image on there. You can’t even do the usual kernel-plus-initrd-combination.

At least not on its own. Syslinux has PXELINUX, which allows reading a configuration file, displaying a menu and loading a kernel plus its initrd. This is nice, but it’s still not a whole disk image.

Syslinux also has MEMDISK which can be loaded as a kernel and it then “mounts”³ the initrd as a disk image and boots from it. So, by combining PXELINUX and MEMDISK, you can boot a disk image over PXE.

If you don’t like the ROM on your network card (or if it doesn’t support PXE or if you want to chainload from another bootloader), iPXE can be used instead.⁴ iPXE also supports HTTP which is way easier to setup and more reliable.

If you hardcode the HTTP URL (eg. in a configuration file), you don’t need to pass any additional information in the DHCP offer.⁵ This configuration can be built into the iPXE binary or passed by the previous bootloader. It could also be served over HTTP (which would then need to be advertised via DHCP or a different configuration file).

the present

UEFI also supports PXE; the executables aren’t raw x86 binaries but UEFI executables instead. If you have Secure Boot enabled (which you should!) it also applies here, making this method actually secure.

But MEMDISK doesn’t work: You can’t hook interrupts to handle disk access if disk access doesn’t happen through interrupts. In theory, it shouldn’t be hard to write a UEFI application that registers a disk image that it gets passed as a Block I/O device. The firmware should then recognize the partitions and load the appropriate drivers to get the Simple File System up and running.

I found an implementation of this on GitHub and while it looks promising, I sadly didn’t manage to use it successfully.

iPXE on UEFI does this interesting trick where it allows you to download additional files with the initrd command — and it then creates a virtual Simple File System containing just those files. So, if you don’t really need the whole disk image but only a few files, this might work for you!

If you do need the whole disk image but if GRUB is used as the bootloader in the image, you can create your own grub.efi with grub-mkimage — and if you pass --memdisk, your disk image is included in the GRUB image and can be accessed as (memdisk). And you can the boot this GRUB image via PXE or iPXE.

the future

Or you can boot it directly via HTTP. Modern UEFI implementations may be able to download and execute stuff via HTTP. And if you pass a disk image instead of a UEFI application, the firmware will mount it and boot from it. Pretty nice!

I think the easiest way to get this to work is to add a boot entry. This might be possible either via your firmware setup or via efibootmgr, but I only tried this on OVMF. Or you can pass a HTTP URL in the DHCP offer.

Depending on your firmware, this method might also allow you to use HTTPS⁶.

The devices I’m trying to boot on don’t support HTTP booting, so that’s why this section is so short.

why?

Maybe you have a large number of devices that should boot the same operating system. And maybe those devices don’t have a hard disk.

I’m doing this because I’m fiddling with operating systems and netboot is more neat than repeatedly writing to a USB key and then connecting it to one computer after another. More details on that may follow in a future blog post, so stay tuned.