Remote Starter

Individual PXE Configurations

Not every client that starts by PXE has to be given the menu from the default configuration file. Before PXELinux offers a client the default, it first searches for individual configuration files. The service initially checks whether a file that matches the client's MAC address exists. For example, if the client boots with a MAC address 48:2a:01:02:03:ff , PXELinux looks for a file named 01-48-2a-01-02-03-ff in /var/lib/tftpboot/pxelinux.cfg/. If the file does not exist, the program looks for configuration files that match the IP address in hexadecimal format. If a client boots with an IP of 192.168.2.201, PXELinux looks for configuration files such as C0A802C9, C0A802C, and C0A802, down to C. If these do not exist, and only then, the start service resorts to the default configuration.

Therefore, you can create individual boot files for single clients or groups. The Dnsmasq option for assigning fixed IP addresses to individual clients by dnsmasq.conf is useful:

dhcp-host=48:2a:01:02:03:ff, 192.168.2.100,infinite

The address needs to be outside of the initially defined DHCP pool. If you want the selected client to keep this address, simply set the lease time to infinite.

PXE by UEFI

Along with the Itanium processor, Intel introduced EFI as a BIOS replacement in the 1990s, lifting the BIOS's 16-bit restriction and supporting individual extensions. Starting in 2005, an alliance of various manufacturers joined forces in the Unified UEFI Forum, which has since developed into what is now no longer a proprietary specification but the open source UEFI. Another open source implementation, EDK2, is maintained by the TianoCore community and is used in the free KVM hypervisor.

UEFI itself can address disks with the GUID partition table (GPT) format and can even access file allocation table (FAT) disks without the operating system running. On Linux, the UEFI boot partition is usually found in /boot/efi. UEFI allows a secure boot process by executing only correctly signed files with valid keys, which has caused debate in the past – many hardware manufacturers only implement Microsoft keys on their machines, so you can only boot Windows if Secure Boot is enabled.

Today, the Microsoft shim-signed UEFI first-stage bootloader is available for Linux, which builds its own secure trust chain with programs downstream (e.g., GRUB or the Linux kernel). The computer itself only has to trust the shim to boot open source Linux securely. However, users do have to create their own keys and sign the other programs in the boot sequence (e.g., GRUB and the system kernel). In the remainder of this article, I do not go further into Secure Boot but, instead, look at UEFI boot with Secure Boot disabled.

Extending Dnsmasq

To start a designated Linux computer with UEFI, you first need the primary (shim) and secondary (GRUB) launcher. The files you need, shimx64.efi and grubx64.efi, are available from the repositories of your Linux distribution. The easiest approach is to turn to a previously installed Linux machine with a /boot/efi partition. Copy the two files from there into the /var/lib/tftpboot directory on your Dnsmasq server. On Fedora, for example, the bootloaders are located in

/boot/efi/EFI/fedora.

Next, build a new boot menu for the UEFI machines, this time with GRUB rather than Syslinux, by first creating a /var/lib/tftpboot/grub.cfg file. The grub.cfg syntax is a bit more complex, but it is documented in great detail online [4]. In Listing 2, I used a small default header, which is followed by the menu entries that can be started by UEFI. In the PXELinux example, the menu entry for the Fedora 34 Live system would look like Listing 3.

set default="0"
function load_video {
      insmod efi_gop
      insmod efi_uga
      insmod video_bochs
      insmod video_cirrus
      insmod all_video
}
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set timeout=10

menuentry ,Fedora 34 Live' --class fedora --class gnu-linux --class gnu --class os {
   linux (http,<IP address of DHCP server>)/f34/images/pxeboot/vmlinuz ro rd.live.image rootovl=1 root=live:http://<IP address of DHCP server>/f34/LiveOS/squashfs.img initrd (http,<IP address of DHCP server>/)/f34/images/pxeboot/initrd.img
}

Like PXELinux, GRUB first looks for individual configuration files. The naming scheme is:

• grub.cfg-01-48-2a-01-02-03-ff for a direct MAC address
• grub.cfg-C0A802C to grub.cfg-C, depending on the IP address.

If none of these files fits the bill, and again only then, GRUB serves up the menu from grub.cfg.

To help the Dnsmasq server distinguish between computers that use a BIOS and computers that use a UEFI boot, you need two entries in /etc/dnsmasq.conf. The first assigns the efi-x86_64 label to client architecture 7 (UEFI 64-bit PC). The second entry then sets up the boot file for this architecture:

dhcp-match=set:efi-x86_64,option:client-arch,7
dhcp-boot=tag:efi-x86_64,shimx64.efi

Now the Dnsmasq server can easily handle BIOS PXE clients with PXELinux and UEFI PXE clients with the shim and GRUB.