17 Preparing network boot environment #
This chapter describes how to configure a DHCP and a TFTP server that provide the required infrastructure for booting with PXE.
SUSE® Linux Enterprise Server can be installed via a Preboot Execution Environment (PXE). The client hardware needs to support booting via PXE. The network needs to provide a DHCP server and a TFTP server providing the required data to the clients. This chapter guides you through setting up the required servers.
PXE only boots a kernel and initrd. This can be used to boot into an installation environment or into live systems. To set up the installation sources, see Chapter 16, Setting up a network installation source.
This section covers the configuration tasks needed in complex boot scenarios. It contains ready-to-apply configuration examples for DHCP, PXE boot, TFTP, and Wake on LAN.
The examples assume that the DHCP, TFTP and NFS server reside on the
same machine with the IP 192.168.1.1
. All services
can reside on different machines without any problems. Make sure to
change the IP addresses as required.
17.1 Setting up a DHCP server #
A DHCP server provides both dynamic (Section 17.1.1, “Dynamic address assignment”) and static IP address assignments (Section 17.1.2, “Assigning static IP addresses”) to your network clients. It advertises servers, routes, and domains. For TFTP servers, DHCP also provides the kernel and initrd files. Which files are loaded depends on the architecture of the target machine, and whether legacy BIOS or UEFI boot is used. The clients transmit their architecture type in their DHCP requests. Based on this information, the DHCP server decides which files the client must download for booting.
Starting with SUSE Linux Enterprise 15.0, there are special conditions that cause PXE boot and AutoYaST installations to fail. See Section 17.1.3, “PXE and AutoYaST installation failures” for more information and the solution.
17.1.1 Dynamic address assignment #
The following example shows how to set up a DHCP server that dynamically assigns IP addresses to clients, and advertises servers, routers, domains, and boot files.
Log in as
root
to the machine hosting the DHCP server.Enable the DHCP server by executing
systemctl enable dhcpd
.Append the following lines to a subnet configuration of your DHCP server's configuration file located under
/etc/dhcpd.conf
:# The following lines are optional option domain-name "my.lab"; option domain-name-servers 192.168.1.1; option routers 192.168.1.1; option ntp-servers 192.168.1.1; ddns-update-style none; default-lease-time 3600; # The following lines are required option arch code 93 = unsigned integer 16; # RFC4578 subnet 192.168.1.0 netmask 255.255.255.0 { next-server 192.168.1.1; range 192.168.1.100 192.168.1.199; default-lease-time 3600; max-lease-time 3600; if option arch = 00:07 or option arch = 00:09 { filename "/EFI/x86/grub.efi"; } else if option arch = 00:0b { filename "/EFI/aarch64/bootaa64.efi"; } else { filename "/BIOS/x86/pxelinux.0"; } }
This configuration example uses the subnet
192.168.1.0/24
with the DHCP, DNS and gateway on the server with the IP192.168.1.1
. Make sure that all IP addresses are changed according to your network layout. For more information about the options available indhcpd.conf
, refer to thedhcpd.conf
manual page.Restart the DHCP server by executing
systemctl restart dhcpd
.
17.1.2 Assigning static IP addresses #
A DHCP server may also assign static IP addresses and host names to network clients. One use case is assigning static addresses to servers. Another use case is restricting which clients may join the network to those with assigned static IP addresses, and providing no dynamic address pools.
Modify the above DHCP configuration according to the following example:
group { host test { hardware ethernet MAC_ADDRESS; fixed-address IP_ADDRESS; } }
The host statement assigns a host name to the installation target. To bind the host name and IP address to a specific host, you must specify the client's hardware (MAC) address. Replace all the variables used in this example with the actual values that match your environment, then save your changes and restart the DHCP server.
17.1.3 PXE and AutoYaST installation failures #
Starting with SUSE Linux Enterprise 15.0 and ISC DHCP 4.3.x, there are special circumstances that cause PXE boot and AutoYaST installations to fail. If your DHCP server does not have a pool of available dynamic IP addresses, but allows only pre-defined static addresses per client, and the clients send RFC 4361 client identifiers, then PXE/AutoYaST installations will not work. (Allowing only addresses assigned to specific network clients, and providing no dynamic address pools, prevents random machines from joining the network.)
When a new system starts in PXE, it sends a request to the DHCP server and
identifies itself using a client identifier constructed from the hardware type plus
the MAC address of the network interface. This is an RFC 2132 client-id
. The DHCP
server then offers the assigned IP address. Next, the installation kernel is loaded,
and sends another DHCP request, but this client-id
is different, and is sent in
RFC 4361 format. The DHCP server will not recognize this as the same client, and
will look for a free dynamic IP address, which is not available, and the installation stops.
The solution is to configure clients to send RFC 2132 client IDs.
To send an RFC 2132 client-id
during the installation, use
linuxrc
to pass
the following ifcfg
command:
ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67, DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67
The traditionally-used RFC 2132 DHCPv4 client-id
on
Ethernet is constructed from the hardware type (01
for
Ethernet) and followed by the hardware address (the MAC address), for
example:
01:52:54:00:02:c2:67
The RFC 4361 DHCPv4 client-id
attempts to correct the problem
of identifying a machine that has more than one network interface. The new
DHCPv4 client-id
has the same format as the DHCPv6
client-id
. It starts with the
0xff
prefix, instead of the hardware type, followed by the
DHCPv6 IAID (the interface-address association ID that describes the
interface on the machine), followed by the DHCPv6 Unique Identifier (DUID),
which uniquely identifies the machine.
Using the above hardware type-based and hardware address-based DUID, the new
RFC 4361 DHCPv4 client-id
would be:
Using the last bytes of the MAC address as the IAID:
ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
When the IAID is a simple incremented number:
ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
The xx:xx:xx:xx field in the DUID-Link-Layer
Timestamp (DUID-LLT) is a creation time stamp. A DUID-Link-Layer (DUID-LL)
(00:03:00:01:$MAC
) does not have a time stamp.
For more information on using linuxrc
, see the AutoYaST Guide.
Also see man 4 initrd
, and the
documentation for the options dhcp4
"create-cid"
, dhcp6 "default-duid"
in
man 5 wicked-config
, wicked duid
--help
, and wicked iaid --help
.
17.2 Setting up a TFTP server #
The following procedure describes how to prepare the server so that the client machines with UEFI and BIOS can boot remotely using files exported by TFTP.
17.2.1 Installing a TFTP server #
To install a TFTP server, use the following procedure:
Install the
tftp
package.>
sudo
zypper in tftp
Review the
tftpd
configuration in/etc/sysconfig/tftp
and add or change options as required. Refer toman 8 tftpd
for more details. The TFTP daemon works without changing the configuration. The default root directory for the files is/srv/tftpboot
.Ensure that
tftpd
is started at boot time, and restart it to read the new configuration.>
sudo
systemctl enable tftp.socket
>
sudo
systemctl restart tftp.socket
17.2.2 Installing files for boot #
SUSE Linux Enterprise Server provides the required files for booting via PXE on BIOS or UEFI machines. The following hardware architectures are supported:
AMD64/Intel 64
AArch64
POWER
IBM Z
Files required to boot from a specific hardware architecture are included in an RPM package. Install it on the machine running the TFTP server:
>
sudo
zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE
Replace OS_VERSION with the version number of
your SUSE Linux Enterprise Server installation, for example
SLE-15-SP3-x86_64, and replace
ARCHITECTURE with the architecture of your
system, for example x86_64
. So the resulting text would
look like this: tftpboot-installation-SLE-15-SP3-x86_64.
Run zypper se tftpboot
to search for all available
versions and architectures.
The files will be installed in
/srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE
.
You can also copy the files for other versions and architectures of
SUSE Linux Enterprise Server to the /srv/tftpboot
directory.
The client and server hardware architecture can vary. For example, you can run an AMD64/Intel 64 TFTP server and provide a bootable environment for AArch64 client machines by installing the tftpboot-installation-SLE-15-SP3-aarch64 package.
/srv/tftpboot/
directory
If the directory /srv/tftpboot/
already
exists on your machine, then all files will be installed to
/usr/share/tftpboot-installation/
. This is
the case if you are upgrading your PXE server from a previous
SLES release.
To fix this problem, copy the files manually from
/usr/share/tftpboot-installation/
to
/srv/tftpboot/
. Alternatively, remove
/srv/tftpboot/
and reinstall the
tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE
package.
17.2.3 Configuring PXELINUX #
Open the file
/srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default
in an editor. Replace the path for the install
parameter according to your setup as described in Chapter 16, Setting up a network installation source. Also replace
TFTP_SERVER with the IP address of the
TFTP server. For an overview of the PXELINUX configuration options,
see Section 17.3, “PXELINUX configuration options”.
default linux # install label linux ipappend 2 kernel boot/ARCHITECTURE/loader/linux append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH display message implicit 1 prompt 1 timeout 50
For details about the boot parameters that are used in the append
line,
see Section 7.3, “List of important boot parameters”.
If required, edit the
/srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message
to display a message in the boot menu.
17.2.4 Preparing PXE boot for EFI with GRUB2 #
Normally, the GRUB2 configuration files require no
modifications. However, the default settings do not include
a network resource for the installation system.
To perform a full SUSE Linux Enterprise Server installation via
network, you need to specify the install
parameter in the linuxefi
instruction of the
/srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg
file. Refer to Section 7.3.3, “Specifying the installation source” for further
information about the install
parameter.
17.3 PXELINUX configuration options #
The options listed here are a subset of all the options available for the PXELINUX configuration file.
APPEND OPTIONS
Adds one or more options to the kernel command line. These are added for both automatic and manual boots. The options are added at the very beginning of the kernel command line, usually permitting explicitly entered kernel options to override them.
APPEND -
Appends nothing.
APPEND
with a single hyphen as argument in aLABEL
section can be used to override a globalAPPEND
.DEFAULT KERNEL_OPTIONS...
Sets the default kernel command line. When PXELINUX boots automatically, it executes the specified entries, appending the
auto
option.If no configuration file exists or no DEFAULT entry is defined in the configuration file, the default is the kernel name “linux” with no options.
IFAPPEND FLAG
Adds a specific option to the kernel command line depending on the FLAG value. The
IFAPPEND
option is available only on PXELINUX. FLAG expects a value, described in Table 17.1, “Generated and added kernel command line options fromIFAPPEND
”:Table 17.1: Generated and added kernel command line options fromIFAPPEND
#Argument
Generated kernel command line / Description
1
ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK
The placeholders are replaced based on the input from the DHCP/BOOTP or PXE boot server.
Note, this option is not a substitute for running a DHCP client in the booted system. Without regular renewals, the lease acquired by the PXE BIOS will expire, making the IP address available for reuse by the DHCP server.
2
BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE
This option is useful to avoid timeouts when the installation server probes one LAN interface after another until it gets a reply from a DHCP server. This option allows an initrd program to determine from which interface the system has been booted. linuxrc reads this option and uses this network interface.
4
SYSUUID=SYSTEM_UUID
Adds UUIDs in lowercase hexadecimals, see
/usr/share/doc/packages/syslinux/pxelinux.txt
LABEL LABEL KERNEL IMAGE APPEND OPTIONS...
Indicates that if LABEL is entered as the kernel to boot, PXELINUX should instead boot IMAGE and the specified
APPEND
options should be used. They replace the ones specified in the global section of the file, before the firstLABEL
command. The default for IMAGE is the same as LABEL and, if noAPPEND
is given, the default is to use the global entry (if any). Up to 128LABEL
entries are permitted.PXELINUX uses the following syntax:
label MYLABEL kernel MYKERNEL append MYOPTIONS
Labels are mangled as if they were file names and they must be unique after mangling. For example, the two labels “v2.6.30” and “v2.6.31” would not be distinguishable under PXELINUX because both mangle to the same DOS file name.
The kernel does not need to be a Linux kernel. It can also be a boot sector or a COMBOOT file.
LOCALBOOT TYPE
On PXELINUX, specifying
LOCALBOOT 0
instead of aKERNEL
option means invoking this particular label and causes a local disk boot instead of a kernel boot.Argument
Description
0
Perform a normal boot
4
Perform a local boot with the Universal Network Driver Interface (UNDI) driver still resident in memory
5
Perform a local boot with the entire PXE stack, including the UNDI driver, still resident in memory
All other values are undefined. If you do not know what the UNDI or PXE stacks are, specify
0
.TIMEOUT TIME-OUT
Indicates how long to wait at the boot prompt until booting automatically, in units of 1/10 second. The time-out is canceled when the user types anything on the keyboard, assuming the user will complete the command begun. A time-out of zero disables the time-out completely (this is also the default). The maximum possible time-out value is 35996 (just less than one hour).
PROMPT flag_val
If
flag_val
is 0, displays the boot prompt only if Shift or Alt is pressed or Caps Lock or Scroll Lock is set (this is the default). Ifflag_val
is 1, always displays the boot prompt.F2 FILENAME F1 FILENAME ..etc... F9 FILENAME F10 FILENAME
Displays the indicated file on the screen when a function key is pressed at the boot prompt. This can be used to implement preboot online help (presumably for the kernel command line options). For backward compatibility with earlier releases, F10 can be also entered as
F0
. Note that there is currently no way to bind file names to F11 and F12.
17.4 Preparing the target system for PXE boot #
Prepare the system's BIOS for PXE boot by including the PXE option in the BIOS boot order.
Do not place the PXE option ahead of the hard disk boot parameter in the BIOS. Otherwise this system would try to re-install itself every time you boot it.
17.5 Using wake-on-LAN for remote wakeups #
Wake-on-LAN (WOL) is an Ethernet standard for remotely waking up a computer by sending it a wakeup signal over a network. This signal is called the “magic packet”. Install WOL on client machines to enable remote wakeups, and on every machine you want to use for sending the wakeup signal. The magic packet is broadcast over UDP port 9 to the MAC address of the network interface on the client machine.
When computers are shut down they usually are not turned all the way off, but remain in a low power mode. When the network interface supports WOL, it listens for the magic packet wakeup signal when the machine is powered off. You can send the magic packet manually, or schedule wakeups in a cron job on the sending machine.
17.5.1 Prerequisites #
WOL works with both wired and wireless Ethernet cards that support it.
You may need to enable WOL in your system BIOS/UEFI.
Check your BIOS/UEFI settings for PXE boot, and make sure it is disabled to prevent accidental re-installations.
Adjust your firewall to allow traffic over UDP port 9.
17.5.2 Verifying wired Ethernet support #
Run the following command to see if a wired Ethernet interface supports WOL:
>
sudo
ethtool eth0 | grep -i wake-on Supports Wake-on: pumbg Wake-on: g
The example output shows that eth0 supports WOL, indicated by the
g
flag on the Supports Wake-on
line.
Wake-on: g
shows that WOL is already enabled, so this
interface is ready to receive wakeup signals. If WOL is not enabled,
enable it with this command:
>
sudo
ethtool -s eth0 wol g
17.5.3 Verifying wireless interface support #
Wakeup-over-wifi, or WoWLAN, requires a wireless network interface that
supports WoWLAN. Test it with the iw
command, which
is provided by the iw package:
>
sudo
zypper in iw
Find your device name:
>
sudo
iw dev phy#0 Interface wlan2 ifindex 3 wdev 0x1 addr 9c:ef:d5:fe:01:7c ssid accesspoint type managed channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz txpower 20.00 dBm
In this example, the device name to use for querying WoWLAN support is
phy#0
. This example shows that it is not supported:
>
sudo
iw phy#0 wowlan show command failed: Operation not supported (-95)
This example shows an interface that supports WoWLAN, but is not enabled:
>
sudo
iw phy#0 wowlan show WoWLAN is disabled
Enable it:
>
sudo
iw phy#0 wowlan enable magic-packet WoWLAN is enabled: * wake up on magic packet
17.5.4 Installing and testing WOL #
To use WOL, install the wol package on the client and sending machines:
>
sudo
zypper in wol
Install wol-udev-rules on your client machines. This package installs a udev rule that enables WOL automatically at start-up.
Get the MAC address of the network interface on the client machine:
>
sudo
ip addr show eth0|grep ether link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff
In the example output, 7c:ef:a5:fe:06:7c
is the MAC
address.
Shut down your client machine, and send it a wakeup signal from another computer on the same subnet:
>
wol 7c:ef:a5:fe:06:7c
If your target machine and second device are on the same network but in different subnets, specify the broadcast address for your target machine:
>
wol -i 192.168.0.63 7c:ef:a5:fe:06:7c
Because WOL relies on broadcast domains, the sending machine must be on the same network, though it can be in a different network segment.
It is possible to send the magic packet from a different network. One way is with port forwarding, if your router supports port forwarding to a broadcast address. A more secure method is to connect to a host inside your network via SSH, and send the magic packet from there.