Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Server-Dokumentation / Bereitstellungshandbuch / Einrichten eines Installationsservers / Vorbereiten der Netzwerk-Boot-Umgebung
Gilt für SUSE Linux Enterprise Server 15 SP3

17 Vorbereiten der Netzwerk-Boot-Umgebung

In diesem Kapitel wird beschrieben, wie Sie einen DHCP- und einen TFTP-Server konfigurieren, die die erforderliche Infrastruktur für das Booten über PXE bilden.

SUSE® Linux Enterprise Server kann über PXE (Preboot Execution Environment) installiert werden. Die Client-Hardware muss das Booten über PXE unterstützen. Das Netzwerk muss einen DHCP-Server und einen TFTP-Server umfassen, die den Clients die erforderlichen Daten bereitstellen. Dieses Kapitel führt Sie durch die Einrichtung der erforderlichen Server.

Mit PXE werden lediglich ein Kernel und initrd gebootet. Hiermit können Sie in eine Installationsumgebung oder in Live-Systeme booten. Weitere Informationen zum Einrichten der Installationsquellen finden Sie in Kapitel 16, Einrichten einer Netzwerkinstallationsquelle.

In diesem Abschnitt werden die für komplexe Boot-Szenarien erforderlichen Konfigurationsschritte beschrieben. Er enthält zudem Konfigurationsbeispiele für DHCP, PXE-Boot, TFTP und Wake-on-LAN.

Bei den Beispielen wird davon ausgegangen, dass sich der DHCP-, TFTP- und NFS-Server auf demselben Rechner mit IP 192.168.1.1 befinden. Alle Dienste können sich problemlos auf verschiedenen Rechnern befinden. Ändern Sie die IP-Adressen in jedem Fall entsprechend.

17.1 Einrichten eines DHCP-Servers

Ein DHCP-Server weist Ihren Netzwerk-Clients sowohl dynamische (Abschnitt 17.1.1, „Dynamische Adressenzuweisung“) als auch statische (Abschnitt 17.1.2, „Zuweisen von statischen IP-Adressen“) IP-Adressen zu. Er gibt Server, Routen und Domänen bekannt. Für TFTP-Server gibt DHCP auch den Kernel und die initrd-Dateien an. Welche Dateien geladen werden hängt von der Architektur des Zielrechners ab und davon, ob Legacy-BIOS oder UEFI-Boot verwendet wird. Die Clients übermitteln ihren Architekturtyp in den DHCP-Anforderungen. Auf der Grundlage dieser Information entscheidet der DHCP-Server, welche Dateien der Client zum Booten herunterladen muss.

Warnung
Warnung: Fehler bei der PXE- und AutoYaST-Installation

Ab SUSE Linux Enterprise 15.0 treten unter bestimmten Umständen Fehler beim PXE-Boot und den AutoYaST-Installationen auf. Weitere Informationen und die Lösung finden Sie in Abschnitt 17.1.3, „Fehler bei der PXE- und AutoYaST-Installation“.

17.1.1 Dynamische Adressenzuweisung

Im folgenden Beispiel wird gezeigt, wie ein DHCP-Server eingerichtet wird, der dynamisch IP-Adressen zu Clients zuweist und Server, Router, Domänen und Boot-Dateien bekannt gibt.

  1. Melden Sie sich als root auf dem Computer an, der den DHCP-Server bereitstellt.

  2. Aktivieren Sie den DHCP-Server mit systemctl enable dhcpd.

  3. Fügen Sie einer Subnetzkonfiguration in der Konfigurationsdatei des DHCP-Servers, die sich unter /etc/dhcpd.conf befindet, folgende Zeilen hinzu:

    # 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";
     }
    }

    Diese Konfiguration verwendet das Teilnetz 192.168.1.0/24 mit DHCP, DNS und dem Gateway am Server mit der IP 192.168.1.1. Vergewissern Sie sich, dass alle IP-Adressen gemäß Ihres Netzwerk-Layouts geändert wurden. Weitere Informationen zu den in dhcpd.conf verfügbaren Optionen finden Sie auf der man-Seite dhcpd.conf.

  4. Starten Sie den DHCP-Server mit systemctl restart dhcpd neu.

17.1.2 Zuweisen von statischen IP-Adressen

Ein DHCP-Server kann auch statische IP-Adressen und Hostnamen zu Netzwerk-Clients zuweisen. Ein Anwendungsfall ist die Zuweisung von statischen Adressen zu Servern. Bei einem weiteren Anwendungsfall wird die Möglichkeit des Beitritts zum Netzwerk auf die Clients mit zugewiesenen statischen IP-Adressen beschränkt und es werden keine dynamischen Adressenpools zur Verfügung gestellt.

Bearbeiten Sie die obige DHCP-Konfiguration entsprechend des folgenden Beispiels:

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

Die Hostbestimmung weist einen Hostnamen zum Installationsziel zu. Um den Hostnamen und die IP-Adresse an einen bestimmten Host zu binden, müssen Sie die Hardware-Adresse (MAC) des Client angeben. Ersetzen Sie alle Variablen in diesem Beispiel durch die aktuellen Werte, die zu Ihrer Umgebung passen. Speichern Sie dann die Änderungen und starten Sie den DHCP-Server neu.

17.1.3 Fehler bei der PXE- und AutoYaST-Installation

Ab SUSE Linux Enterprise 15.0 und ISC DHCP 4.3.x treten unter bestimmten Umständen Fehler beim PXE-Boot und den AutoYaST-Installationen auf. Die PXE/AutoYaST-Installationen funktionieren nicht, wenn Ihr DHCP-Server keinen Pool von verfügbaren dynamischen IP-Adressen enthält und nur vordefinierte statische Adressen pro Client zulässt, und die Clients RFC 4361-Client-Kennungen senden. (Zufällig ausgewählte Rechner können dem Netzwerk nicht beitreten, wenn nur Adressen zugelassen werden, die bestimmten Netzwerk-Clients zugewiesen sind, und wenn keine dynamischen Adressenpools zur Verfügung gestellt werden.)

Wenn ein neues System in PXE startet, sendet es eine Anforderung an den DHCP-Server und erkennt sich selbst anhand einer Client-Kennung, die aus dem Hardwaretyp plus der MAC-Adresse der Netzwerkschnittstelle erstellt wurde. Dies ist eine RFC 2132 client-id. Der DHCP-Server bietet dann die zugewiesene IP-Adresse an. Als nächstes wird der Installations-Kernel geladen und er sendet eine weitere DHCP-Anforderung. Doch diese client-id ist anders und wird im RFC 4361-Format gesendet. Der DHCP-Server erkennt sie nicht als denselben Client und sucht nach einer freien dynamischen IP-Adresse. Da diese nicht verfügbar ist, wird der Installationsvorgang angehalten.

Die Lösung besteht darin, Clients so zu konfigurieren, dass sie RFC 2132-Client-IDs senden. Verwenden Sie zum Senden einer RFC 2132 client-id während der Installation linuxrc, um das folgende ifcfg-Kommando weiterzugeben:

ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67,
DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67

Die üblicherweise verwendete RFC 2132 DHCPv4 client-id im Ethernet setzt sich aus dem Hardwaretyp (01 für Ethernet) gefolgt von der Hardwareadresse (der MAC-Adresse) zusammen, wie zum Beispiel:

01:52:54:00:02:c2:67

Die RFC 4361 DHCPv4 client-id versucht das Problem, einen Rechner mit mehr als einer Netzwerkschnittstelle zu erkennen, zu korrigieren. Die neue DHCPv4 client-id hat dasselbe Format wie die DHCPv6 client-id. Sie beginnt mit dem Präfix 0xff anstelle des Hardwaretyps, gefolgt von der DHCPv6 IAID (der ID der Schnittstellenadressverknüpfung, die die Schnittstelle am Rechner beschreibt), gefolgt von der eindeutigen DHCPv6-Kennung (DUID), mit der der Rechner eindeutig gekennzeichnet ist.

Mit der oben genannten DUID auf Basis des Hardwaretyps und der Hardwareadresse wäre die neue RFC 4361 DHCPv4 client-id:

  • Unter Verwendung der letzten Bytes der MAC-Adresse der IAID: ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • Wenn die IAID eine einfache inkrementierte Zahl ist: ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

Das Feld xx:xx:xx:xx im DUID-Link-Layer-Zeitstempel (DUID-LLT) ist ein Erstellungszeitstempel. Ein DUID-Link-Layer (DUID-LL) (00:03:00:01:$MAC) hat keinen Zeitstempel.

Weitere Informationen zur Verwendung vonlinuxrc finden Sie im AutoYaST-Handbuch. Sehen Sie sich dazu auch man 4 initrd und die Dokumentation für die Optionen dhcp4 "create-cid", dhcp6 "default-duid" in man 5 wicked-config, wicked duid --help und wicked iaid --help an.

17.2 Einrichten eines TFTP-Servers

Im folgenden Verfahren wird beschrieben, wie der Server so vorbereitet wird, dass die Client-Rechner mit UEFI und BIOS dezentral mit den durch TFTP exportierten Dateien gebootet werden können.

17.2.1 Installieren eines TFTP-Servers

So installieren Sie einen TFTP-Server:

  1. Installieren Sie das Paket tftp.

    tux > sudo zypper in tftp
  2. Überprüfen Sie die tftpd-Konfiguration unter /etc/sysconfig/tftp und ergänzen oder ändern Sie die Optionen je nach Bedarf. Weitere Informationen finden Sie im man 8 tftpd. Beim TFTP-Daemon muss die Konfiguration nicht geändert werden. Das Standard-Stammverzeichnis für die Dateien lautet /srv/tftpboot.

  3. tftpd muss beim Booten gestartet werden; starten Sie es zum Einlesen der neuen Konfiguration erneut.

    tux > sudo systemctl enable tftp.socket
    tux > sudo systemctl restart tftp.socket

17.2.2 Installieren der Dateien zum Booten

SUSE Linux Enterprise Server stellt die erforderlichen Dateien zum Booten über PXE auf BIOS- oder UEFI-Rechnern bereit. Die folgenden Hardwarearchitekturen werden unterstützt:

  • AMD64/Intel 64

  • AArch64

  • POWER

  • IBM Z

Dateien, die von einer bestimmten Hardwarearchitektur gebootet werden müssen, sind in einem RPM-Paket enthalten. Installieren Sie die Dateien auf dem Rechner, auf dem der TFTP-Server ausgeführt wird:

tux > sudo zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE

Ersetzen Sie OS_VERSION durch die Versionsnummer Ihrer SUSE Linux Enterprise Server-Installation (z. B. SLE-15-SP3-x86_64) und ARCHITECTURE durch die Architektur Ihres Systems (z. B. x86_64). Der resultierende Text würde folgendermaßen aussehen: tftpboot-installation-SLE-15-SP3-x86_64. Führen Sie zypper se tftpboot zum Suchen nach allen verfügbaren Versionen und Architekturen aus.

Die Dateien werden unter /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE installiert. Sie können auch die Dateien für andere Versionen und Architekturen von SUSE Linux Enterprise Server in das Verzeichnis /srv/tftpboot kopieren.

Tipp
Tipp: Bedienen verschiedener Architekturen

Die Hardwarearchitektur von Client und Server kann variieren. Sie können beispielsweise einen AMD64/Intel 64 TFTP-Server ausführen und eine bootfähige Umgebung für AArch64-Clientrechner bereitstellen, indem Sie das Paket tftpboot-installation-SLE-15-SP3-aarch64 Paket verfügbar ist.

Anmerkung
Anmerkung: Bestehendes /srv/tftpboot/-Verzeichnis

Wenn das Verzeichnis /srv/tftpboot/ bereits auf Ihrem Rechner vorhanden ist, werden alle Dateien im Pfad /usr/share/tftpboot-installation/ installiert. Dies ist der Fall, wenn Sie Ihren PXE-Server von einer früheren SLES-Version upgraden.

Kopieren Sie die Dateien manuell von /usr/share/tftpboot-installation/ zu /srv/tftpboot/, um dieses Problem zu beheben. Entfernen Sie alternativ /srv/tftpboot/ und installieren Sie das Paket tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE Paket verfügbar ist.

17.2.3 Konfigurieren von PXELINUX

Öffnen Sie die Datei /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default in einem Editor. Ersetzen Sie den Pfad für den Parameter install gemäß Ihrer Einrichtung (siehe Kapitel 16, Einrichten einer Netzwerkinstallationsquelle). Ersetzen Sie außerdem TFTP_SERVER durch die IP-Adresse des TFTP-Servers. Einen Überblick über die PXELINUX-Konfigurationsoptionen finden Sie in Abschnitt 17.3, „PXELINUX-Konfigurationsoptionen“.

default linux

# install
label linux
  ipappend 2
  kernel boot/ARCHITECTURE/loader/linux
  append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH

display  message
implicit 1
prompt  1
timeout  50

Weitere Informationen zu den Boot-Parametern in der Zeile append finden Sie in Abschnitt 7.3, „Liste wichtiger Boot-Parameter“.

Wenn eine Meldung im Boot-Menü angezeigt werden soll, bearbeiten Sie gegebenenfalls /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message.

17.2.4 Vorbereiten des PXE-Boot-Vorgangs für EFI mit GRUB2

Normalerweise müssen die GRUB2-Konfigurationsdateien nicht geändert werden. Die Standardeinstellungen enthalten jedoch keine Netzwerkressource für das Installationssystem. Für eine vollständige Installation von SUSE Linux Enterprise Server über das Netzwerk müssen Sie den Parameter install in der Anweisung linuxefi der Datei /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg angeben. In Abschnitt 7.3.3, „Angeben der Installationsquelle“ finden Sie weitere Informationen über den Parameter install.

17.3 PXELINUX-Konfigurationsoptionen

Die hier aufgeführten Optionen sind eine Teilmenge der für die PXELINUX-Konfigurationsdatei verfügbaren Optionen.

APPEND OPTIONEN

Fügt der Kernel-Kommandozeile eine oder mehrere Optionen hinzu. Diese werden sowohl bei automatischen als auch bei manuellen Bootvorgängen hinzugefügt. Die Optionen werden an den Beginn der Kernel-Kommandozeile gesetzt und ermöglichen, dass explizit eingegebene Kernel-Optionen sie überschreiben können.

APPEND -

Hiermit wird nichts angehängt. APPEND mit einem Bindestrich als Argument in einem LABEL-Abschnitt kann zum Überschreiben einer globalen APPEND-Option verwendet werden.

DEFAULT KERNEL_OPTIONEN...

Legt die standardmäßige Kernel-Kommandozeile fest. Wenn PXELINUX automatisch gebootet wird, agiert es, als wären die Einträge nach DEFAULT in der Booteingabeaufforderung eingegeben worden, außer, dass die Option für das automatische Booten (boot) automatisch hinzugefügt wird.

Wenn keine Konfigurationsdatei vorhanden oder der DEFAULT-Eintrag in der Konfigurationsdatei nicht definiert ist, wird standardmäßig der Kernel-Name linux ohne Optionen verwendet.

IFAPPEND FLAG

Fügt eine bestimmte Option in die Kernel-Kommandozeile ein, abhängig vom Wert für FLAG. Die Option IFAPPEND ist nur unter PXELINUX verfügbar. Für FLAG ist ein Wert erforderlich, siehe Tabelle 17.1, „Generierte und hinzugefügte Optionen für Kernel-Kommandozeilen von IFAPPEND:

Tabelle 17.1: Generierte und hinzugefügte Optionen für Kernel-Kommandozeilen von IFAPPEND

Argument

Generierte Kernel-Kommandozeile/Beschreibung

1

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

Die Platzhalter werden auf der Grundlage der Eingaben vom DHCP/BOOTP- oder PXE-Boot-Server ersetzt.

Diese Option ist kein Ersatz für das Ausführen eines DHCP-Clients im gebooteten System. Ohne regelmäßige Verlängerung läuft die vom PXE BIOS erworbene Lease ab, sodass die IP-Adresse zur erneuten Verwendung durch den DHCP-Server verfügbar wird.

2

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

Mit dieser Option lässt sich eine Zeitüberschreitung vermeiden, wenn der Installationsserver die LAN-Schnittstellen einzeln nacheinander abfragt, bis er eine Antwort von einem DHCP-Server erhält. Ein initrd-Programm kann dabei ermitteln, von welcher Schnittstelle das System gebootet wurde. linuxrc liest diese Option aus und verwendet die erkannte Netzwerkschnittstelle.

4

SYSUUID=SYSTEM_UUID

Fügt UUIDs im Hexadezimalformat mit Kleinbuchstaben hinzu, siehe /usr/share/doc/packages/syslinux/pxelinux.txt

LABEL KENNUNG KERNEL IMAGE APPEND OPTIONEN...

Wenn KENNUNG als der zu bootende Kernel angegeben wird, soll PXELINUX stattdessen IMAGE booten und dabei die angegebenen APPEND-Optionen heranziehen. Diese Optionen ersetzen die im globalen Abschnitt der Datei vor dem ersten Kommando LABEL angegebenen Optionen. Die Vorgabe für IMAGE ist dieselbe wie für KENNUNG und wenn keine APPEND-Optionen angegeben sind, wird standardmäßig der globale Eintrag verwendet (sofern vorhanden). Es sind bis zu 128 LABEL-Einträge zulässig.

PXELINUX verwendet die folgende Syntax:

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Kennungen werden wie Dateinamen umgesetzt und müssen nach der Umsetzung (sogenanntes Mangling) eindeutig sein. Die beiden Kennungen v2.6.30 und v2.6.31 wären beispielsweise unter PXELINUX nicht unterscheidbar, da beide auf denselben DOS-Dateinamen umgesetzt würden.

Der Kernel muss kein Linux-Kernel sein. Auch ein Bootsektor oder eine COMBOOT-Datei ist möglich.

LOCALBOOT TYP

Wenn Sie unter PXELINUX LOCALBOOT 0 an Stelle einer KERNEL-Option angeben, bedeutet dies, dass diese bestimmte Kennung aufgerufen und die lokale Festplatte an Stelle eines Kernels gebootet wird.

Argument

Beschreibung

0

Führt einen normalen Bootvorgang aus

4

Führt einen lokalen Bootvorgang mit dem noch im Arbeitsspeicher vorhandenen UNDI-Treiber (Universal Network Driver Interface) aus

5

Führt einen lokalen Bootvorgang mit dem gesamten PXE-Stack, einschließlich des UNDI-Treibers aus, der sich im Arbeitsspeicher befindet

Alle anderen Werte sind nicht definiert. Wenn Sie die Werte für die UNDI- oder PXE-Stacks nicht wissen, geben Sie 0 an.

TIMEOUT ZEITLIMIT

Gibt in Einheiten von 1/10 Sekunde an, wie lange die Booteingabeaufforderung angezeigt werden soll, bevor der Bootvorgang automatisch gestartet wird. Das Zeitlimit wird aufgehoben, sobald der Benutzer eine Eingabe über die Tastatur vornimmt, da angenommen wird, dass der Benutzer die Eingabe des Kommandos abschließt. Mit einem Zeitlimit von Null wird das Zeitüberschreitungsoption deaktiviert (dies ist die Vorgabe). Der größtmögliche Wert für das Zeitlimit ist 35996 (etwas weniger als eine Stunde).

PROMPT flag_val

Wenn flag_val auf 0 gesetzt ist, wird die Booteingabeaufforderung nur angezeigt, wenn die Taste Umschalttaste oder Alt gedrückt wird oder die Feststelltaste oder die Taste Rollen gesetzt ist (dies ist die Standardeinstellung). Wenn flag_val 1 ist, wird die Booteingabeaufforderung immer angezeigt.

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

Zeigt die angegebene Datei auf dem Bildschirm an, wenn an der Booteingabeaufforderung eine Funktionstaste gedrückt wird. Mithilfe dieser Option kann auch die Preboot-Online-Hilfe implementiert werden (für die Kernel-Kommandozeilenoptionen). Aus Gründen der Kompabilität mit früheren Versionen kann F10 auch als F0 verwendet werden. Beachten Sie, dass derzeit keine Möglichkeit besteht, Dateinamen an F11 und F12 zu binden.

17.4 Vorbereiten des Zielsystems für PXE-Boot

Bereiten Sie das System-BIOS für PXE-Boot vor, indem Sie die PXE-Option in die BIOS-Boot-Reihenfolge aufnehmen.

Warnung
Warnung: BIOS-Bootreihenfolge

Die PXE-Option darf im BIOS nicht vor dem Boot-Parameter für die Festplatte stehen. Andernfalls würde dieses System versuchen, sich selbst bei jedem Booten neu zu installieren.

17.5 Verwenden von Wake-on-LAN für Fernaktivierungen

Wake-on-LAN (WOL) ist ein Ethernet-Standard zum Fernaktivieren eines Rechners durch Senden eines Aktivierungssignals über ein Netzwerk. Dieses Signal wird Magic Packet genannt. Installieren Sie WOL auf Client-Rechnern, um Fernaktivierungen zu ermöglichen, und auf jedem Rechner, den Sie zum Senden des Aktivierungssignals verwenden möchten. Das Magic Packet wird über UDP-Port 9 an die MAC-Adresse der Netzwerkschnittstelle auf dem Client-Rechner gesendet.

Beim Herunterfahren werden Rechner in der Regel nicht ganz ausgeschaltet, sondern verbleiben in einem Energiesparmodus. Wenn die Netzwerkschnittstelle WOL unterstützt, überwacht sie auf das Aktivierungssignal des Magic Packet, wenn das Gerät ausgeschaltet ist. Sie können das Magic Packet manuell senden oder Aktivierungen in einem Cron auf dem sendenden Rechner planen.

17.5.1 Voraussetzungen

WOL funktioniert sowohl mit kabelgebundenen als auch mit drahtlosen Ethernet-Karten, die es unterstützen.

Möglicherweise müssen Sie WOL in Ihrem System-BIOS/UEFI aktivieren.

Überprüfen Sie Ihre BIOS/UEFI-Einstellungen für PXE-Boot und stellen Sie sicher, dass es deaktiviert ist, um versehentliche Neuinstallationen zu verhindern.

Passen Sie Ihre Firewall so an, dass der Datenverkehr über UDP-Port 9 zugelassen wird.

17.5.2 Überprüfen der Unterstützung von kabelgebundenem Ethernet

Führen Sie folgendes Kommando aus, um festzustellen, ob eine kabelgebundene Ethernet-Schnittstelle WOL unterstützt:

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

Die Ausgabe im Beispiel zeigt, dass WOL von eth0 unterstützt wird, angezeigt durch das g-Flag in der Zeile Supports Wake-on. Wake-on: g zeigt an, dass WOL bereits aktiviert ist, sodass diese Schnittstelle bereit ist, Aktivierungssignale zu empfangen. Wenn WOL nicht aktiviert ist, aktivieren Sie es mit folgendem Kommando:

tux > sudo ethtool -s eth0 wol g

17.5.3 Überprüfen der Unterstützung für drahtlose Schnittstellen

Für Wakeup-over-wifi (WoWLAN) ist eine drahtlose Netzwerkschnittstelle erforderlich, die WoWLAN unterstützt. Testen Sie dies mit dem Kommando iw, das im iw Paket verfügbar ist:

tux > sudo zypper in iw

Suchen Sie den Gerätenamen:

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 diesem Beispiel lautet der Gerätename zum Abfragen der WoWLAN-Unterstützung phy#0. Dieses Beispiel zeigt, dass es nicht unterstützt wird:

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

Dieses Beispiel zeigt eine Schnittstelle, die WoWLAN unterstützt, aber nicht aktiviert ist:

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

Aktivieren Sie sie:

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

17.5.4 Installieren und Testen von WOL

Installieren Sie zur Verwendung von WOL das Paket wol am Client und den sendenden Rechnern:

tux > sudo zypper in wol

Installieren Sie wol-udev-rules auf Ihren Client-Rechnern. Dieses Paket installiert eine udev-Regel, die WOL automatisch beim Start aktiviert.

Ermitteln Sie die MAC-Adresse der Netzwerkschnittstelle auf dem Client-Rechner:

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

In der Ausgabe des Beispiels ist 7c:ef:a5:fe:06:7c die MAC-Adresse.

Fahren Sie Ihren Client-Rechner herunter und senden Sie ihm ein Aktivierungssignal von einem anderen Rechner im selben Teilnetz:

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

Wenn sich Ihr Zielgerät und das zweite Gerät zwar im selben Netzwerk, aber in unterschiedlichen Teilnetzen befinden, geben Sie die Broadcast-Adresse für Ihr Zielgerät an:

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

Da WOL auf Broadcast-Domänen beruht, muss sich der sendende Rechner im selben Netzwerk befinden, kann aber auch in einem anderen Netzwerksegment liegen.

Es ist möglich, das Magic Packet von einem anderen Netzwerk aus zu senden. Eine Möglichkeit ist die Portweiterleitung, wenn Ihr Router die Portweiterleitung auf eine Broadcast-Adresse unterstützt. Eine sicherere Methode ist es, sich über SSH mit einem Host innerhalb Ihres Netzwerks zu verbinden und das Magic Packet von dort aus zu senden.