Setting Up a PXE Boot Server on SUSE Linux Enterprise Server for SAP applications 16.0
- WHAT?
Set up a PXE boot server with support for UEFI Secure Boot and the Agama installer.
- WHY?
Automate and streamline the installation of multiple SUSE Linux Enterprise Server for SAP applications 16.0 systems over the network.
- EFFORT
For a system or network administrator, it typically takes 30 to 45 minutes to read and understand this article.
- GOAL
A functioning PXE server that can boot multiple architectures into the Agama installer.
- REQUIREMENTS
A SUSE Linux Enterprise Server for SAP applications 16.0 system with administrative privileges
Internet connection to fetch ISO images
Static IP configuration for the PXE server
1 Overview of PXE booting with SUSE Linux Enterprise Server for SAP applications 16.0 #
PXE booting enables machines to boot over the network into an installation or runtime environment without local storage. This section explains how PXE works in SUSE Linux Enterprise Server for SAP applications 16.0 Agama and live installer images with a focus on GRUB 2.
1.1 What is PXE booting? #
PXE (Preboot Execution Environment) is a method that allows systems to retrieve bootloaders and OS installers from a network server using DHCP and TFTP or HTTP. It is widely used for provisioning machines without physical media or preinstalled operating systems.
1.2 Benefits of PXE booting #
PXE booting simplifies provisioning by removing the need for local installation media or manual setup. It enables:
Unattended installation of many systems over the network
Centralized management of installer versions and boot configurations
Support for diverse architectures and firmware types, including UEFI Secure Boot
Dynamic selection of installers or installation parameters using GRUB 2 menus
1.3 How PXE booting works in SUSE Linux Enterprise Server for SAP applications 16.0 #
PXE booting in SUSE Linux Enterprise Server for SAP applications 16.0 uses GRUB 2 as the bootloader and the Agama installer as the installation interface. Boot loaders and installer files are provided over the network using HTTP or TFTP, with GRUB 2 fetching the kernel, initrd and live image. PXE clients can use a variety of firmware (including the most common ones such as BIOS or UEFI), bootloader executable or image formats, as required by their architectures such as AMD64/Intel 64, AArch64, ppc64le and s390x. In addition, they must work in both IPv4 and IPv6 networks.
The bootloader passes kernel parameters such as root=live: to load the
squashfs-based root file system from a live ISO image, starting the Agama interface either
locally or as a Web service for a remote Web UI.
1.3.1 Backward compatibility with SLES for SAP 15.x #
The information in this article applies primarily to SUSE Linux Enterprise Server for SAP applications 16.0 and later. It focuses on PXE booting workflows that integrate with the Agama installer and rely on live installation images. In the context and scope of this article, SLES for SAP 16.0 and later versions differ from SLES for SAP 15.x in the following ways:
- Installer
Uses
dracutand Agama instead oflinuxrcand YaST.- DHCP server
Use of ISC DHCP is discontinued (EOL 2022). For a DHCP server, use either Kea or dnsmasq instead.
- Boot parameters
Uses
root=live:parameter to load the agama installer image and the optionalinst.install_url=for the non-default installation repository, instead of theinstall=parameter.
The bootloader choice (GRUB 2, pxelinux, etc.) remains flexible and is not version-dependent.
1.3.2 Different possible setups and steps #
This article consists of mandatory setup steps and optional or alternative configurations. Follow only the sections relevant to your deployment and skip any alternatives that do not apply to your deployment.
- Mandatory
Tasks like installing components, preparing the installer image, configuring GRUB 2, and validating the server must be completed in all setups.
- File delivery method
An HTTP server (recommended with Agama) like
nginxand/or a TFTP server liketftpordnsmasq.- DHCP server
Choose either Kea or dnsmasq.
Note: Limitations and features of your chosen methodUse Kea—the new DHCP server from ISC—as a modern replacement for ISC DHCP. For more information on Kea, refer to https://www.isc.org/kea/. For the ISC DHCP EOL notice, see https://www.isc.org/dhcp/. Kea is a DHCP server and requires separate TFTP server software. The Kea DHCP server supports options for TFTP/PXE boot over IPv4 and IPv6 as well as for HTTP boot via IPv4. The HTTP boot via IPv6 requires, that the DHCPv6 server can send the
Vendor Class Option(seeRFC3315, Section 22.16), supposed to be used “by a client to identify the vendor,” back to the client and is currently not supported.dnsmasq as a combination of a DNS server, a DHCP server, and a TFTP server. You can use it to serve the bootloader, kernel, initrd (and other files) over TFTP. For more information on dnsmasq, refer to https://thekelleys.org.uk/dnsmasq/doc.html. The dnsmasq DHCP server supports options for TFTP/PXE boot over IPv4 and IPv6 as well as for HTTP boot via IPv4. The HTTP boot via IPv6 requires that the DHCPv6 server can send the
Vendor Class Option(seeRFC3315, Section 22.16), supposed to be used “by a client to identify the vendor,” back to the client and is currently not supported.
2 Preparing the network for PXE boot services #
This module describes the network infrastructure requirements for deploying PXE boot services on SUSE Linux Enterprise Server for SAP applications 16.0.
2.1 Introduction #
A PXE server comprises three servers: a DHCP server providing the address and boot file
(bootloader) location and a TFTP and/or HTTP server to retrieve the files.
In addition, there might be a DNS server, an NTP server and a router with IPv6
support—usually they are separate from the PXE server in a production network. A PXE
server running SUSE Linux Enterprise Server for SAP applications 16.0 may also need a specific network interface setup,
certain persistent rules added to the firewall, and some permissions in
SELinux. This section illustrates a sample network with suitable IP
ranges, and the necessary rules for firewall and SELinux.
2.2 Assumptions and sample network configuration #
In this article, we assume the following:
The PXE server is running on the
eno1network interface with the following network configuration:Table 1: Sample PXE network configuration #IPv4 IPv6 DNS Name PXE Network 192.168.1.0/24 2001:db8:0:1::/64 example.net PXE Server 192.168.1.200 2001:db8:0:1::200 pxe.example.net PXE Gateway 192.168.1.1 2001:db8:0:1::1 DNS Server 192.168.1.200 2001:db8:0:1::200 NTP Server 192.168.1.1 2001:db8:0:1::1 By default, the router, NTP and DNS servers are external and running on another machine. This article provides some hints, but does not cover their complete configuration.
2.3 Configure network interface, firewall and SELinux for PXE services #
Configure the network interface and firewall to allow network services required by the PXE
server. Adjust SELinux settings to enable installation testing and
define persistent local policies.
Verify and assign the PXE network interface to the appropriate firewalld zone.
Check the currently active zones and their assigned interfaces:
>sudofirewall-cmd --get-active-zonesIf
eno1is not assigned to thepubliczone, assign it:>sudofirewall-cmd --zone=public --change-interface=eno1Make the interface assignment persistent across reboots:
>sudofirewall-cmd --permanent --zone=public --add-interface=eno1
Configure the firewall for DNS service access.
Allow DNS service for the current session:
>sudofirewall-cmd --zone=public --add-service=dnsMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=dns
Configure the firewall for NTP service access.
Allow NTP service for the current session:
>sudofirewall-cmd --zone=public --add-service=ntpMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=ntp
Configure the firewall for DHCP (IPv4) service access.
Allow DHCP service for the current session:
>sudofirewall-cmd --zone=public --add-service=dhcpMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=dhcp
Configure the firewall for DHCPv6 service access.
Allow DHCPv6 service for the current session:
>sudofirewall-cmd --zone=public --add-service=dhcpv6Make the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=dhcpv6
Configure the firewall for TFTP service access.
Allow TFTP service for the current session:
>sudofirewall-cmd --zone=public --add-service=tftpMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=tftp
Configure the firewall for HTTP service access.
Allow HTTP service for the current session:
>sudofirewall-cmd --zone=public --add-service=httpMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=http
Configure the firewall for HTTPS service access.
Allow HTTPS service for the current session:
>sudofirewall-cmd --zone=public --add-service=httpsMake the change persistent:
>sudofirewall-cmd --permanent --zone=public --add-service=https
Temporarily disable
SELinuxfor setup testing.Set
SELinuxto permissive mode:>sudosetenforce 0Check
SELinuxstatus:>sudosestatus
Generate and install local
SELinuxpolicy modules for PXE-related services.Create and install a module for
nginx:>sudoif test `ausearch -c 'nginx' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'nginx' --raw | audit2allow -a -M local-nginx>sudosemodule -i local-nginx.pp>sudofiCreate and install a module for
dnsmasq:>sudoif test `ausearch -c 'dnsmasq' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'dnsmasq' --raw | audit2allow -a -M local-dnsmasq>sudosemodule -i local-dnsmasq.pp>sudofiCreate and install a module for
in.tftpd:>sudoif test `ausearch -c 'in.tftpd' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'in.tftpd' --raw | audit2allow -a -M local-tftpd>sudosemodule -i local-tftpd.pp>sudofi
Reenable
SELinuxenforcement mode.Set
SELinuxto enforcing mode:>sudosetenforce 1Verify
SELinuxstatus:>sudosestatus
2.4 Summary #
This procedure ensured that the PXE server's network interface, firewall, and
SELinux policy were correctly configured for secure and functional
operation.
Verified and assigned the PXE-serving interface (
eno1in this example) to thepublicfirewalld zone.Opened the required firewall services for PXE operation, including
dns,ntp,dhcp,dhcpv6,tftp,http, andhttps.Temporarily set
SELinuxtopermissivemode to facilitate service testing and log AVC denials.Used
ausearchandaudit2allowto generate and install custom SELinux policy modules for services such asnginx,dnsmasq, andin.tftpd.Restored
SELinuxtoenforcingmode to secure the system for production use.
With these steps complete, the PXE server is securely configured and ready to serve client machines over the network using either IPv4 or IPv6.
3 Installing the required PXE server components #
This section explains how to install the necessary packages to support PXE booting in SUSE Linux Enterprise Server for SAP applications 16.0, including GRUB 2, DHCP, TFTP and/or HTTP components.
3.1 Introduction #
To configure a PXE boot server on SUSE Linux Enterprise Server for SAP applications 16.0, you need to install several services and tools. Depending on your setup, you may need the following:
The dnsmasq package provides a combination of a DNS server, a TFTP server and a DHCP server (DHCPv4 and DHCPv6) with limited IPv6 router advertisement (RA) support. It offers the following:
dnsmasq DHCP server: Supports conditional delivery of DHCP options depending on request and client architecture for:
PXE boot requests using DHCPv4 and DHCPv6
HTTP boot requests using DHCPv4
Note: Limitations of dnsmasq for HTTP boot over DHCPv6Currently, dnsmasq does not support sending the required
vendor-classDHCPv6 option.
dnsmasq TFTP server: Delivers bootloader files, kernel and initrd over TFTP during PXE boot.
dnsmasq DNS server: Provides recursive resolution of domain names and IP addresses for client firmware and
/etc/resolv.confin the Installer/OS.dnsmasq IPv6 RA: Supports sending IPv6 RA when the PXE server is also acting as a router (configurability limited to a “common RA pattern”).
The kea package is a DHCP server and a successor of the ISC DHCP server. It supports conditional delivery of DHCP options depending on request and client architecture for:
PXE boot requests using DHCPv4 and DHCPv6
HTTP boot requests using DHCPv4
Note: Limitations of Kea for HTTP Boot over DHCPv6Currently, Kea does not support sending the required
vendor-classDHCPv6 option. For more information, see https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#id4.
A TFTP server delivers the bootloader files, kernel and initrd over TFTP, while PXE boot with kea is provided by the tftp package and not required for HTTP Boot. If you are using dnsmasq, you do not need the tftp package.
A Web server such as the nginx package to serve installer images over HTTP.
Note: Necessity for HTTP serversAn HTTP/HTTPS server like nginx is almost always required. Its use extends beyond just HTTP Boot. In particular, you may need it in the following scenarios:
It is a basic requirement for HTTP Boot.
It is recommended for providing the
squashfs.img. You can useroot=live:tftp://.../squashfs.imgin the boot command line.It is also recommended for providing RPMs to Agama in the
inst.install_url=http://.../install/boot command-line parameter on aSLES-16.0-Full-*.inline.iso, along with installation profiles and other files for unattended installation.
The GRUB 2 bootloader packages provide network boot for supported architectures and methods. For example, the AMD64/Intel 64 architecture offers two methods for network boot: BIOS and UEFI. Additionally, UEFI generally supports PXE (TFTP) and HTTP Boot. Other bootloaders, such as pxelinux, do not support UEFI and HTTP Boot.
Optionally, a router advertisement daemon for IPv6, such as the radvd package. It is required on SLES for SAP if it is also acting as a router for an installer network to perform the following:
Configure routing on a network for PXE or HTTP Boot clients.
Enable DHCPv6 use on a network for PXE or HTTP Boot clients.
3.2 Requirements #
A system running SUSE Linux Enterprise Server for SAP applications 16.0 with administrative privileges, registered to the SUSE Customer Center and configured with access to the appropriate online repositories using SUSEConnect.
Enabled SLE modules: Server Applications Module, Legacy Module and Base System Module.
Access to the SLE module repositories for network services and bootloaders.
A working internet connection to fetch packages.
3.3 Installing the packages #
Use the following steps to install the core packages required for the PXE boot server.
Install the GRUB 2 boot loader and the nginx HTTP server as common requirements.
>sudozypper install grub2 nginxRun any of the following commands to install the essential packages for your approach:
kea for the DHCP server, tftp for the TFTP server
>sudozypper install kea tftpdnsmasq as the common provider for DHCP, DNS, and TFTP servers
>sudozypper install dnsmasq
Note: Limitations of DHCP servers provided by Kea and dnsmasqHTTP boot over IPv6 is currently not supported by DHCP servers provided by the kea and dnsmasq packages. It does not support sending a
vendor-classoption back to the HTTP client, as required by the UEFI specification.Optionally, install additional architecture-specific GRUB 2 targets if you plan to support other platforms.
For AMD64/Intel 64 architecture:
>sudozypper install grub2-x86_64-efi grub2-i386-pcFor AArch64 architecture:
>sudozypper install grub2-aarch64-efiFor ppc64le architecture:
>sudozypper install grub2-ppc64le-ieee1275
Note: How the PXE server delivers GRUB 2 packages to clients that are different from the server machine's architectureThe GRUB 2 architecture-specific noarch.rpm packages are included in the
noarchsubdirectory of the installation media/repository, regardless of the architecture of the machine on which the PXE server is set up. That is, you can install grub2-arm64-efi and grub2-powerpc-ieee1275 packages in a PXE server running on an AMD64/Intel 64 machine, in order to support clients with other architectures.Optionally, you may install the shim package if you need UEFI Secure Boot for AMD64/Intel 64 or AArch64, but do not want to use the files from the installation media ISO.
>sudozypper install shimOptionally, install the router advertisement daemon radvd if you want to use the PXE server as a router (not recommended for production networks).
>sudozypper install radvdInstall the rsync utility to conveniently copy or sync the ISO and directory tree.
>sudozypper install rsyncEnsure the services are installed but not yet started. Configuration will be covered in later sections.
4 Creating GRUB 2 NetBoot directories for PXE server #
This section explains creating GRUB 2 NetBoot directories for PXE servers using
grub2-mknetdir, which generates architecture-specific directories for
AMD64/Intel 64 (UEFI and BIOS), AArch64, and ppc64le systems. For UEFI Secure Boot support,
administrators must copy signed EFI files from installation media or use the
shim package to replace the default unsigned bootloader files.
4.1 Introduction #
This section describes how to set up GRUB 2 NetBoot directories for PXE server deployment
across multiple architectures. The grub2-mknetdir command creates
architecture-specific directories under /srv/tftpboot/boot/grub2/ for
different platforms. For example, AMD64/Intel 64 systems generate both UEFI
(x86_64-efi) and legacy BIOS (i386-pc) directories,
while AArch64 and ppc64le systems create their respective UEFI directories
(arm64-efi and powerpc-ieee1275).
For UEFI Secure Boot support, which is not provided by the default unsigned
core.efi files, administrators can either copy signed EFI files from
installation media or install the shim package and manually copy the
required bootloader files (shim.efi, grub.efi,
MokManager.efi) to the appropriate architecture directories, ensuring
proper symbolic link resolution to keep all files within the TFTP root directory.
4.2 Requirements #
Ensure that you have installed the following packages: grub2, tftp, and any other architecture-specific GRUB 2 package such as grub2-x86_64-efi and grub2-i386-pc.
Ensure that you have either the installation media (ISO) available for mounting, or the shim package installed on the system. You can download the installation media (ISO) for your target architecture from the SUSE Customer Center.
4.3 Preparing NetBoot directories and UEFI Secure Boot #
This procedure creates the required GRUB 2 directory structure for PXE network booting and optionally configures UEFI Secure Boot support across multiple architectures.
Create a GRUB 2 NetBoot directory structure.
>sudogrub2-mknetdir --net-directory=/srv/tftpboot --subdir=/boot/grub2This creates architecture-specific directories:
AMD64/Intel 64:
/srv/tftpboot/boot/grub2/x86_64-efiand/srv/tftpboot/boot/grub2/i386-pcAArch64:
/srv/tftpboot/boot/grub2/arm64-efippc64le:
/srv/tftpboot/boot/grub2/powerpc-ieee1275
WarningDo not manually overwrite the
grub.cfgfile created bygrub2-mknetdir.Copy other architecture-independent directories, such as
fonts/andlocale/that are available under the/srv/tftpboot/boot/grub2/directory to the TFTP server.You can use the
/srv/tftpboot/boot/grub2/ARCH-efi/core.efifile installed by thegrub2-mknetdircommand for AMD64/Intel 64 or AArch64 architectures for UEFI PXE as well. However, they are not signed and do not support UEFI Secure Boot. To optionally enable UEFI Secure Boot for the supported AMD64/Intel 64 and AArch64 architectures, perform any of the following steps:Copy the necessary files from the installation media ISO:
Mount the ISO image.
>sudomount -o loop /PATH/TO/SLES.ISO /mntCopy EFI files.
>sudocp -v /mnt/EFI/BOOT/*.efi /srv/tftpboot/boot/grub2/ARCH-efi/1Replace
ARCH-efiwithx86_64-efiorarm64-efi—the supported architectures for UEFI Secure Boot.Unmount the installation media ISO.
>sudoumount /mnt
Use the shim package if you do not want to use the files from the installation media ISO:
If not already installed, install the shim package.
>sudozypper install shimCopy the signed bootloader files for the necessary architecture:
Copy the
shim.efifile.For AMD64/Intel 64 architecture:
>sudocp -v -p -L /usr/share/efi/x86_64/shim.efi /srv/tftpboot/boot/grub2/x86_64-efi/bootx64.efiFor AArch64 architecture:
>sudocp -v -p -L /usr/share/efi/aarch64/shim.efi /srv/tftpboot/boot/grub2/arm64-efi/bootaa64.efi
Copy the
grub.efifile.For AMD64/Intel 64 architecture:
>sudocp -v -p -L /usr/share/efi/x86_64/grub.efi /srv/tftpboot/boot/grub2/x86_64-efi/For AArch64 architecture:
>sudocp -v -p -L /usr/share/efi/aarch64/grub.efi /srv/tftpboot/boot/grub2/arm64-efi/
Copy the
MokManager.efifile.For AMD64/Intel 64 architecture:
>sudocp -v -p -L /usr/share/efi/x86_64/MokManager.efi /srv/tftpboot/boot/grub2/x86_64-efi/For AArch64 architecture:
>sudocp -v -p -L /usr/share/efi/aarch64/MokManager.efi /srv/tftpboot/boot/grub2/arm64-efi/
NoteThe
-Lflag resolves symbolic links to ensure files stay within TFTP root.
5 Preparing the installer image content #
This section describes how to extract and organize installer files from SUSE Linux Enterprise Server for SAP applications
16.0 installation media for PXE boot environments. It covers both
.install.iso images and RPM packages, with specific instructions for
different architectures and installation types.
5.1 Introduction #
SUSE Linux Enterprise Server for SAP applications 16.0 provides installer files in multiple formats to support
different PXE boot scenarios. The Agama installer requires three essential files: the
kernel image (linux), the initial RAM disk
(initrd), and the compressed root file system
(squashfs.img). These files must be extracted from the installation
media and organized in a directory structure accessible via TFTP and HTTP.
This section covers preparation methods for both .install.iso images and
RPM packages, ensuring compatibility with various architectures and installation types
supported by SUSE Linux Enterprise Server for SAP applications 16.0.
5.2 Requirements #
SUSE Linux Enterprise Server for SAP applications 16.0 installation media, as available in SUSE Customer Center. Choose from:
Online ISO: Installer-only for network installations (
SLES-16.0-Online-ARCH-BUILD.install.iso)Full ISO: Installer with installation repository (
SLES-16.0-Full-ARCH-BUILD.install.iso)RPM packages: tftpboot-agama-installer-SUSE_SLE_16_PXE-ARCH
A temporary mount point, such as
/mnt.Sufficient disk space under
/srv/tftpbootand/srv/installfor your chosen installation method.Administrative privileges to create directories and copy files.
5.3 Preparing installer files from ISO images #
ISO images provide a straightforward method for extracting installer files. The following procedures cover both Online and Full ISO types for different architectures.
5.3.1 Using Online ISO images #
Online ISO images contain only the installer components, requiring network access
to installation repositories during system installation. This corresponds with the
SLES-16.0 Online Installation boot menu entry in GRUB.
Create the directory structure for installer files:
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH/Mount the Online ISO image:
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Online-ARCH-BUILD.install.iso /mntCopy the kernel and initrd files:
>sudocp /mnt/boot/ARCH/loader/linux /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudocp /mnt/boot/ARCH/loader/initrd /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copy the compressed root file system:
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ARCH/Unmount the ISO image:
>sudoumount /mnt
Create the directory structure:
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Mount the ISO image:
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Online-ppc64le-BUILD.install.iso /mntCopy the kernel and initrd files (note the different path structure for ppc64le):
>sudocp /mnt/boot/ppc64le/linux /srv/tftpboot/boot/images/SLES-16.0/ppc64le/>sudocp /mnt/boot/ppc64le/initrd /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Copy the compressed root file system:
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Unmount the ISO image:
>sudoumount /mnt
5.3.2 Using Full ISO images #
Full ISO images include both the installer and installation repositories, enabling local
installations without external network dependencies.
It corresponds with the SLES-16.0 Local Installation boot menu entry
in grub with the additional
inst.install_url=http://pxe.example.net/install/SLES-16.0/${arch}
parameter.
Create directories for both installer files and the installation repository:
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudomkdir -p /srv/install/SLES-16.0Mount the Full ISO image:
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Full-ARCH-BUILD.install.iso /mntCopy the kernel and initrd files (adjust paths for ppc64le as shown in previous procedures):
>sudocp /mnt/boot/ARCH/loader/linux /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudocp /mnt/boot/ARCH/loader/initrd /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copy the compressed root file system:
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copy the installation repository for local HTTP server access:
>sudorsync -avP /mnt/install/ /srv/install/SLES-16.0/ARCH/Unmount the ISO image:
>sudoumount /mnt
5.4 Preparing installer files from RPM packages #
RPM packages provide an alternative method for obtaining Online Installer files.
Install the required packages:
>sudozypper in tftpboot-agama-installer-SUSE_SLE_16-ARCHCopy the linux,initrd,squashfs.img into tftpboot:
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH>sudocd /srv/tftpboot/boot/images/SLES-16.0/ARCH>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/linux .>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/initrd .>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/squashfs.img .
5.5 Recommended directory structure #
Organize the extracted files according to the following directory layout to ensure consistency and ease of maintenance. This structure supports multiple architectures and installation types.
/srv/tftpboot/ ├── boot/ │ ├── grub2/ │ │ ├── x86_64-efi/ │ │ │ ├── bootx64.efi │ │ │ └── grub.cfg │ │ ├── i386-pc/ │ │ │ └── core.0 │ │ ├── arm64-efi/ │ │ │ └── bootaa64.efi │ │ └── powerpc-ieee1275/ │ │ └── core.elf │ └── images/ │ └── SLES-16.0/ │ ├── x86_64/ │ │ ├── linux 1 │ │ ├── initrd 2 │ │ └── squashfs.img 3 │ ├── aarch64/ │ └── ppc64le/ /srv/install/ └── SLES-16.0/ ├── x86_64/ 4 ├── aarch64/ └── ppc64le/
5.6 Verifying the installation #
After extracting and organizing the installer files, verify that all required components are present and accessible.
Check that essential files are present:
>ls -la /srv/tftpboot/boot/images/SLES-16.0/ARCH/*Ensure proper file permissions:
>sudofind /srv/tftpboot/boot/images/ -type d -exec chmod 0755 {} \;>sudofind /srv/tftpboot/boot/images/ -type f -exec chmod 0644 {} \;
Ensure that all extracted files are readable by the TFTP and HTTP services. The files will be accessed by PXE clients during the boot process, so proper permissions and service configuration are essential for successful deployments.
5.7 Next steps #
With the installer files properly prepared and organized, you can proceed to:
Configure GRUB 2 for PXE boot with menu entries referencing these files
Set up HTTP and TFTP services to serve the extracted content
Configure DHCP to direct PXE clients to the appropriate bootloaders
The extracted files will be referenced in GRUB 2 configuration using paths such as
root=live:http://pxe.example.net/boot/images/SLES-16.0/ARCH/squashfs.img.
6 Configuring GRUB 2 for PXE boot #
This section describes how to configure the GRUB 2 bootloader for PXE-based booting on SUSE Linux Enterprise Server for SAP applications 16.0. It covers creating the network boot directory structure, setting up architecture-specific bootloaders, and implementing a flexible configuration system that supports multiple architectures and installation scenarios.
6.1 Introduction #
GRUB 2 serves as the network bootloader for PXE clients, loading kernel and initrd files to start the Agama installer. This section demonstrates how to create a sophisticated GRUB 2 configuration that automatically detects client architecture, manages network interface selection, and provides a unified boot menu supporting multiple installation types and target architectures.
The configuration approach uses a modular design with separate files for architecture detection, variable definitions, and boot menu entries. This enables support for machine-specific configurations and automated installation profiles while maintaining consistency across different hardware platforms.
6.2 Requirements #
Ensure that the GRUB 2 network boot directory structure is in place, as described in the previous sections.
Ensure that the installer files are properly organized as described in the previous sections.
GRUB 2 packages for all target architectures must be installed: grub2-x86_64-efi, grub2-i386-pc, grub2-aarch64-efi, and grub2-ppc64le-ieee1275
The shim package for UEFI Secure Boot support (optional).
Administrative access to
/srv/tftpbootor equivalent PXE root.
6.3 Creating the GRUB 2 configuration #
The GRUB 2 configuration file handles three main tasks: detecting the client's architecture, managing network interfaces and loading other configuration files. This modular approach provides flexibility for different deployment scenarios.
grub.cfg file #Create the main GRUB 2 configuration file at
/srv/tftpboot/boot/grub2/grub.cfg:>sudocat > /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Architecture detection and mapping if [ "$grub_cpu" == "i386" ]; then set arch='x86_64' elif [ "$grub_cpu" == "x86_64" ]; then set arch='x86_64' elif [ "$grub_cpu" == "arm64" ]; then set arch='aarch64' elif [ "$grub_cpu" == "powerpc" ]; then set arch='ppc64le' fi if [ "X$arch" == "X" ]; then echo "ERROR: No architecture found for ${grub_cpu}" exit else echo "Running on $arch CPU architecture" fi export arch # Network interface configuration for PXE-selected NIC # - dracut based images on SLE-16: set ipcfg="ifname=pxe0:${net_default_mac} ip=pxe0:dhcp" export ipcfg # - linuxrc installer on SLE-15: set ifcfg="ifcfg=${net_default_mac}=dhcp" export ifcfg # Define typical serial console kernel parameter #set sconsole="console=tty0 console=ttyS0,115200n8" #export sconsole # Load machine-specific configuration if available if [ -s "${config}/${net_default_mac}/grub.cfg" ]; then ## Source a host specific configuration of grub menu: source "${config}/${net_default_mac}/grub.cfg" else ## Source default grub boot menu: source "${prefix}/menu.cfg" fi EOF
- Architecture detection
Maps GRUB 2 CPU types to distribution architectures, enabling unified menu entries that work across different hardware platforms
- Network interface management
Defines an
${ipcfg}variable using the grub2 variable${net_default_mac}to activate dhcp only on the PXE boot interface namedpxe0, avoiding network probing issues on multi-interface systems.- Utility definitions
Defines a typical
${sconsole}variable with serial console parameters.- Machine-specific configuration
Loads optional per-machine configuration files based on MAC address, enabling customized per-machine boot parameters and automated installation profiles
6.5 Machine-specific configurations #
For advanced deployments, you can create machine-specific configuration files that override default settings or provide automated installation parameters.
Create a directory for machine-specific configurations:
>sudomkdir -p /srv/tftpboot/boot/configFor a machine with a MAC address
aa:bb:cc:dd:ee:ff, create a specific configuration:>sudomkdir -p /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ffCreate the machine-specific
grub.cfg:>sudocat > /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ff/grub.cfg << 'EOF'# Machine-specific configuration for aa:bb:cc:dd:ee:ff set default='SLES-16.0 Full Installation' # Activate the menu-entry after 5sec timeout set timeout=5 # Use know predictable network interface name set ipcfg="ip=eno1:dhcp" # Set the autoinstall variable for this machine set autoinstall="inst.auto=http://pxe.example.net/install/profiles/aa:bb:cc:dd:ee:ff/sles16.json" export autoinstall # Load the default menu source "/boot/grub2/menu.cfg" EOFAlternatively, provide own menu entry in the host-specific
grub.cfg(e.g. generated for a specific boot attempt):>sudocat > /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ff/grub.cfg << 'EOF'set default='SLES-16.0 Auto-Installation' set timeout=5 menuentry 'SLES-16.0 Auto-Installation' { linux /boot/images/SLES-16.0/${arch}/linux showopts root=live:http://pxe.example.net/boot/images/SLES-16.0/${arch}/squashfs.img inst.install_url=http://pxe.example.net/install/SLES-16.0/${arch} inst.auto=http://pxe.example.net/install/profiles/${net_default_mac}/sles16.json ip=eno1:dhcp initrd /boot/images/SLES-16.0/${arch}/initrd } EOF
defaultSpecifies which menu entry to boot automatically
timeoutSets the boot timeout in seconds
ipcfgOverrides network interface configuration for specific hardware
autoinstallProvides machine-specific automated installation profile URLs
6.6 Verifying GRUB 2 configuration #
After creating the configuration files, verify that the setup is correct, and all required files are in place.
Check the GRUB 2 directory structure:
>find /srv/tftpboot/boot/grub2 -type f -name "*.cfg" -o -name "*.efi" -o -name "core.*"Verify the configuration file syntax by testing with GRUB 2 tools:
>grub2-script-check /srv/tftpboot/boot/grub2/grub.cfg>grub2-script-check /srv/tftpboot/boot/grub2/menu.cfgEnsure proper file permissions:
>sudochmod -R 644 /srv/tftpboot/boot/grub2/*.cfg>sudofind /srv/tftpboot/boot/grub2 -type d -exec chmod 0755 {} \;
Test the GRUB 2 configuration with actual PXE clients to ensure proper architecture
detection and menu functionality. The ${net_default_mac} variable is
only available during actual network boot scenarios.
6.7 Troubleshooting GRUB 2 configuration #
Common issues and their solutions when working with GRUB 2 PXE configurations. Each problem includes diagnostic steps and specific commands to resolve the issue.
6.7.1 Architecture detection fails #
When GRUB 2 fails to detect the correct architecture, clients may boot with incorrect binaries or fail to load altogether.
Add debug output to the GRUB 2 configuration to see detected values:
>sudocat >> /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Debug architecture detection echo "Detected grub_cpu: ${grub_cpu}" echo "Mapped arch: ${arch}" sleep 3 EOFTest the configuration syntax:
>grub2-script-check /srv/tftpboot/boot/grub2/grub.cfgIf architecture mapping is incomplete, extend the detection logic:
>sudosed -i '/elif \[ "$grub_cpu" == "powerpc" \]/a\\nelif [ "$grub_cpu" == "riscv64" ]; then\n set arch='\''riscv64'\''\\' /srv/tftpboot/boot/grub2/grub.cfgVerify the architecture-specific directories exist:
>ls -la /srv/tftpboot/boot/grub2/
6.7.2 Network interface not found #
Some firmware implementations may not set the ${net_default_mac}
variable correctly, causing network configuration failures.
Add debug output to check network variables:
>sudosed -i '/set ipcfg=/i\\necho "Default MAC: ${net_default_mac}"\necho "Network variables set"\nsleep 2' /srv/tftpboot/boot/grub2/grub.cfgCreate a fallback network configuration:
>sudocat >> /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Fallback network configuration if net_default_mac is empty if [ "X${net_default_mac}" == "X" ]; then set ipcfg="ip=dhcp" set ifcfg="ifcfg=*=dhcp" echo "WARNING: Using fallback network configuration" sleep 2 fi EOFTest network configuration with a specific interface:
>sudoecho 'set ipcfg="ip=eno1:dhcp"' > /srv/tftpboot/boot/config/test-network.cfgVerify network interface names on the target system:
>ip link show
6.7.3 File paths not found #
Incorrect file paths prevent GRUB 2 from loading kernel and initrd files, causing boot failures.
Check if the installer files exist in the expected locations:
>find /srv/tftpboot/boot/images -name "linux" -o -name "initrd" -o -name "squashfs.img"Verify TFTP access to boot files:
>tftp localhost -c get /boot/grub2/grub.cfg /tmp/test-grub.cfgTest HTTP access to installer files:
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/linuxCheck file permissions and ownership:
>ls -la /srv/tftpboot/boot/images/SLES-16.0/*/Fix permissions if needed:
>sudochmod -R 644 /srv/tftpboot/boot/images/>sudofind /srv/tftpboot/boot/images/ -type d -exec chmod 755 {} \;Verify symbolic links are not broken:
>find /srv/tftpboot/boot/images/ -type l -exec ls -la {} \;
6.7.4 EFI boot failures #
EFI and Secure Boot issues can prevent proper bootloader initialization or cause authentication failures.
Verify Secure Boot files are present:
>ls -la /srv/tftpboot/boot/grub2/x86_64-efi/*.efiCheck that shim (bootx64.efi or shim.efi), grub.efi and MokManager.efi files are properly copied:
>file /srv/tftpboot/boot/grub2/x86_64-efi/bootx64.efiVerify EFI file integrity:
>sha256sum /srv/tftpboot/boot/grub2/x86_64-efi/*.efiTest if files are accessible via TFTP:
>tftp localhost -c get /boot/grub2/x86_64-efi/bootx64.efi /tmp/test-shim.efiFor aarch64 systems, verify ARM64 EFI files:
>ls -la /srv/tftpboot/boot/grub2/arm64-efi/*.efiCheck that the DHCP configuration provides the correct bootloader paths:
>grep -n "bootx64.efi\|shim.efi\|bootaa64.efi" /etc/dnsmasq.d/dhcp.conf /etc/kea/kea-dhcp?.conf /etc/dhcpd?.confIf files are missing, recopy from the ISO mounted to /mnt or from the shim package files:
>sudocp -v /mnt/EFI/BOOT/*.efi /srv/tftpboot/boot/grub2/x86_64-efi/>sudocp -pL /usr/share/efi/x86_64/*.efi /srv/tftpboot/boot/grub2/x86_64-efi/
6.7.6 Enabling detailed logging #
For persistent issues, enable comprehensive logging to capture detailed information about the boot process.
Create a debug version of the main configuration:
>sudocp /srv/tftpboot/boot/grub2/grub.cfg /srv/tftpboot/boot/grub2/grub.cfg.backupAdd comprehensive debug output:
>sudocat > /srv/tftpboot/boot/grub2/debug.cfg << 'EOF'# Debug configuration for GRUB troubleshooting set debug=all set pager=1 echo "=== GRUB Debug Information ===" echo "grub_cpu: ${grub_cpu}" echo "grub_platform: ${grub_platform}" echo "net_default_mac: ${net_default_mac}" echo "net_default_server: ${net_default_server}" echo "=============================" sleep 5 EOFInclude debug configuration in main file:
>sudosed -i '1i\source "${prefix}/debug.cfg"' /srv/tftpboot/boot/grub2/grub.cfgMonitor TFTP logs during boot attempts:
>sudo journalctl -f -u tftp.socketMonitor DHCP logs for PXE requests:
>sudo journalctl -f -u dhcpdDisable debug mode after troubleshooting:
>sudosed -i '/source "${prefix}\/debug.cfg"/d' /srv/tftpboot/boot/grub2/grub.cfg
6.8 Next steps #
With GRUB 2 properly configured, you can proceed to:
Configure HTTP and TFTP services to serve the boot files and installer content
Set up DHCP services to direct PXE clients to the appropriate bootloaders
Test the complete PXE boot process on target hardware
The flexible GRUB 2 configuration system provides a foundation for sophisticated PXE deployment scenarios, supporting multiple architectures and installation types through a unified interface.
7 Configuring TFTP for PXE booting #
This section explains how to configure TFTP services to serve GRUB 2 bootloaders and PXE
boot content for SUSE Linux Enterprise Server for SAP applications 16.0 installations. It covers the traditional
in.tftpd server and the integrated TFTP functionality provided by
dnsmasq.
7.1 Introduction #
TFTP serves bootloader files to PXE clients during the network boot process. SUSE Linux Enterprise Server for SAP applications
16.0 supports two TFTP server implementations: the traditional
in.tftpd server from the tftp package, and the
integrated TFTP functionality within dnsmasq.
7.2 Requirements #
Either the tftp package or the dnsmasq package installed
PXE boot files organized under
/srv/tftpbootAdministrative privileges to configure services
7.3 Configuring in.tftpd server #
The in.tftpd server uses the configuration file
/etc/sysconfig/tftp to define the TFTP root directory and server
options.
Optionally, enable verbose logging by setting TFTP options:
>sudosed -i 's/^TFTP_OPTIONS=.*/TFTP_OPTIONS="-v"/' /etc/sysconfig/tftpThe
-voption enables verbose logging to see the file names fetched via TFTP.Enable and start the TFTP service:
>sudosystemctl enable --now tftp.service
7.4 Configuring dnsmasq TFTP server #
dnsmasq provides a built-in TFTP server that can be enabled and
configured to use the /srv/tftpboot directory.
Create the TFTP configuration file:
>sudocat > /etc/dnsmasq.d/tftp.conf << 'EOF'enable-tftp tftp-root=/srv/tftpboot EOFEnable and start the dnsmasq service:
>sudosystemctl enable --now dnsmasq
7.5 Verifying TFTP configuration #
Test the TFTP server functionality to ensure it can serve files to PXE clients.
Create a test file:
>echo "test file" | sudo tee /srv/tftpboot/test.txtRetrieve the test file via TFTP:
>tftp localhost -c get test.txt /tmp/tftp-test.txtVerify the file was retrieved successfully:
>cat /tmp/tftp-test.txtClean up test files:
>sudorm /srv/tftpboot/test.txt /tmp/tftp-test.txt
7.6 Troubleshooting TFTP configuration #
Common issues when configuring TFTP services for PXE boot environments.
7.6.1 Service conflicts on port 69 #
Both in.tftpd and dnsmasq use UDP port 69
for TFTP services and cannot run simultaneously.
Check which services are running:
>systemctl status tftp.service dnsmasqCheck what is using port 69:
>ss -ulnp | grep :69Stop the conflicting service (example for dnsmasq):
>sudosystemctl stop dnsmasqStart your preferred TFTP service:
>sudosystemctl start tftp.service
7.6.2 TFTP directory issues #
Problems accessing the TFTP root directory can prevent file serving.
Verify the TFTP directory setting for in.tftpd:
>grep TFTP_DIRECTORY /etc/sysconfig/tftpVerify the TFTP directory setting for dnsmasq:
>grep tftp-root /etc/dnsmasq.d/tftp.confCheck if the directory exists:
>ls -la /srv/tftpboot/Create the directory if missing:
>sudomkdir -p /srv/tftpboot
7.6.3 Enabling TFTP logging #
Verbose logging helps identify file access issues with TFTP transfers.
Check the current TFTP options:
>grep TFTP_OPTIONS /etc/sysconfig/tftpEnable verbose logging:
>sudosed -i 's/^TFTP_OPTIONS=.*/TFTP_OPTIONS="-v"/' /etc/sysconfig/tftpRestart the TFTP service:
>sudosystemctl restart tftp.serviceMonitor TFTP logs:
>journalctl -u tftp.service -f
7.7 Next steps #
With TFTP configured, you can proceed to configure HTTP services for serving installer files and DHCP services for directing PXE clients to the appropriate bootloaders.
8 Configuring nginx for HTTP delivery #
This section explains how to configure nginx to serve PXE boot content over HTTP, allowing clients to load installer files like kernel, initrd, and squashfs images from a central location. HTTP delivery provides better performance than TFTP for large files and is required for SUSE Linux Enterprise Server for SAP applications 16.0 Agama installations.
8.1 Introduction #
nginx serves as the HTTP server for PXE boot environments, providing access to installer files through Web-based delivery. The HTTP server exposes the TFTP boot directory and installation repositories, enabling PXE clients to download kernel images, initrd files, and the Agama installer components over HTTP rather than the slower TFTP protocol.
8.2 Requirements #
The nginx package installed
PXE boot files organized under
/srv/tftpboot/bootInstallation repositories available under
/srv/installAdministrative privileges to modify nginx configuration
8.3 Configuring nginx for PXE boot #
The nginx configuration defines location aliases that expose the TFTP boot directory and installation repositories through HTTP URLs.
Edit the nginx configuration file:
>sudovim /etc/nginx/nginx.confConfigure the HTTP server block in the
httpsection:>sudocat > /etc/nginx/nginx.conf << 'EOF'http { include mime.types; default_type application/octet-stream; charset utf-8; sendfile on; keepalive_timeout 65; server { listen 80 default_server; listen [::]:80 default_server; location / { root /srv/www/htdocs/; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /srv/www/htdocs/; } # Expose TFTP boot directory for HTTP boot location /boot { alias /srv/tftpboot/boot; autoindex on; } # Expose installation repositories and profiles location /install { alias /srv/install; autoindex on; } } } events { worker_connections 1024; } EOFTest the nginx configuration syntax:
>sudonginx -tEnable and start the nginx service:
>sudosystemctl enable --now nginx.service
8.4 Verifying nginx configuration #
Test the HTTP server functionality to ensure it can serve PXE boot files and installation content to clients.
Test HTTP access to boot files:
>curl -I http://localhost/boot/Test access to the installation directory:
>curl -I http://localhost/install/Verify a specific installer file is accessible:
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.img
8.5 Troubleshooting nginx configuration #
Common issues when configuring nginx for PXE boot HTTP delivery.
8.5.1 Configuration syntax errors #
Incorrect nginx configuration syntax prevents the service from starting or reloading properly.
Test the configuration syntax:
>sudonginx -tCheck nginx service status if startup fails:
>systemctl status nginx.serviceView detailed error logs:
>journalctl -u nginx.service -fCheck nginx error log file:
>tail -f /var/log/nginx/error.log
8.5.2 File access and permission issues #
nginx may fail to serve files due to incorrect permissions or missing directories.
Check if the boot directory exists and is accessible:
>ls -la /srv/tftpboot/boot/Check if the install directory exists:
>ls -la /srv/install/Verify nginx can read the directories:
>sudo -u nginx ls /srv/tftpboot/boot/Create missing directories if needed:
>sudomkdir -p /srv/installSet appropriate permissions:
>sudochmod -R 755 /srv/tftpboot/boot /srv/install
8.5.3 Port binding conflicts #
nginx may fail to start if another service is using port 80.
Check what is using port 80:
>ss -tlnp | grep :80Stop conflicting services if needed:
>sudosystemctl stop apache2Start nginx service:
>sudosystemctl start nginx.serviceVerify nginx is listening on port 80:
>ss -tlnp | grep :80
8.6 Next steps #
With nginx configured for HTTP delivery, you can proceed to configure DHCP services for directing PXE clients to the appropriate bootloaders and HTTP resources.
9 Configuring a DNS server using dnsmasq #
This section explains how to configure DNS services using dnsmasq to provide host name resolution for PXE clients accessing SUSE Linux Enterprise Server for SAP applications 16.0 installation resources. DNS configuration enables clients to use host names instead of IP addresses in boot URLs and DHCP configurations.
9.1 Introduction #
DNS services enable PXE clients to resolve host names in boot URLs and installation sources. While full DNS server configuration is beyond the scope of this document, this section provides a basic DNS configuration using dnsmasq that allows clients to resolve the PXE server host name (PXE.EXAMPLE.NET) to its IP addresses.
Without DNS configuration, boot URLs must use IP addresses directly, such as
http://192.168.1.200/ or http://[2001:db8:0:1::200]/.
Some BIOS/UEFI firmware implementations do not support host names in DHCP TFTP URLs and
require IP addresses like tftp://[2001:db8:0:1::200]/.
9.2 Requirements #
The dnsmasq package installed
Static IP addresses configured for the PXE server
Administrative privileges to configure DNS services
9.3 Configuring dnsmasq DNS services #
The dnsmasq DNS configuration provides local host name resolution and uses upstream name servers for external queries.
Create the DNS configuration file for dnsmasq:
>sudocat > /etc/dnsmasq.d/dns.conf << 'EOF'# DNS configuration file for dnsmasq # Log DNS queries log-queries # DNS cache behavior cache-size=10000 local-ttl=60 neg-ttl=10 # Never forward A or AAAA queries for plain names to upstream name servers domain-needed # Add local domain to simple names in /etc/hosts and DHCP expand-hosts # Specifies DNS domain and networks including local forward and reverse declarations domain=EXAMPLE.NET,192.168.1.0/24,local domain=EXAMPLE.NET,2001:db8:0:1::/64,local EOFAdd host name entries to the system hosts file:
>sudocat >> /etc/hosts << 'EOF'192.168.1.200 PXE.EXAMPLE.NET 2001:db8:0:1::200 PXE.EXAMPLE.NET EOFTest the dnsmasq configuration:
>sudodnsmasq --testEnable and start the dnsmasq service:
>sudosystemctl enable --now dnsmasq
By default, dnsmasq uses the name servers in /etc/resolv.conf as
forwarders and provides records from /etc/hosts. This allows the PXE
server to resolve external host names while providing local resolution for PXE-related
services.
9.4 Verifying DNS configuration #
Test the DNS server functionality to ensure host name resolution works for PXE clients.
Test IPv4 host name resolution:
>nslookup PXE.EXAMPLE.NET localhostTest IPv6 host name resolution:
>nslookup PXE.EXAMPLE.NET localhost | grep 2001:db8Test reverse DNS lookup for IPv4:
>nslookup 192.168.1.200 localhostVerify external DNS forwarding still works:
>nslookup google.com localhost
9.5 Troubleshooting DNS configuration #
Common issues when configuring dnsmasq for DNS services in PXE environments.
9.5.1 Configuration and service issues #
dnsmasq may fail to start due to configuration errors or port conflicts.
Test the dnsmasq configuration syntax:
>sudodnsmasq --testCheck dnsmasq service status:
>systemctl status dnsmasqCheck what is using DNS port 53:
>ss -ulnp | grep :53View dnsmasq logs for errors:
>journalctl -u dnsmasq -fStop conflicting DNS services if needed:
>sudosystemctl stop systemd-resolved
9.5.2 Host name resolution failures #
DNS queries may fail due to incorrect configuration or missing host name entries.
Check if host name entries exist in hosts file:
>grep PXE.EXAMPLE.NET /etc/hostsVerify domain configuration in dnsmasq:
>grep domain= /etc/dnsmasq.d/dns.confTest DNS query with verbose output:
>dig @localhost PXE.EXAMPLE.NETMonitor dnsmasq query logs:
>journalctl -u dnsmasq | grep "query"Restart dnsmasq to reload the configuration:
>sudosystemctl restart dnsmasq
9.5.3 DNS forwarding problems #
External DNS queries may fail if the upstream name server configuration is incorrect.
Check the upstream name server configuration:
>cat /etc/resolv.confTest direct query to the upstream name server:
>nslookup google.com 8.8.8.8Check dnsmasq forwarding configuration:
>grep -E "server=|no-resolv" /etc/dnsmasq.d/dns.confAdd a specific upstream name server if needed:
>sudoecho "server=8.8.8.8" >> /etc/dnsmasq.d/dns.confRestart dnsmasq service:
>sudosystemctl restart dnsmasq
9.6 Next steps #
With DNS services configured, PXE clients can now resolve host names in boot URLs and installation sources. You can proceed to configure DHCP services that reference the DNS server for client configuration.
10 Configuring an NTP server using chrony #
This section explains how to configure NTP services using chrony
to provide accurate time synchronization for PXE clients during SUSE Linux Enterprise Server for SAP applications
16.0 installations. Proper time synchronization is essential for certificate
validation and system logging during network-based installations.
10.1 Introduction #
NTP services ensure accurate time synchronization across network infrastructure. For PXE boot
environments, synchronized time is crucial for certificate validation during HTTPS
connections, proper log timestamps, and coordinated system operations. This section provides
basic NTP server configuration using chrony.
10.2 Requirements #
The chrony package installed
>sudozypper install chronyNetwork connectivity to upstream NTP servers
Administrative privileges to configure NTP services
10.3 Configuring chrony NTP service #
The chrony service provides NTP functionality with automatic time
synchronization to upstream servers and local time-serving capabilities for network clients.
chrony NTP server #Enable and start the
chronyservice:>sudosystemctl enable --now chronyd.service
10.4 Verifying NTP configuration #
Test the NTP service functionality to ensure time synchronization works correctly.
Check
chronyservice status:>systemctl status chronyd.serviceView the current time synchronization status:
>chronyc trackingList configured NTP sources:
>chronyc sourcesCheck NTP server statistics:
>chronyc sourcestats
10.5 Troubleshooting NTP configuration #
Common issues when configuring chrony for NTP services in PXE
environments.
10.5.1 Service startup issues #
chrony service may fail to start due to configuration errors or
network connectivity problems.
Check
chronyservice status and logs:>systemctl status chronyd.serviceView detailed service logs:
>journalctl -u chronyd.service -fTest
chronyconfiguration:>sudochronyd -QRestart the service if needed:
>sudosystemctl restart chronyd.service
10.5.2 Time synchronization failures #
Time synchronization may fail due to network issues or incorrect server configuration.
Check the current synchronization status:
>chronyc trackingView NTP source connectivity:
>chronyc sources -vForce immediate synchronization:
>sudochronyc makestepCheck system time against hardware clock:
>timedatectl statusVerify network connectivity to NTP servers:
>chronyc activity
10.5.3 Firewall and network issues #
NTP traffic may be blocked by firewall rules, preventing time synchronization.
Check if NTP port is open in firewall:
>firewall-cmd --list-services | grep ntpAdd NTP service to firewall if needed:
>sudofirewall-cmd --permanent --add-service=ntpReload firewall configuration:
>sudofirewall-cmd --reloadTest NTP connectivity manually:
>ntpdate -q pool.ntp.orgCheck
chronyport usage:>ss -ulnp | grep :123
10.6 Next steps #
With NTP services configured, the PXE server and clients will maintain accurate time synchronization. This ensures proper certificate validation and coordinated system operations during network-based installations.
11 Configuring IPv6 router advertisement #
This section describes how to configure IPv6 router advertisement functionality to provide adequate router advertisements for PXE clients. IPv6 RA enables IPv6 routing configuration and stateful DHCPv6 address automatic configuration for SUSE Linux Enterprise Server for SAP applications 16.0 installations.
11.1 Introduction #
IPv6 router advertisement (RA) provides essential network configuration information to PXE
clients, including IPv6 routing and DHCPv6 address automatic configuration settings. This
section assumes that an IPv6 router is configured to provide adequate router advertisements
to configure IPv6 routing to the network and default route, and enable stateful DHCPv6
address automatic configuration using AdvManagedFlag on.
11.2 Requirements #
The radvd package installed
IPv6 network configuration on the server interface
Administrative privileges to configure router advertisement services
11.3 Configuring radvd for IPv6 router advertisement #
The radvd service provides IPv6 router advertisement functionality
using configuration defined in /etc/radvd.conf.
radvd IPv6 router advertisement #Configure the
radvdservice:>sudocat > /etc/radvd.conf << 'EOF'interface eno1 { # radvd options IgnoreIfMissing on; # Do not fail and exit when interface is missed AdvSendAdvert on; # Sending RAs on the interface is not disabled # Configuration settings AdvManagedFlag on; # Request IPv6 address and dns options via DHCPv6 AdvOtherConfigFlag off; # Request only dns info via DHCPv6, IP via SLAAC AdvDefaultLifetime 1800; # Add default route via this router for 1800sec prefix 2001:db8:0:1::/64 # Add direct route for this local network/prefix { AdvAutonomous off; # Assign IPv6 address via SLAAC AdvValidLifetime 7200; AdvPreferredLifetime 3600; }; }; EOFEnable and start the
radvdservice:>sudosystemctl enable --now radvd
11.4 Verifying IPv6 router advertisement #
Test the IPv6 RA functionality to ensure proper configuration and operation.
Check
radvdservice status:>systemctl status radvdReview and verify IPv6 RA settings using
ravdump>radvdumpThe
radvdumputility displays IPv6 RA settings sent by the IPv6 router every few minutes.
11.5 Configuring IP forwarding for router functionality #
If the PXE server also acts as a router, IP forwarding must be enabled to allow the system to function in a router role.
Create the network configuration file:
>sudocat > /etc/sysctl.d/90-network.conf << 'EOF'# This machine is a router net.ipv4.conf.all.forwarding = 1 net.ipv6.conf.all.forwarding = 1 # Accept host autoconf on router uplink net.ipv6.conf.uplink.accept_ra = 2 EOFApply the network configuration settings:
>sudosysctl -p /etc/sysctl.d/90-network.conf
A router does not process IPv6 RAs for host automatic configuration by default. To accept
IPv6 RA on a router uplink interface, the accept_ra = 2 sysctl setting
is required. Consult the Network Configuration section in the Administration Guide for
further details on router configuration, including firewall adjustments and other required
steps.
11.6 Troubleshooting IPv6 router advertisement #
Common issues when configuring IPv6 router advertisement for PXE environments.
11.6.1 radvd service issues #
The radvd service may fail to start due to configuration errors or
interface problems.
radvd service problems #Check
radvdservice status and logs:>systemctl status radvdView detailed service logs:
>journalctl -u radvd -fTest
radvdconfiguration syntax:>sudoradvd -C /etc/radvd.confCheck if the specified interface exists:
>ip link show eno1Restart the service after fixing configuration:
>sudosystemctl restart radvd
11.6.2 IP forwarding configuration issues #
Incorrect IP forwarding settings can prevent proper router functionality.
Check current IP forwarding status:
>sysctl net.ipv4.conf.all.forwardingCheck IPv6 forwarding status:
>sysctl net.ipv6.conf.all.forwardingVerify sysctl configuration file:
>cat /etc/sysctl.d/90-network.confApply configuration if values are incorrect:
>sudosysctl -p /etc/sysctl.d/90-network.confCheck accept_ra setting on uplink interface:
>sysctl net.ipv6.conf.uplink.accept_ra
11.6.3 Router advertisement reception issues #
Clients may not receive or process IPv6 router advertisements correctly.
Monitor router advertisements using
ravdump:>radvdump -dCheck IPv6 interface configuration on clients:
>ip -6 addr showVerify IPv6 routing table on clients:
>ip -6 route showTest IPv6 connectivity to the router:
>ping6 2001:db8:0:1::1Check firewall rules for ICMPv6:
>firewall-cmd --list-protocols | grep ipv6-icmp
11.7 Next steps #
With IPv6 router advertisement configured, PXE clients can receive a proper IPv6 network configuration. This enables DHCPv6 functionality and IPv6 connectivity for network-based installations.
12 Configuring a DHCP server using dnsmasq #
This section explains how to configure DHCP services using dnsmasq to provide network configuration and PXE boot information for SUSE Linux Enterprise Server for SAP applications 16.0 installations. The dnsmasq DHCP server uses tag-based configuration to support both IPv4 and IPv6 PXE clients with UEFI and BIOS boot capabilities.
12.1 Introduction #
The dnsmasq DHCP server provides network configuration and boot file information to PXE clients using a tag-based system to match client types and provide appropriate bootloaders. This configuration supports both PXEClient and HTTPClient matches that work for DHCPv4 and DHCPv6, enabling boot via UEFI and BIOS systems across multiple architectures.
dnsmasq version 2.90 and earlier does not support sending the vendor-class option6:16 back to DHCPv6 clients for HTTPClient configurations. For full HTTPClient support, consider using Kea or ISC DHCP servers.
12.2 Requirements #
The dnsmasq package installed
PXE boot files properly organized under
/srv/tftpbootNetwork interface configured for DHCP service
Administrative privileges to configure DHCP services
12.3 Configuring dnsmasq DHCP services #
The dnsmasq DHCP configuration includes client type matching, network ranges, and boot file assignments for both IPv4 and IPv6 networks.
Create the DHCP configuration file for dnsmasq:
>sudocat > /etc/dnsmasq.d/dhcp.conf << 'EOF'# DHCP configuration file for dnsmasq # Log DHCP processing log-dhcp # This is the only DHCP server, don't ignore unknown clients/send NAK dhcp-authoritative # Disable re-use of the DHCPv4 servername and filename fields as extra # option space, which may confuse old or broken clients dhcp-no-override # IPv4 PXE/HTTP boot client matches (no enterprise number) # Match client type in PXEClient:Arch and map to a tag dhcp-vendorclass=set:tftp_bios_x86_pc,PXEClient:Arch:00000 dhcp-vendorclass=set:tftp_uefi_x86_64,PXEClient:Arch:00007 dhcp-vendorclass=set:tftp_ieee_ppc_64,PXEClient:Arch:0000e dhcp-vendorclass=set:tftp_uefi_arm_64,PXEClient:Arch:00011 # Match client type in HTTPClient:Arch and map to a tag dhcp-vendorclass=set:http_uefi_x86_64,HTTPClient:Arch:00016 dhcp-vendorclass=set:http_uefi_arm_64,HTTPClient:Arch:00019 # IPv6 PXE/HTTP boot client matches (enterprise:343 intel) # Match client type in PXEClient:Arch and map to a tag dhcp-vendorclass=set:tftp_bios_x86_pc,enterprise:343,PXEClient:Arch:00000 dhcp-vendorclass=set:tftp_uefi_x86_64,enterprise:343,PXEClient:Arch:00007 dhcp-vendorclass=set:tftp_ieee_ppc_64,enterprise:343,PXEClient:Arch:0000e dhcp-vendorclass=set:tftp_uefi_arm_64,enterprise:343,PXEClient:Arch:00011 # Match client type in HTTPClient:Arch and map to a tag dhcp-vendorclass=set:http_uefi_x86_64,enterprise:343,HTTPClient:Arch:00016 dhcp-vendorclass=set:http_uefi_arm_64,enterprise:343,HTTPClient:Arch:00019 EOFConfigure IPv4 DHCP range and options:
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv4 range and options dhcp-range=set:net0v4,192.168.1.100,192.168.1.199,255.255.255.0,1h dhcp-option=tag:net0v4,option:domain-search,example.net dhcp-option=tag:net0v4,option:dns-server,192.168.1.200 dhcp-option=tag:net0v4,option:ntp-server,192.168.1.1 dhcp-option=tag:net0v4,option:router,192.168.1.1 EOFConfigure IPv4 PXE boot options:
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv4 PXEClient boot dhcp-boot=tag:net0v4,tag:tftp_bios_x86_pc,/boot/grub2/i386-pc/core.0,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_uefi_x86_64,/boot/grub2/x86_64-efi/bootx64.efi,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_ieee_ppc_64,/boot/grub2/powerpc-ieee1275/core.elf,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_uefi_arm_64,/boot/grub2/arm64-efi/bootaa64.efi,192.168.1.200 # IPv4 HTTPClient boot dhcp-option-force=tag:net0v4,tag:http_uefi_x86_64,option:vendor-class,HTTPClient dhcp-boot=tag:net0v4,tag:http_uefi_x86_64,http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi dhcp-option-force=tag:net0v4,tag:http_uefi_arm_64,option:vendor-class,HTTPClient dhcp-boot=tag:net0v4,tag:http_uefi_arm_64,http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi EOFConfigure IPv6 DHCP range and options:
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv6 range and options dhcp-range=set:net0v6,2001:db8:0:1:d::,2001:db8:0:1:d::ffff,64,1h dhcp-option=tag:net0v6,option6:domain-search,example.net dhcp-option=tag:net0v6,option6:dns-server,[2001:db8:0:1::200] dhcp-option=tag:net0v6,option6:sntp-server,[2001:db8:0:1::1] EOFConfigure IPv6 PXE boot options:
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv6 PXEClient boot dhcp-option=tag:net0v6,tag:tftp_bios_x86_pc,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0 dhcp-option=tag:net0v6,tag:tftp_uefi_x86_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi dhcp-option=tag:net0v6,tag:tftp_ieee_ppc_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf dhcp-option=tag:net0v6,tag:tftp_uefi_arm_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi # IPv6 HTTPClient boot # Note: dnsmasq <= 2.90 does not support sending vendor-class option6:16 back to client EOFTest the dnsmasq configuration:
>sudodnsmasq --testEnable and start the dnsmasq service:
>sudosystemctl enable --now dnsmasq
12.4 Verifying DHCP configuration #
Test the DHCP server functionality to ensure proper network configuration and boot file delivery to PXE clients.
Check dnsmasq service status:
>systemctl status dnsmasqVerify DHCP port binding:
>ss -ulnp | grep :67Monitor DHCP lease assignments:
>journalctl -u dnsmasq -fCheck active DHCP leases:
>cat /var/lib/dhcp/dhcpd.leases
12.5 Troubleshooting dnsmasq DHCP configuration #
Common issues when configuring dnsmasq for DHCP services in PXE environments.
12.5.1 Service startup and configuration issues #
dnsmasq may fail to start due to configuration errors or port conflicts with other DHCP services.
Test dnsmasq configuration syntax:
>sudodnsmasq --testCheck for DHCP port conflicts:
>ss -ulnp | grep :67Stop conflicting DHCP services:
>sudosystemctl stop dhcpdView detailed service logs:
>journalctl -u dnsmasq -fRestart dnsmasq after resolving conflicts:
>sudosystemctl restart dnsmasq
12.5.2 DHCP lease assignment problems #
Clients may fail to receive IP addresses due to range configuration or network connectivity issues.
Check DHCP range configuration:
>grep dhcp-range /etc/dnsmasq.d/dhcp.confMonitor DHCP requests in real-time:
>journalctl -u dnsmasq -f | grep DHCPCheck network interface status:
>ip addr showVerify DHCP authoritative setting:
>grep dhcp-authoritative /etc/dnsmasq.d/dhcp.confTest DHCP response with dhcping:
>dhcping -s 192.168.1.200
12.5.3 PXE boot file delivery issues #
PXE clients may receive IP addresses but fail to boot due to incorrect boot file configuration or client type matching problems.
Check client vendor class matching:
>grep dhcp-vendorclass /etc/dnsmasq.d/dhcp.confVerify boot file paths:
>grep dhcp-boot /etc/dnsmasq.d/dhcp.confTest TFTP access to boot files:
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiMonitor PXE-specific DHCP logs:
>journalctl -u dnsmasq | grep -E "PXE|HTTP"Check tag assignment in logs:
>journalctl -u dnsmasq | grep "tags:"
12.5.4 IPv6 DHCP configuration issues #
IPv6 DHCP clients require proper router advertisement configuration and may have different addressing requirements than IPv4.
Verify IPv6 DHCP range configuration:
>grep "2001:db8" /etc/dnsmasq.d/dhcp.confCheck IPv6 router advertisement status:
>systemctl status radvdMonitor DHCPv6 requests:
>journalctl -u dnsmasq | grep "DHCPv6"Test IPv6 connectivity:
>ping6 2001:db8:0:1::200Check IPv6 option configuration:
>grep option6 /etc/dnsmasq.d/dhcp.conf
12.6 Next steps #
With dnsmasq DHCP services configured, PXE clients can receive network configuration and boot file information for both IPv4 and IPv6 environments. The tag-based system provides flexible boot file assignment based on client architecture and boot method requirements.
13 Configuring a DHCP server using Kea #
This section explains how to configure DHCP services using Kea to provide network configuration and PXE boot information for SUSE Linux Enterprise Server for SAP applications 16.0 installations. Kea is a modern DHCP server that supports both IPv4 and IPv6 with client class matching for PXE and HTTP boot scenarios.
13.1 Introduction #
Kea is the modern DHCP server developed by ISC as the successor to the legacy ISC DHCP server. It provides robust support for both DHCPv4 and DHCPv6 with client classification capabilities that enable proper boot file delivery based on client architecture and boot method. Kea uses JSON-based configuration files and supports advanced features like vendor class identification for HTTP boot.
13.2 Requirements #
Kea DHCP packages installed: kea-dhcp4 and kea-dhcp6
PXE boot files properly organized under
/srv/tftpbootNetwork interface configured for DHCP service
Administrative privileges to configure DHCP services
13.3 Configuring the Kea DHCPv4 server #
The Kea DHCPv4 configuration uses client classes to match PXE and HTTP client types and provide appropriate boot files for different architectures.
Configure the Kea DHCPv4 server:
>sudocat > /etc/kea/kea-dhcp4.conf << 'EOF'{ "Dhcp4": { "interfaces-config": { "interfaces": [ "eno1" ] }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea4-ctrl-socket" }, "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/dhcp4.leases", "lfc-interval": 3600 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1800, "rebind-timer": 3150, "valid-lifetime": 3600, "option-data": [], "client-classes": [ { "name": "pxeclients#00000", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/i386-pc/core.0" }, { "name": "pxeclients#00007", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/x86_64-efi/bootx64.efi" }, { "name": "pxeclients#0000e", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:0000e'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/powerpc-ieee1275/core.elf" }, { "name": "pxeclients#00011", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00011'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/arm64-efi/bootaa64.efi" }, { "name": "httpclients#00016", "test": "substring(option[60].hex,0,21) == 'HTTPClient:Arch:00016'", "boot-file-name": "http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi", "option-data": [ { "name": "vendor-class-identifier", "data": "HTTPClient" } ] }, { "name": "httpclients#00019", "test": "substring(option[60].hex,0,21) == 'HTTPClient:Arch:00019'", "boot-file-name": "http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi", "option-data": [ { "name": "vendor-class-identifier", "data": "HTTPClient" } ] } ], "subnet4": [ { "id": 1, "subnet": "192.168.1.0/24", "pools": [ { "pool": "192.168.1.100 - 192.168.1.199" } ], "option-data": [ { "name": "routers", "data": "192.168.1.1" }, { "name": "ntp-servers", "data": "192.168.1.1" }, { "name": "domain-name-servers", "data": "192.168.1.200" }, { "name": "domain-search", "data": "example.net" } ], "reservations": [] } ], "loggers": [ { "name": "kea-dhcp4", "output-options": [ { "output": "/var/log/kea/dhcp4.log" } ], "severity": "INFO", "debuglevel": 0 } ] } } EOFCreate the Kea log directory:
>sudomkdir -p /var/log/keaTest the Kea DHCPv4 configuration:
>sudokea-dhcp4 -t /etc/kea/kea-dhcp4.confEnable and start the Kea DHCPv4 service:
>sudosystemctl enable --now kea-dhcp4
13.4 Configuring Kea DHCPv6 server #
The Kea DHCPv6 configuration provides IPv6 address assignment and boot file information using vendor class matching for different client architectures.
Configure the Kea DHCPv6 server:
>sudocat > /etc/kea/kea-dhcp6.conf << 'EOF'{ "Dhcp6": { "interfaces-config": { "interfaces": [ "eno1" ] }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea6-ctrl-socket" }, "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/dhcp6.leases", "lfc-interval": 3600 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1800, "rebind-timer": 2880, "preferred-lifetime": 3600, "valid-lifetime": 7200, "option-data": [], "option-def": [], "client-classes": [ { "name": "pxeclients#00000", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00000'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0" } ] }, { "name": "pxeclients#00007", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00007'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi" } ] }, { "name": "pxeclients#0000e", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:0000e'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf" } ] }, { "name": "pxeclients#00011", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00011'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi" } ] } ], "subnet6": [ { "id": 1, "subnet": "2001:db8:0:1::/64", "interface": "eno1", "pools": [ { "pool": "2001:db8:0:1:d::/112" } ], "option-data": [ { "name": "sntp-servers", "data": "2001:db8:0:1::1" }, { "name": "dns-servers", "data": "2001:db8:0:1::200" }, { "name": "domain-search", "data": "example.net" } ], "reservations": [] } ], "loggers": [ { "name": "kea-dhcp6", "output-options": [ { "output": "/var/log/kea/dhcp6.log" } ], "severity": "INFO", "debuglevel": 0 } ] } } EOFTest the Kea DHCPv6 configuration:
>sudokea-dhcp6 -t /etc/kea/kea-dhcp6.confEnable and start the Kea DHCPv6 service:
>sudosystemctl enable --now kea-dhcp6
13.5 Verifying Kea DHCP configuration #
Test the Kea DHCP server functionality to ensure proper network configuration and boot file delivery to PXE clients.
Check Kea DHCPv4 service status:
>systemctl status kea-dhcp4Check Kea DHCPv6 service status:
>systemctl status kea-dhcp6Verify DHCP port binding:
>ss -ulnp | grep -E ":67|:547"Monitor DHCPv4 logs:
>tail -f /var/log/kea/dhcp4.logMonitor DHCPv6 logs:
>tail -f /var/log/kea/dhcp6.logCheck active DHCP leases:
>cat /var/lib/kea/dhcp4.leases
13.6 Troubleshooting Kea DHCP configuration #
Common issues when configuring Kea DHCP servers for PXE boot environments.
13.6.1 Configuration and service issues #
Kea services may fail to start due to JSON configuration errors or network interface problems.
Test DHCPv4 configuration syntax:
>sudokea-dhcp4 -t /etc/kea/kea-dhcp4.confTest DHCPv6 configuration syntax:
>sudokea-dhcp6 -t /etc/kea/kea-dhcp6.confCheck for JSON syntax errors:
>python3 -m json.tool /etc/kea/kea-dhcp4.confVerify network interface configuration:
>ip addr show eno1Check Kea service logs:
>journalctl -u kea-dhcp4 -f
13.6.2 DHCP lease assignment problems #
Clients may fail to receive IP addresses due to subnet configuration or pool exhaustion issues.
Check subnet and pool configuration:
>grep -A 10 "subnet4\|pools" /etc/kea/kea-dhcp4.confMonitor lease assignments in real-time:
>tail -f /var/log/kea/dhcp4.log | grep -E "ALLOC|DISCOVER"Check lease database for conflicts:
>cat /var/lib/kea/dhcp4.leases | tail -20Verify interface binding:
>grep interfaces /etc/kea/kea-dhcp4.confClear lease database if needed:
>sudosystemctl stop kea-dhcp4>sudomv /var/lib/kea/dhcp4.leases /var/lib/kea/dhcp4.leases.backup>sudosystemctl start kea-dhcp4
13.6.3 PXE client class matching issues #
PXE clients may receive IP addresses but fail to get correct boot files due to client class configuration problems.
Check client class definitions:
>grep -A 5 "client-classes" /etc/kea/kea-dhcp4.confMonitor client class matching in logs:
>tail -f /var/log/kea/dhcp4.log | grep -i classVerify vendor class identifier patterns:
>grep "PXEClient\|HTTPClient" /etc/kea/kea-dhcp4.confTest boot file accessibility:
>curl -I http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efiEnable debug logging for detailed client analysis:
>sudosed -i 's/"debuglevel": 0/"debuglevel": 99/' /etc/kea/kea-dhcp4.conf>sudosystemctl restart kea-dhcp4
13.6.4 DHCPv6 specific issues #
IPv6 DHCP clients require proper router advertisement configuration and have different vendor class option handling than IPv4.
Check DHCPv6 subnet configuration:
>grep -A 10 "subnet6" /etc/kea/kea-dhcp6.confVerify IPv6 router advertisement status:
>systemctl status radvdMonitor DHCPv6 vendor class matching:
>tail -f /var/log/kea/dhcp6.log | grep "option\[16\]"Check IPv6 bootfile-url option format:
>grep "bootfile-url" /etc/kea/kea-dhcp6.confTest IPv6 connectivity to boot server:
>ping6 2001:db8:0:1::200
13.7 Next steps #
With Kea DHCP services configured, PXE clients can receive comprehensive network configuration and boot file information for both IPv4 and IPv6 environments. The client classification system provides precise boot file assignment based on client architecture and supports both traditional PXE and modern HTTP boot methods.
14 Configuring a DHCP server using ISC DHCP #
This section explains how to configure the ISC DHCP server to provide network configuration and PXE boot information for SUSE Linux Enterprise Server for SAP applications 15 installations. The ISC dhcp-server package is not available on SUSE Linux Enterprise Server for SAP applications 16.0 anymore. ISC DHCP uses class and subclass matching to support PXE and HTTP boot scenarios across different client architectures.
14.1 Introduction #
ISC DHCP is the traditional DHCP server that provides network configuration and boot file information to PXE clients using a class and subclass system. While ISC has declared this server end-of-life as of 2022, it remains widely used in existing deployments and provides robust support for PXE and HTTP boot scenarios with vendor class identification.
ISC DHCP has been declared end-of-life by ISC in 2022. For new deployments, consider using Kea or dnsmasq instead. This configuration is provided for compatibility with existing ISC DHCP installations.
14.2 Requirements #
ISC DHCP packages installed: dhcp-server
PXE boot files properly organized under
/srv/tftpbootNetwork interface configured for DHCP service
Administrative privileges to configure DHCP services
14.3 Configuring the ISC DHCPv4 server #
The ISC DHCPv4 configuration uses class and subclass declarations to match PXE and HTTP client types and provide appropriate boot files for different architectures.
Configure the ISC DHCPv4 server:
>sudocat > /etc/dhcpd.conf << 'EOF'# /etc/dhcpd.conf # # Sample configuration file for ISC dhcpd # # *** PLEASE CONFIGURE IT FIRST *** # # Don't forget to set the DHCPD_INTERFACE in the # /etc/sysconfig/dhcpd file. # # if you want to use dynamical DNS updates, you should first read # read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt # ddns-updates off; # Use this to enable / disable dynamic dns updates globally. ddns-update-style none; # default lease time default-lease-time 3600; max-lease-time 7200; ## ## PXE / HTTP boot option declarations ## class "pxeclients" { # PXEClient:Arch:00000:UNDI:002001 match substring (option vendor-class-identifier, 0, 20); } class "httpclients" { # HTTPClient:Arch:00016:UNDI:003001 match substring (option vendor-class-identifier, 0, 21); } ## ## PXE / HTTP boot subclass request matches ## subclass "pxeclients" "PXEClient:Arch:00000" { next-server 192.168.1.200; filename "/boot/grub2/i386-pc/core.0"; } subclass "pxeclients" "PXEClient:Arch:00007" { next-server 192.168.1.200; filename "/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "pxeclients" "PXEClient:Arch:0000e" { next-server 192.168.1.200; filename "/boot/grub2/powerpc-ieee1275/core.elf"; } subclass "pxeclients" "PXEClient:Arch:00011" { next-server 192.168.1.200; filename "/boot/grub2/arm64-efi/bootaa64.efi"; } subclass "httpclients" "HTTPClient:Arch:00016" { option vendor-class-identifier "HTTPClient"; filename "http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "httpclients" "HTTPClient:Arch:00019" { option vendor-class-identifier "HTTPClient"; filename "http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi"; } ## ## Subnet declaration for the pxe network ## subnet 192.168.1.0 netmask 255.255.255.0 { authoritative; range dynamic-bootp 192.168.1.100 192.168.1.199; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option ntp-servers 192.168.1.1; option domain-name-servers 192.168.1.200; option domain-name "example.net"; option domain-search "example.net"; } EOFConfigure the DHCP interface in sysconfig:
>sudoecho 'DHCPD_INTERFACE="eno1"' > /etc/sysconfig/dhcpdTest the DHCPv4 configuration:
>sudodhcpd -t -cf /etc/dhcpd.confEnable and start the ISC DHCPv4 service:
>sudosystemctl enable --now dhcpd
14.4 Configuring the ISC DHCPv6 server #
The ISC DHCPv6 configuration provides IPv6 address assignment and boot file information using vendor class matching with proper DHCPv6 option handling.
Configure the ISC DHCPv6 server:
>sudocat > /etc/dhcpd6.conf << 'EOF'# /etc/dhcpd6.conf # # Sample DHCPv6 configuration file for ISC dhcpd # # *** PLEASE CONFIGURE IT FIRST *** # # Don't forget to set the DHCPD6_INTERFACE in the # /etc/sysconfig/dhcpd file. # # if you want to use dynamical DNS updates, you should first # read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt ddns-updates off; # Use this to enable / disable dynamic dns updates globally. ddns-update-style none; # IPv6 address valid lifetime # (at the end the address is no longer usable by the client) # (set to 30 days, the usual IPv6 default) default-lease-time 7200; # IPv6 address preferred lifetime # (at the end the address is deprecated, i.e., the client should use # other addresses for new connections) # (set to 7 days, the usual IPv6 default) preferred-lifetime 3600; ## ## PXE / HTTP boot option declarations ## # The dhcp6 option 16 is in fact an: # { uint32 enterprise-number, array of { uint16 len, string tag} vendor-class-data } # this declaration is using the whole option data as string for substring match: option dhcp6.vendor-class-as-string code 16 = string; # this declaration is using the enterprise-number with 1st tag length and string: option dhcp6.vendor-class-en-len-tag code 16 = {integer 32, integer 16, string}; class "pxeclients" { # PXEClient:Arch:00000:UNDI:002001 # note: +6 to skip the enterprise-number+len until the PXEClient string match substring (option dhcp6.vendor-class-as-string, 6, 20); } class "httpclients" { # HTTPClient:Arch:00016:UNDI:003001 # note: +6 to skip the enterprise-number+len until the HTTPClient string match substring (option dhcp6.vendor-class-as-string, 6, 21); } ## ## PXE / HTTP boot subclass request matches ## subclass "pxeclients" "PXEClient:Arch:00000" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0"; } subclass "pxeclients" "PXEClient:Arch:00007" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "pxeclients" "PXEClient:Arch:0000e" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf"; } subclass "pxeclients" "PXEClient:Arch:00011" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi"; } subclass "httpclients" "HTTPClient:Arch:00016" { option dhcp6.vendor-class-en-len-tag 343 10 "HTTPClient"; option dhcp6.bootfile-url "http://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "httpclients" "HTTPClient:Arch:00019" { option dhcp6.vendor-class-en-len-tag 343 10 "HTTPClient"; option dhcp6.bootfile-url "http://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi"; } ## ## Subnet declaration for the pxe network ## subnet6 2001:db8:0:1::/64 { authoritative; range6 2001:db8:0:1:d:: 2001:db8:0:1:d::ffff; option dhcp6.sntp-servers 2001:db8:0:1::1; option dhcp6.name-servers 2001:db8:0:1::200; option dhcp6.domain-search "example.net"; } EOFConfigure the DHCPv6 interface in sysconfig:
>sudoecho 'DHCPD6_INTERFACE="eno1"' >> /etc/sysconfig/dhcpdTest the DHCPv6 configuration:
>sudodhcpd -6 -t -cf /etc/dhcpd6.confEnable and start the ISC DHCPv6 service:
>sudosystemctl enable --now dhcpd6
14.5 Verifying the ISC DHCP configuration #
Test the ISC DHCP server functionality to ensure proper network configuration and boot file delivery to PXE clients.
Check ISC DHCPv4 service status:
>systemctl status dhcpdCheck ISC DHCPv6 service status:
>systemctl status dhcpd6Verify DHCP port binding:
>ss -ulnp | grep -E ":67|:547"Monitor DHCP logs:
>journalctl -u dhcpd -fCheck active DHCP leases:
>cat /var/lib/dhcp/dhcpd.leasesMonitor DHCPv6 activity:
>journalctl -u dhcpd6 -f
14.6 Troubleshooting ISC DHCP configuration #
Common issues when configuring ISC DHCP servers for PXE boot environments.
14.6.1 Configuration and service issues #
ISC DHCP services may fail to start due to configuration syntax errors or interface binding problems.
Test DHCPv4 configuration syntax:
>sudodhcpd -t -cf /etc/dhcpd.confTest DHCPv6 configuration syntax:
>sudodhcpd -6 -t -cf /etc/dhcpd6.confCheck interface configuration:
>cat /etc/sysconfig/dhcpdVerify network interface status:
>ip addr show eno1Check for port conflicts:
>ss -ulnp | grep :67View detailed service logs:
>journalctl -u dhcpd -xe
14.6.2 DHCP lease assignment problems #
Clients may fail to receive IP addresses due to subnet configuration or authorization issues.
Check subnet and range configuration:
>grep -A 10 "subnet\|range" /etc/dhcpd.confVerify authoritative setting:
>grep authoritative /etc/dhcpd.confMonitor lease assignments in real time:
>tail -f /var/log/messages | grep dhcpdCheck lease database for errors:
>tail -20 /var/lib/dhcp/dhcpd.leasesTest DHCP response manually:
>dhcping -s 192.168.1.200 -h aa:bb:cc:dd:ee:ff
14.6.3 Class and subclass matching issues #
PXE clients may receive IP addresses but fail to get correct boot files due to class matching configuration problems.
Check class definitions:
>grep -A 3 "class.*clients" /etc/dhcpd.confVerify subclass entries:
>grep -A 5 "subclass" /etc/dhcpd.confMonitor vendor class identification:
>tail -f /var/log/messages | grep -E "PXEClient|HTTPClient"Test boot file accessibility:
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiEnable detailed logging:
>sudosed -i '1i\log-facility local7;' /etc/dhcpd.conf>sudosystemctl restart dhcpd
14.6.4 DHCPv6 vendor class option issues #
IPv6 DHCP clients have complex vendor class option handling that may require specific configuration for proper PXE boot support.
Check DHCPv6 option definitions:
>grep -A 3 "option dhcp6" /etc/dhcpd6.confVerify vendor class string parsing:
>grep "substring.*6.*20\|21" /etc/dhcpd6.confMonitor DHCPv6 vendor class matching:
>journalctl -u dhcpd6 | grep -i vendorCheck IPv6 bootfile-url format:
>grep "bootfile-url" /etc/dhcpd6.confVerify router advertisement dependency:
>systemctl status radvdTest IPv6 connectivity:
>ping6 2001:db8:0:1::200
14.7 Next steps #
With ISC DHCP services configured, PXE clients can receive network configuration and boot file information using the traditional class and subclass system. While ISC DHCP is end-of-life, this configuration provides compatibility for existing deployments that require PXE and HTTP boot functionality across multiple client architectures.
15 Validating PXE server setup #
This section describes how to validate and test the complete PXE server setup to ensure all components are working correctly for SUSE Linux Enterprise Server for SAP applications 16.0 network installations. It covers service verification, network connectivity testing, and end-to-end PXE boot validation.
15.1 Introduction #
After configuring all PXE server components, including TFTP, HTTP, DNS, DHCP, and GRUB 2 bootloader services, it is essential to validate that the complete system functions correctly. This validation ensures that PXE clients can successfully boot into the Agama installer and perform network-based installations of SUSE Linux Enterprise Server for SAP applications 16.0.
15.2 Requirements #
All PXE server components configured and running
Test client systems capable of PXE booting
Network connectivity between the PXE server and clients
Administrative access to monitor server services
15.3 Validating PXE server services #
Verify that all essential PXE server services are running and properly configured before testing with PXE clients.
Verify TFTP service status:
>systemctl status tftp.socketExpected result: Service should be active and listening on port 69.
Check nginx HTTP service:
>systemctl status nginxExpected result: Service should be active and listening on port 80.
Verify DNS service (if using dnsmasq):
>systemctl status dnsmasqExpected result: Service should be active and listening on port 53.
Check DHCP service status (choose appropriate service):
>systemctl status dhcpdFor dnsmasq DHCP:
>systemctl status dnsmasqFor Kea DHCP:
>systemctl status kea-dhcp4 kea-dhcp6Expected result: DHCP service should be active and listening on appropriate ports.
Verify IPv6 router advertisement (if configured):
>systemctl status radvdExpected result: Service should be active for IPv6 environments.
Check NTP service:
>systemctl status chronydExpected result: Service should be active and synchronized.
15.4 Testing network connectivity and file access #
Validate that PXE clients can access boot files and installation content over the network using both TFTP and HTTP protocols.
Test TFTP access to bootloader files:
>tftp localhost -c get /boot/grub2/x86_64-efi/bootx64.efi /tmp/test-bootx64.efiVerify the file was retrieved:
>file /tmp/test-bootx64.efiClean up test file:
>rm /tmp/test-bootx64.efiTest HTTP access to GRUB 2 configuration:
>curl -I http://localhost/boot/grub2/grub.cfgExpected result: HTTP 200 OK response.
Verify HTTP access to installer files:
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.imgExpected result: HTTP 200 OK response with appropriate content length.
Test DNS resolution (if local DNS configured):
>nslookup pxe.example.net localhostExpected result: Proper A and AAAA record resolution.
Verify directory browsing for autoindex locations:
>curl http://localhost/boot/Expected result: Directory listing showing boot files.
15.5 Validating DHCP functionality #
Test DHCP server responses and verify that proper boot information is provided to different client types.
Check DHCP port binding:
>ss -ulnp | grep -E ":67|:547"Expected result: DHCP services listening on ports 67 (IPv4) and 547 (IPv6).
Monitor DHCP requests in real-time:
>journalctl -u dhcpd -fOr for dnsmasq:
>journalctl -u dnsmasq -fLeave this running to observe DHCP activity during testing.
Test DHCP response using dhcping (if available):
>dhcping -s 192.168.1.200Expected result: Successful DHCP response from server.
Check active DHCP leases:
>cat /var/lib/dhcp/dhcpd.leasesOr for Kea:
>cat /var/lib/kea/dhcp4.leasesExpected result: Lease entries for test clients.
15.6 End-to-end PXE boot testing #
Perform complete PXE boot tests with actual client systems to validate the entire boot process from DHCP to Agama installer startup.
Prepare a test client system:
Configure BIOS/UEFI to enable network boot
Set network boot as first boot priority
Connect the client to the same network as PXE server
Monitor PXE server logs during client boot:
>journalctl -f | grep -E "dhcp|tftp|nginx"Boot the test client and observe the following sequence:
Client should receive IP address via DHCP
Client should download bootloader via TFTP
GRUB 2 menu should appear with installation options
Kernel and initrd should load via HTTP
Agama installer should start successfully
Verify client architecture detection by testing different client types:
Legacy BIOS x86_64 systems (should get core.0)
UEFI x86_64 systems (should get bootx64.efi)
UEFI aarch64 systems (should get bootaa64.efi)
Test IPv6 PXE boot (if IPv6 configured):
Enable IPv6-only network configuration on test client
Verify DHCPv6 address assignment
Confirm IPv6 bootfile-url delivery
15.7 Validating Agama installer functionality #
Verify that the Agama installer starts correctly and can access installation sources for completing SUSE Linux Enterprise Server for SAP applications 16.0 installations.
Verify Agama Web interface accessibility:
During client boot, note the IP address assigned and access:
http://CLIENT_IP_ADDRESS
Expected result: Agama Web interface should load successfully.
Check Agama installer logs on the client:
Switch to the console (Alt+F2) and run:
#journalctl -u agama-web-server -fExpected result: No critical errors in Agama startup.
Verify installation source accessibility:
For Full ISO installations, check repository access:
#curl -I http://192.168.1.200/install/SLES-16.0/x86_64/Expected result: HTTP 200 OK response with directory listing.
Test package installation capability:
In Agama interface, verify that:
The system can detect available disks
Network configuration is preserved
Package repository is accessible
Installation can proceed to completion
15.8 Troubleshooting validation failures #
Common issues during PXE server validation and their resolution steps.
15.8.1 DHCP assignment failures #
Clients fail to receive IP addresses during PXE boot.
Check DHCP service conflicts:
>ss -ulnp | grep :67Verify network interface is up:
>ip addr show eno1Check DHCP range availability:
>nmap -sn 192.168.1.100-199Monitor DHCP logs for errors:
>journalctl -u dhcpd | tail -50
15.8.2 Boot file delivery failures #
Clients receive IP addresses but fail to download boot files.
Verify TFTP service accessibility:
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiCheck file permissions:
>ls -la /srv/tftpboot/boot/grub2/x86_64-efi/Monitor TFTP access logs:
>journalctl -u tftp.socket -fVerify client architecture detection:
>grep -E "PXEClient|HTTPClient" /var/log/messages
15.8.3 Agama installer startup failures #
Boot files load successfully but Agama installer fails to start.
Check HTTP access to installer files:
>curl -I http://192.168.1.200/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.imgVerify kernel parameter syntax in GRUB 2 configuration:
>grep "root=live:" /srv/tftpboot/boot/grub2/menu.cfgMonitor client boot process:
>journalctl -f | grep -E "kernel|initrd|agama"Check network configuration persistence:
#ip addr show
15.9 PXE server validation checklist #
Use this checklist to systematically verify all aspects of your PXE server configuration.
| Component | Validation Step | Status |
|---|---|---|
| TFTP Service | Service active, port 69 listening, files accessible | ☐ |
| HTTP Service | nginx active, port 80 listening, installer files accessible | ☐ |
| DNS Service | Host name resolution working, port 53 listening | ☐ |
| DHCP Service | IP assignment working, boot options delivered | ☐ |
| GRUB 2 Configuration | Menu loads, architecture detection working | ☐ |
| IPv6 Support | Router advertisement active, DHCPv6 functioning | ☐ |
| PXE Boot | Client boots successfully, receives correct bootloader | ☐ |
| Agama Installer | Installer starts; Web interface accessible | ☐ |
| Installation Source | Repository accessible, packages installable | ☐ |
| Network Persistence | Network configuration maintained during installation | ☐ |
15.10 Validation conclusion #
A properly validated PXE server should demonstrate successful end-to-end functionality from client network boot through Agama installer startup. All services should operate without errors, and clients should be able to complete SUSE Linux Enterprise Server for SAP applications 16.0 installations over the network. Regular validation testing ensures the continued reliability of the PXE infrastructure for automated deployments.
16 Legal Notice #
Copyright© 2006–2025 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.