13 Preparing network boot environment #

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.

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.

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:

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.

To install a TFTP server, use the following procedure:

SUSE Linux Enterprise Desktop provides the required files for booting via PXE on BIOS or UEFI machines. The following hardware architectures are supported:

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 Desktop 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 Desktop to the /srv/tftpboot directory.

Tip: Serving different architectures

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.

Note: Existing /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.

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 12, 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 13.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 3.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.

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 Desktop 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 3.3.3, “Specifying the installation source” for further information about the install parameter.

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.

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

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

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.