UEFI HTTP Boot clarity?

I’m interested in learning more about UEFI HTTPBoot and setting it up for my
LAN as a netboot option, but the details are notably sparse. The best docs I’ve
found are Suse Docs for
configuring an HTTP Boot server, but it’s lacking some information I’m wondering about.

I use PFSense as my DHCP/DNS server. According to this blog,
the option for HTTP boot in PFSense became available in 2.6, which is a pretty
recent release. According to the blog post, PFSense must be configured with a
specialty option to get this to work:

vendor-class-identifier “HTTPClient” with a "Number" of 60.

There’s very little information about the boot process or requirements of
the Network Boot Program (NBP), or the process to prep the payload for netboot.

Have several questions:

  • Can any linux distro that supports UEFI (and has a *.efi file) be pointed to
    for HTTP Boot?
  • What is the process to prep the NBP? Extract a given distro’s ISO contents to
    any HTTP static server and point to the *.efi file in the URL?
  • It seems once the EFI file is loaded, a bootloader is initiated? Will any
    bootloader work, or does it need to be something that specifically supports HTTPBoot?
    How is the bootloader configured such that the *.efi or some other process
    understands to launch that specific bootloader?
  • Is the root file system specified as just the path relative to the host in the
    URI file?
  • Once I have a bootloader configured, if I wanted to have several different available
    distros, do I just need to configure them accordingly in the bootloader config,
    and I can just pick one of the *.efi files to launch it?
  • What is the vendor-class-identifier option, and the "Number" associated with it?
Asked By: eriknelson

||

Can any linux distro that supports UEFI (and has a *.efi file) be pointed to for HTTP Boot?

Assuming its UEFI bootloader does not have any bug or other behavior that would stop it from working with HTTP boot, I cannot see why not.

What is the process to prep the NBP? Extract a given distro’s ISO contents to any HTTP static server and point to the *.efi file in the URL?

Those would be the first steps, yes. Depending on the distro, you might also add some kernel boot options to tell the installation environment to a) (re-)set up networking once OS drivers take over the control of the network interface, b) tell the installation initramfs where to find any further installer components (e.g. a squashfs filesystem image) from, if applicable – this is distribution-specific.

It seems once the EFI file is loaded, a bootloader is initiated? Will any bootloader work, or does it need to be something that specifically supports HTTPBoot? How is the bootloader configured such that the *.efi or some other process understands to launch that specific bootloader?

A UEFI bootloader can use the UEFI LoadFile firmware protocol to load files from the disk. If the UEFI implementation is HTTPBoot-capable, the same firmware protocol can also accept HTTP URLs. The firmware just needs the DHCP server to tell it the URL of the first file to load – it can be a *.efi bootloader executable, or apparently even a complete UEFI-bootable ISO image (see page 13).

Presumably the bootloader can refer to other files in the same URI directory path just like it refers to other files in the same directory as the initial bootloader file when booting from disk media, and any file path that starts with either a forward- or backslash will be interpreted as a full URI path using the hostname as specified by the original full URL given by the DHCP server.

Is the root file system specified as just the path relative to the host in the URI file?

Hold your horses. HTTPBoot’s only job is to get the bootloader up and running, and to allow it to easily load other files from the HTTP server. In the case of Linux bootup, those files would typically be:

  • GRUB configuration file, specifying the paths (or URIs) of further files to load, and default kernel boot options
  • the kernel file
  • the initramfs file, if applicable

Selecting the root filesystem is either the kernel’s or initramfs’s job, and it happens after the kernel has taken over the control of the system from the UEFI firmware. So HTTPBoot has nothing at all to do with specifying the root filesystem.

Regarding the root filesystem, a HTTPBoot should be essentially no different from old-style PXE boot: you’ll probably need an initramfs that will start up and configure Linux network drivers, and then you can use whatever method for accessing a root filesystem that your initramfs can support. For an installer, it could be a squashfs image downloaded to a local RAM disk from a HTTP URL; for other purposes, it could be a NFSroot if you had a reason to do that. How to configure it depends entirely on the distribution you use.

Once I have a bootloader configured, if I wanted to have several different available distros, do I just need to configure them accordingly in the bootloader config, and I can just pick one of the *.efi files to launch it?

Yes, however Secure Boot may complicate things. If you need a shimx64.efi for Secure Boot support, a single shim can usually only support the signing key of the distribution it came with, and an optional Machine Owner’s Key (MOK). If you cannot chainload from the boot menu to another distribution’s shim, you would need to choose one "primary" distribution and manually re-sign the kernels and kernel modules of all non-primary distributions with your own MOK, and have your MOK enrolled in the system NVRAM. Or if your systems allow manipulating the firmware’s Secure Boot keys, you could add each distribution’s Secure Boot certificate to the firmware Secure Boot whitelist (UEFI NVRAM variable db).

What is the vendor-class-identifier option, and the "Number" associated with it?

option vendor-class-identifier is ISC DHCP server’s configuration syntax for DHCP option #60.

A HTTPBoot-capable UEFI firmware should include the DHCP option #60 in its DHCP requests, with the option value set to the string HTTPClient, just like more classic PXE boot clients set this option to a string PXEClient + some hardware/firmware architecture identifiers.

The DHCP server can use this to detect HTTPBoot-capable clients, and it must include the same option in its DHCP responses to those clients.

The DHCP configuration snippet in the SuSE document you linked:

class "httpclients" {
  match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
  option vendor-class-identifier "HTTPClient";
  filename "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
}

essentially says: "if the DHCP request includes the DHCP option 60 and the first 10 bytes of its value form a string HTTPClient, repeat the same option in your answer, and supply the URL to the bootx64.efi in the legacy BOOTP boot filename parameter.

In theory, you could also use DHCP option #67 ("bootfile name") to specify the boot URL, but in practice I’ve seen firmware implementations that corrupt the filename/URL if specified as a DHCP option but accept if BOOTP-form is used – and I guess other implementations might have the opposite bug. So try specifying the URL one way, and if it does not immediately work, and a HTTP server log or network traffic dump indicates the firmware makes a corrupted HTTP request, try the opposite way.

Answered By: telcoM
Categories: Answers Tags: , , , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.