Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Dokumentace systému SUSE Linux Enterprise Server / Deployment Guide / Setting Up an Installation Server / Preparing the Boot of the Target System
Applies to SUSE Linux Enterprise Server 12 SP5

9 Preparing the Boot of the Target System

After the installations server is properly configured depending on which network protocol you prefer, you need to configure remote booting from it. This section covers the configuration tasks needed in complex boot scenarios and contains ready-to-apply configuration examples for DHCP, PXE boot, TFTP, and Wake on LAN.

Note
Note: Terminology

In the following sections, the system to hold your new SUSE Linux Enterprise Server installation is called target system or installation target. The term repository (previously called installation source) is used for all sources of installation data. This includes physical media, such as CD and DVD, and network servers distributing the installation data in your network.

Refer to Chapter 8, Setting Up the Server Holding the Installation Sources to find examples of serving the installation data via NFS, FTP, SMB or HTTP.

The examples assume that the DHCP, TFTP and NFS server reside on the same machine with the IP 192.168.1.1. All services can reside on different machines without any problems. Make sure to change the IP addresses as required.

9.1 Setting Up a DHCP Server

In addition to providing automatic address allocation to your network clients, the DHCP server announces the IP address of the TFTP server and the file that needs to be pulled in by the installation routines on the target machine. The file that has to be loaded depends on the architecture of the target machine and whether legacy BIOS or UEFI boot is used.

  1. Log in as root to the machine hosting the DHCP server.

  2. Enable the DHCP server by executing systemctl enable dhcpd.

  3. Append the following lines to a subnet configuration of your DHCP server's configuration file located under /etc/dhcpd.conf:

    # The following lines are optional
    option domain-name "my.lab";
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    option ntp-servers 192.168.1.1;
    ddns-update-style none;
    default-lease-time 3600;
    
    # The following lines are required
    option arch code 93 = unsigned integer 16; # RFC4578
    subnet 192.168.1.0 netmask 255.255.255.0 {
     next-server 192.168.1.1;
     range 192.168.1.100 192.168.1.199;
     default-lease-time 3600;
     max-lease-time 3600;
     if option arch = 00:07 or option arch = 00:09 {
       filename "/EFI/x86/grub.efi";
     }
     else if option arch = 00:0b {
       filename "/EFI/aarch64/bootaa64.efi";
     }
     else  {
       filename "/BIOS/x86/pxelinux.0";
     }
    }

    This configuration example uses the subnet 192.168.1.0/24 with the DHCP, DNS and gateway on the server with the IP 192.168.1.1. Make sure that all used IP addresses are changed according to your network layout. For more information about the options available in dhcpd.conf, refer to the dhcpd.conf manual page.

  4. Restart the DHCP server by executing systemctl restart dhcpd.

If you plan to use SSH for the remote control of a PXE and Wake on LAN installation, specify the IP address DHCP should provide to the installation target. To achieve this, modify the above mentioned DHCP configuration according to the following example:

group {
 host test {
   hardware ethernet MAC_ADDRESS;
   fixed-address IP_ADDRESS;
   }
}

The host statement introduces the host name of the installation target. To bind the host name and IP address to a specific host, you must know and specify the system's hardware (MAC) address. Replace all the variables used in this example with the actual values that match your environment.

After restarting the DHCP server, it provides a static IP to the host specified, enabling you to connect to the system via SSH.

9.2 Setting Up a TFTP Server

If using a SUSE based installation, you may use YaST to set up a TFTP Server. Alternatively, set it up manually. The TFTP server delivers the boot image to the target system after it boots and sends a request for it.

9.2.1 Setting Up a TFTP Server Using YaST

  1. Log in as root.

  2. Start YaST › Network Services › TFTP Server and install the requested package.

  3. Click Enable to make sure that the server is started and included in the boot routines. No further action from your side is required to secure this. xinetd starts tftpd at boot time.

  4. Click Open Port in Firewall to open the appropriate port in the firewall running on your machine. If there is no firewall running on your server, this option is not available.

  5. Click Browse to browse for the boot image directory. The default directory /srv/tftpboot is created and selected automatically.

  6. Click Finish to apply your settings and start the server.

9.2.2 Setting Up a TFTP Server Manually

  1. Log in as root and install the packages tftp and xinetd.

  2. Modify the configuration of xinetd located under /etc/xinetd.d to make sure that the TFTP server is started on boot:

    1. If it does not exist, create a file called tftp under this directory with touch tftp. Then run chmod 755 tftp.

    2. Open the file tftp and add the following lines:

      service tftp
      {
              socket_type            = dgram
              protocol               = udp
              wait                   = yes
              user                   = root
              server                 = /usr/sbin/in.tftpd
              server_args            = -s /srv/tftpboot
              disable                = no
      }
    3. Save the file and restart xinetd with systemctl restart xinetd.

9.3 Installing Files on TFTP Server

The following procedures describe how to prepare the server for target machines with UEFI and BIOS on x86 architectures with 32 and 64 bits. The prepared structure also already provides for AArch64 systems.

9.3.1 Preparing the Structure

In this procedure, replace OS_VERSION and SP_VERSION with the used operating system and service pack version. For example, use sles12 and sp5.

  1. Create a structure in /srv/tftpboot to support the various options.

    root # mkdir -p /srv/tftpboot/BIOS/x86
    root # mkdir -p /srv/tftpboot/EFI/x86/boot
    root # mkdir -p /srv/tftpboot/EFI/aarch64/boot
    root # mkdir -p /srv/install/x86/OS_VERSION/SP_VERSION/cd1
    root # mkdir -p /srv/install/aarch64/OS_VERSION/SP_VERSION/cd1
  2. Download the DVD ISO images of SUSE Linux Enterprise Server 12 SP5 from the SUSE Web site for all architectures you need.

  3. Mount the ISO files as described in Section 8.6, “Using ISO Images of the Installation Media on the Server”. To have the files available after a reboot, create an entry in /etc/fstab. For a standard installation, only DVD 1 is required.

    root # mount -o loop PATH_TO_ISO /srv/install/ARCH/OS_VERSION/SP_VERSION/cd1/

    Repeat this step for all required architectures and replace ARCH with x86 or aarch64 and PATH_TO_ISO with the path to the corresponding ISO file.

  4. Copy the kernel, initrd and message files required for x86 BIOS and UEFI boot to the appropriate location.

    root # cd /srv/install/x86/OS_version/SP_version/cd1/boot/x86_64/loader/
    root # cp -a linux initrd message /srv/tftpboot/BIOS/x86/
  5. Ensure that the path /srv/install is available via NFS. For details, see Section 8.2, “Setting Up an NFS Repository Manually”.

9.3.2 BIOS Files for x86

  1. Copy pxelinux.0 into the TFTP folder and prepare a subfolder for the configuration file.

    root # cp /usr/share/syslinux/pxelinux.0 /srv/tftpboot/BIOS/x86/
    root # mkdir /srv/tftpboot/BIOS/x86/pxelinux.cfg
  2. Create /srv/tftpboot/BIOS/x86/pxelinux.cfg/default and add the following lines:

    default install
    
    # hard disk
    label harddisk
     localboot -2
    # install
    label install
     kernel linux
     append initrd=initrd install=nfs://192.168.1.1:/srv/install/x86/OS_version/SP_version/cd1
    
    display message
    implicit 0
    prompt 1
    timeout 5
  3. Edit the file /srv/tftpboot/BIOS/x86/message to reflect the default file you just edited.

    Welcome to the Installer Environment!
    
    To start the installation enter 'install' and press <return>.
    
    Available boot options:
     harddisk   - Boot from Hard Disk (this is default)
     install    - Installation

9.3.3 UEFI Files for x86

In this procedure replace OS_version and SP_version with the used operating system and service pack version. For example use sles12 and sp5.

  1. Copy all required grub2 files for UEFI booting.

    root # cd /srv/install/x86/OS_version/SP_version/cd1/EFI/BOOT
    root # cp -a bootx64.efi grub.efi MokManager.efi /srv/tftpboot/EFI/x86/
  2. Copy the kernel and initrd files to the directory structure.

    root # cd /srv/install/x86/OS_version/SP_version/cd1/boot/x86_64/loader/
    root # cp -a linux initrd /srv/tftpboot/EFI/x86/boot
  3. Create the file /srv/tftpboot/EFI/x86/grub.cfg with at least the following content:

    set timeout=5
    menuentry 'Install OS_version SP_version for x86_64' {
      linuxefi /EFI/x86/boot/linux \
       install=nfs://192.168.1.1/srv/install/x86/OS_version/SP_version/cd1
      initrdefi /EFI/x86/boot/initrd
    }

9.3.4 UEFI Files for AArch64

In this procedure replace OS_version and SP_version with the used operating system and service pack version. For example use sles12 and sp5.

  1. This is done in a way very similar to the x86_64 EFI environment. Start by copying the files required for UEFI booting of a grub2-efi environment.

    root # cd /srv/install/aarch64/OS_version/SP_version/cd1/EFI/BOOT
    root # cp -a bootaa64.efi /srv/tftpboot/EFI/aarch64/
  2. Copy the kernel and initrd to the directory structure.

    root # cd /srv/install/aarch64/OS_version/SP_version/cd1/boot/aarch64
    root # cp -a linux initrd /srv/tftpboot/EFI/aarch64/boot
  3. Now create the file /srv/tftpboot/EFI/grub.cfg and add the following content:

    menuentry 'Install OS_version SP_version' {
      linux /EFI/aarch64/boot/linux network=1 usessh=1 sshpassword="suse" \
       install=nfs://192.168.1.1:/srv/install/aarch64/OS_version/SP_version/cd1 \
       console=ttyAMA0,115200n8
      initrd /EFI/aarch64/boot/initrd
    }

    This addition to the configuration file has a few other options to enable the serial console and allow installation via SSH, which is helpful for systems that do not have a standard KVM console interface. You will notice that this is set up for a specific ARM platform.

9.4 PXELINUX Configuration Options

The options listed here are a subset of all the options available for the PXELINUX configuration file.

APPEND OPTIONS

Add one or more options to the kernel command line. These are added for both automatic and manual boots. The options are added at the very beginning of the kernel command line, usually permitting explicitly entered kernel options to override them.

APPEND -

Append nothing. APPEND with a single hyphen as argument in a LABEL section can be used to override a global APPEND.

DEFAULT KERNEL_OPTIONS...

Sets the default kernel command line. If PXELINUX boots automatically, it acts as if the entries after DEFAULT had been typed in at the boot prompt, except the auto option is automatically added, indicating an automatic boot.

If no configuration file exists or no DEFAULT entry is defined in the configuration file, the default is the kernel name linux with no options.

IFAPPEND FLAG

Adds a specific option to the kernel command line depending on the FLAG value. The IFAPPEND option is available only on PXELINUX. FLAG expects a value, described in Table 9.1, “Generated and Added Kernel Command Line Options from IFAPPEND:

Table 9.1: Generated and Added Kernel Command Line Options from IFAPPEND

Argument

Generated Kernel Command Line / Description

1

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

The placeholders are replaced based on the input from the DHCP/BOOTP or PXE boot server.

Note, this option is not a substitute for running a DHCP client in the booted system. Without regular renewals, the lease acquired by the PXE BIOS will expire, making the IP address available for reuse by the DHCP server.

2

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

This option is useful if you want to avoid timeouts when the installation server probes one LAN interface after the other until it gets a reply from a DHCP server. This option allows an initrd program to determine from which interface the system has been booted. linuxrc reads this option and uses this network interface.

4

SYSUUID=SYSTEM_UUID

Adds UUIDs in lowercase hexadecimals, see /usr/share/doc/packages/syslinux/pxelinux.txt

LABEL LABEL KERNEL IMAGE APPEND OPTIONS...

Indicates that if LABEL is entered as the kernel to boot, PXELINUX should instead boot IMAGE and the specified APPEND options should be used instead of the ones specified in the global section of the file (before the first LABEL command). The default for IMAGE is the same as LABEL and, if no APPEND is given, the default is to use the global entry (if any). Up to 128 LABEL entries are permitted.

PXELINUX uses the following syntax:

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Labels are mangled as if they were file names and they must be unique after mangling. For example, the two labels v2.6.30 and v2.6.31 would not be distinguishable under PXELINUX because both mangle to the same DOS file name.

The kernel does not need to be a Linux kernel. It can also be a boot sector or a COMBOOT file.

LOCALBOOT TYPE

On PXELINUX, specifying LOCALBOOT 0 instead of a KERNEL option means invoking this particular label and causes a local disk boot instead of a kernel boot.

Argument

Description

0

Perform a normal boot

4

Perform a local boot with the Universal Network Driver Interface (UNDI) driver still resident in memory

5

Perform a local boot with the entire PXE stack, including the UNDI driver, still resident in memory

All other values are undefined. If you do not know what the UNDI or PXE stacks are, specify 0.

TIMEOUT TIME-OUT

Indicates how long to wait at the boot prompt until booting automatically, in units of 1/10 second. The time-out is canceled when the user types anything on the keyboard, assuming the user will complete the command begun. A time-out of zero disables the time-out completely (this is also the default). The maximum possible time-out value is 35996 (just less than one hour).

PROMPT flag_val

If flag_val is 0, displays the boot prompt only if Shift or Alt is pressed or Caps Lock or Scroll Lock is set (this is the default). If flag_val is 1, always displays the boot prompt.

F2  FILENAME
F1  FILENAME
..etc...
F9  FILENAME
F10 FILENAME

Displays the indicated file on the screen when a function key is pressed at the boot prompt. This can be used to implement preboot online help (presumably for the kernel command line options). For backward compatibility with earlier releases, F10 can be also entered as F0. Note that there is currently no way to bind file names to F11 and F12.

9.5 Preparing the Target System for PXE Boot

Prepare the system's BIOS for PXE boot by including the PXE option in the BIOS boot order.

Warning
Warning: BIOS Boot Order

Do not place the PXE option ahead of the hard disk boot option in the BIOS. Otherwise this system would try to re-install itself every time you boot it.

9.6 Booting from CD or USB Drive Instead of PXE

You can also use a CD, DVD or USB drive with a small system image instead of booting via PXE. The necessary files will be loaded via NFS when the kernel and initrd are loaded. A bootable image can be created with mksusecd. This can be useful if the target machine does not support PXE boot.

Install it with sudo zypper in mksusecd. Use the following command to create a bootable ISO image:

tux > mksusecd --create image.iso \
--net=nfs://192.168.1.1:/srv/install/ARCH/OS_VERSION/SP_VERSION/cd1  \
/srv/tftpboot/EFI/ARCH/boot

Replace ARCH with the folder corresponding to the target system architecture. Also replace OS_version and SP_version according to your paths in Section 9.3, “Installing Files on TFTP Server”.

Instead of using an NFS server for the --net option, it is also possible to use an HTTP repository, for example the openSUSE repository:

tux > mksusecd --create image.iso \
--net=http://download.opensuse.org/tumbleweed/repo/oss/suse \
/srv/tftpboot/EFI/ARCH/boot

The image.iso can be written to a DVD or CD, or using dd to a USB stick:

root # dd if=image.iso of=/dev/USB_DEVICE

Replace USB_DEVICE with the device name of your USB stick. Check the device name thoroughly to ensure that you are not accidentally destroying data on another drive.

9.7 Using Wake-on-LAN for Remote Wakeups

Wake-on-LAN (WOL) is an Ethernet standard for remotely waking up a computer by sending it a wakeup signal over a network. This signal is called the "magic packet". Install WOL on client machines to enable remote wakeups, and on every machine you want to use for sending the wakeup signal. The magic packet is broadcast over UDP port 9 to the MAC address of the network interface on the client machine.

When computers are shutdown they usually are not turned all the way off, but remain in a low power mode. When the network interface supports WOL it listens for the magic packet wakeup signal when the machine is powered off. You can send the magic packet manually, or schedule wakeups in a cron job on the sending machine.

9.7.1 Prerequisites

WOL works with both wired and wireless Ethernet cards that support it.

You may need to enable WOL in your system BIOS/UEFI.

Check your BIOS/UEFI settings for PXE boot, and make sure it is disabled to prevent accidental re-installations.

Adjust your firewall to allow traffic over UDP port 9.

9.7.2 Verifying Wired Ethernet Support

Run the following command to see if a wired Ethernet interface supports WOL:

tux > sudo ethtool eth0 | grep -i wake-on
Supports Wake-on: pumbg
Wake-on: g

The example output shows that eth0 supports WOL, indicated by the g flag on the Supports Wake-on line. Wake-on: g shows that WOL is already enabled, so this interface is ready to receive wakeup signals. If WOL is not enabled, enable it with this command:

tux > sudo ethtool -s eth0 wol g

9.7.3 Verifying Wireless Interface Support

Wakeup-over-wifi, or WoWLAN, requires a wireless network interface that supports WoWLAN. Test it with the iw, command, which is provided by the iw package:

tux > sudo zypper in iw

Find your device name:

tux > sudo iw dev
phy#0
        Interface wlan2
                ifindex 3
                wdev 0x1
                addr 9c:ef:d5:fe:01:7c
                ssid accesspoint
                type managed
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm

In this example, the device name to use for querying WoWLAN support is phy#0. This example shows that it is not supported:

tux > sudo iw phy#0 wowlan show
command failed: Operation not supported (-95)

This example shows an interface that supports WoWLAN, but it is not enabled:

tux > sudo iw phy#0 wowlan show
WoWLAN is disabled

Enable it:

tux > sudo iw phy#0 wowlan enable magic-packet
WoWLAN is enabled:
* wake up on magic packet

9.7.4 Installing and Testing WOL

To use WOL, install the wol package on the client and sending machines:

tux > sudo zypper in wol

Get the MAC address of the network interface on the client machine:

tux > sudo ip addr show eth0|grep ether
link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff

In the example output, 7c:ef:a5:fe:06:7c is the MAC address.

Shut down your client machine, and send it a wakeup signal from another computer on the same subnet:

tux > wol 7c:ef:a5:fe:06:7c

When your target machine and second device are on the same network but in different subnets, specify the broadcast address for your target machine:

tux > wol -i 192.168.0.63 7c:ef:a5:fe:06:7c

When you are satisfied with your configuration, add the following line to /etc/crontab, substituting the correct name of your network interface, to enable WOL on the client machines after every startup:

@reboot root /usr/bin/ethtool -s eth0 wol g

Because WOL relies on broadcast domains the sending machine must be on the same network, though it can be in a different network segment.

It is possible to send the magic packet from a different network. One way is with port forwarding, if your router supports port forwarding to a broadcast address. A more secure method is to SSH to a host inside your network, and send the magic packet from there.