Booting BIOS-based PXE clients via SUSE Manager and its integrated “Cobbler” component is very easy and well-documented. But as more and more hardware vendors decide to switch to UEFI, how about PXE-booting these?
As a matter of fact, it’s surprisingly easy and only takes a few steps. The following steps were tested with SUSE Manager v3.2.3 (the latest version at the time of writing this article), but it should be no different even for 3.1 installations.
General structure
If you already know your way around PXE booting, you can safely skip this part of the article and move right on to “configuring your SUSE Manager system”.
PXE booting is a multi-step process to bring up a system (usually a hardware machine, but it will work for virtual machines, too, if the hypervisor supports PXE boot) when it has no operating system installed. Typically, it’s used to install a system automatically, without having to use the system’s console, nor insert any installation media.
The first step is, of course, the booting machine itself. In order to boot it via network, it needs to be configured accordingly. This is very machine-specific and involves making sure the network adapter(s) are enabled, connected to the network and allow PXE boot. Another important configuration is the boot order: If you have an installed operating system on local media and set that disk to boot from first, you’ll never reach the PXE step, even if it’s configured as a later option. And if you connect your machine to networks via multiple adapters, pay attention to which adapters are set for PXE boot and in which boot order.
The network adapter, during machine boot, will send out a plain DHCP query, broadcasting to the network its presence and waiting for network parameters.
This brings us to step two, the DHCP server: In order to support a client doing its PXE boot, the DHCP server will have to provide two additional parameters to the client (on top of the general network parameters, like IP address, gateway etc): Which server should the client turn to, to receive its OS boot files? And which one is to be the first file it should be asking for?
The first parameter is called, in DHCP terms, “next-server” and the second one is simply “filename”. “next-server” will be pointing to your local instance of SUSE Manager, be it a master server, a SUSE Manager Proxy or an ISS slave. The “filename” parameter is the “first stage boot loader” and depends on the type of system to boot – more details follow below.
Once the client has received its network parameters and the accompanying “next-server” and “filename” information, it will set up its IP stack and then tries to retrieve the file stated in “filename” from the TFTP server on the server pointed to by “next-server”.
So we’re now at step 3, TFTP: On the SUSE Manager system, a TFTP server needs to be running and serving content from a (well-known) directory. Typically, you’ll have “atftpd” running on your SUSE Manager machine, serving the content of “/srv/tftpboot”. So any reference to file names that you see during tftp transactions will be relative to “/srv/tftpboot”, even if given as absolute path names: A client requesting “/etc/passwd” will not get to your sensitive information, but receive the content of the file “/srv/tftpboot/etc/passwd”, should it exist.
The client will treat that first file (from the “filename” parameter) as a program to execute, making that the stage 1 bootloader.
Configuring your SUSE Manager system
To support booting BIOS clients via PXE, there’s not much to do: All you need is a proper Cobbler configuration (which is created for you, once you set up autoinstallation profiles) and a running TFTP server. So check your system to see if atftpd.service is both enabled and active.
Supporting x86_64 UEFI clients needs only a small bit more on the SUSE Manager: You need to make sure that the two packages “shim” and “grub2-x86_64-efi” are installed. Once they are and the Cobbler configuration gets synchronized (either automatically, when reconfiguring autoinstallation profiles, or manually by calling “cobbler sync” on your SUSE Manager’s command line), Cobbler will make sure all files required for PXE boot (for both BIOS and UEFI clients) are copied to “/srv/tftpboot”.
Configuring your DHCP server
If you run your DHCP server on your SUSE Manager machine, Cobbler can even generate the according configuration for you. But I have yet to see an installation (outside a test bed) where this is the case: Usually, DHCP is provided by some corporate DHCP servers outside Cobblers control.
Basically, all you have to do is provide the proper values for “next-server” and “filename” to your PXE clients. But while “next-server” is easily set up (it just needs to point to i.e. the IP address of the SUSE Manager that is to serve the according client), “filename” requires a bit more work:
Booting a BIOS PXE client requires this parameter to point to “/pxelinux.0”, while booting an “Intel 64-bit” UEFI client requires to provide “/grub/x86_64-efi/grub.efi”. If you have other PXE clients, for instance ARM-based machines, you’ll need according other stage 1 bootloaders.
Of course you could set up the “filename” parameter of each system individually – but that wouldn’t support typical use cases, like booting up any client without pre-configuring the DHCP server. So you’ll need to resort to an automatism, i. e. provided by ISC’s dhcpd: Setting values according to the “arch” option of the client. If you have only BIOS and UEFI x86-64 clients, you can tell the DHCP server to set the parameter accordingly by putting into /etc/dhcpd.conf:
if option arch = 00:07 or option arch = 00:09 {
filename "/grub/x86_64-efi/grub.efi";
} else {
filename "/pxelinux.0";
}"
The only thing that is missing now is that “option arch” – that’s not available in the dhcpd configuration by default, so it needs to be configured in dhcpd.conf, too – preferably at the top of your configuration:
option arch code 93 = unsigned integer 16
And if you’re using an LDAP-based dhcpd configuration, both above statements go into “dhcpStatemens” elements and you can put the definition of “option arch” into the top leaf of your configuration. Where you put the conditional definition of “filename” depends on your setup – we’ve put it into the leaf describing our group of SUSE Manager managed auto-installation hosts, which are explicitly defined to our dhcpd. But of course, that’s only useful if you know your hosts in advance.
So to sum it up, integrating UEFI PXE boot into your existing (BIOS) PXE environment is nothing more than making sure your clients will receive the proper “filename” value. Everything else can stay as it is, no need for i. e. special Cobbler definitions or alike. Piece of cake 🙂