Dies ist die Dokumentation einer alten opsi-Version. Die Dokumentation für die aktuelle Version 4.3 finden Sie hier.

opsi mit UEFI/GPT

Aktuelle Rechner werden in der Regel mit UEFI (Unified Extensible Firmware Interface) ausgeliefert. Die Firmware-Schnittstelle ist der BIOS-Nachfolger (Basic Input/Output System), bietet mehr Flexibilität und eine verbesserte Leistung: UEFI unterstützt 64-Bit-Prozessoren und dank GPT (GUID Partition Table) Festplatten mit mehr als 2 TByte Speicherkapazität. GPT ist der Nachfolger von MBR (Master Boot Record) und erlaubt theoretisch beliebig viele Partitionen auf einer einzigen Festplatte (128 Partitionen sollten alle Betriebssysteme unterstützen).

Häufig lässt sich UEFI in den so genannten Legacy-Modus (also den alten Startmodus) umschalten. Damit ist es dann möglich, ältere Betriebssysteme oder Software zu installieren, die nicht mit UEFI kompatibel sind. Es gibt aber zunehmend Geräte, die keinen Legacy-Modus bieten (UEFI-only). Diese lassen sich in opsi-Umgebungen nicht per PXE Boot verwalten. Um auch solche Rechner zu integrieren bzw. um die Vorteile von UEFI nutzen zu können, haben wir diese Erweiterung entwickelt. Sie erlaubt es, BIOS- und UEFI-Clients nebeneinander zu verwalten.

Eine Liste von Netboot-Produkten mit UEFI-Unterstützung und Secure-Boot-Unterstützung finden Sie am Ende dieses Kapitels.

Was ist anders bei UEFI?

UEFI ist ungleich mächtiger als das herkömmliche BIOS. Im Prinzip ist das Unified Extensible Firmware Interface ein eigenes kleines Mini-Betriebssystem. Ohne groß ins Detail zu gehen, finden Sie hier einige Punkte, die für den Systemverwalter von besonderer Bedeutung sind:

  • UEFI und klassisches BIOS existieren teilweise nebeneinander — mal lässt sich eines von beiden deaktivieren, mal nicht. Manchmal ist UEFI mit CSM (Compatibility Support Module) implementiert, mal ohne. Netboot funktioniert oder funktioniert nicht — gerade im Hinblick auf Client-Management-Systeme ist das natürlich wichtig.

  • Im klassischen BIOS sind BIOS und die Einstellungen des Betriebssystems (in aller Regel) getrennt. Das heißt, dass auch die Bootreihenfolge festgelegt ist und vom Betriebssystem nicht geändert werden kann. Bei UEFI ist das anders: Das Betriebssystem kann die Bootreihenfolge ändern (und macht davon in der Regel auch Gebrauch). Auch das hat Auswirkungen auf die Netboot-Anbindung der Rechner an das Client-Management-System.

  • UEFI enthält einen eigenen Bootmanager mit den Starteinträgen der Betriebssysteme. Betriebssysteme können die Reihenfolge der Einträge verändern (siehe oben). Das vereinfacht ein Nebeneinander unterschiedlicher Betriebssysteme auf dem Gerät, weil die Bootloader sich nicht mehr gegenseitig überschreiben.

  • UEFI ist in 32 oder 64 Bit implementiert. Damit ist dann auch die Architektur des Betriebssystems vorgegeben, das heißt, dass ein 32-Bit-OS nicht auf einem 64-Bit-UEFI installierbar ist (und umgekehrt).

  • Secure Boot ist eine UEFI-Funktion, die dafür sorgt, dass ein Windows-Start nur dann funktioniert, wenn bestimmte Firmware-Elemente (z. B. der Bootloader) nicht durch Dritte verändert wurden. Secure Boot ist seit Windows 8 standardmäßig aktiviert.

  • Partitionierung mit GPT und zusätzliche Partitionen für die Bootloader:

    • 1. Partition: EFI System Partition (ESP) 100 bis 260 MByte; VFAT

    • 2. Partition: Microsoft Reserved Partiion (MSR) 32 bis 128 MByte; NTFS

    • Ab hier kommen die eigentlichen OS-Partitionen

Was ist anders bei GPT?

GPT (GUID Partition Table) ersetzt die bisherigen MBR-Partitionstabellen. GPT ist Bestandteil der UEFI-Spezifikation.

Wesentliche Merkmale für den Systemadministrator sind:

  • Wegfall der 2-TByte-Grenze (jetzt 8 Zebibytes bzw. 9,6 Zettabytes, also 9.600 Millionen Terabytes)

  • Theoretisch beliebig viele Partitionen (128 sollten alle OS unterstützen; keine Unterscheidung zwischen primären, erweiterten und logischen Partitionen)

  • Geänderte Partitionstypen (GUIDs)

  • Neu: Partitions-GUIDs

  • Neu: Partitions-Attribute (nur lesen/read-only, versteckt/hidden usw.)

  • Andere Werkzeuge zur Bearbeitung: gdisk

Prinzipiell lässt sich GPT auch ohne UEFI verwenden. UEFI funktioniert aber nur mit GPT. Wird UEFI verwendet, so kommen ein bis zwei zusätzliche Partitionen hinzu:

  1. EFI System Partition, ESP (hier liegen die Bootloader)

  2. Microsoft Reserved Partition, MSR

Voraussetzungen

Dieses Modul ist momentan eine kostenpflichtige Erweiterung. Das heißt, dass Sie eine Freischaltdatei benötigen. Sie erhalten diese, nachdem Sie die Erweiterung gekauft haben. Zu Evaluierungszwecken stellen wir Ihnen kostenlos eine zeitlich befristete Freischaltung zur Verfügung. Bitte kontaktieren Sie uns dazu per E-Mail.

Weitere Details hierzu finden Sie im Kapitel opsi-Erweiterungen.

Die Erweiterung setzt opsi 4.1 oder neuer voraus. Die folgende Tabelle listet die benötigten opsi-Pakete auf:

Tabelle 1. Benötigte Pakete
opsi-Paket Version

Netboot-Produkte

>=4.1

opsi-Server

>=4.1

opsipxeconfd

>=4.1.1.20-3

opsi-linux-bootimage

>=20200506

Allgemeine Anforderungen

opsi 4.0.5 unterstützt nur 64 Bit UEFI-Installationen.

Für die Installation über PXE Boot (Preboot eXecution Environment) benötigen Sie ein UEFI-taugliches WinPE_UEFI (eine Variante von Windows PE, die speziell für den Start auf Systemen mit UEFI-Firmware konzipiert wurde). Oft enthält Windows PE (Windows Preinstallation Environment) bereits UEFI-Unterstützung (Ordner EFI und Datei winpe/bootmgr.efi des opsi-Netboot-Produkts). Andernfalls erstellen Sie mit DISM (Deployment Image Servicing and Management) ein aktuelles Windows PE (siehe Abschnitt Manuelles Erstellen eines PE). Ein UEFI-WinPE gehört in den Ordner winpe_uefi des opsi-Netboot-Produkts.

Sofern es ein Windows PE für beide Bootmodi gibt, können Sie winpe_uefi durch einen symbolischen Link auf winpe ersetzen.

Einen externen DHCP-Server müssen Sie so konfigurieren, dass er PXE Boot über den opsi-Server ermöglicht. Tragen Sie linux/pxelinux.cfg/shimx64.efi.signed als Bootdatei ein.

In der Management-Oberfläche opsi-configed setzen Sie für UEFI-Clients ein Häkchen bei UEFI-Boot (seit Version 4.0.5.8.1). Alternativ konfigurieren Sie den Hostparameter clientconfig.dhcpd.filename für die Clients und tragen dort die Bootdatei ein:

clientconfig.dhcpd.filename=linux/pxelinux.cfg/shimx64.efi.signed

Sie können die Einstellung auch über das folgende Kommando vornehmen:

opsi-admin -d method configState_create "clientconfig.dhcpd.filename" "<Host-ID>" "linux/pxelinux.cfg/shimx64.efi.signed"
Falls Ihr opsi-Server bereits frühere Paketversionen installiert hatte, müssen Sie eventuell die Datei /etc/opsi/opsipxeconfd.conf anpassen, da der UEFI-Bootloader sonst inkompatibel zur Named Pipe ist.

Ändern Sie diese Zeile

uefi netboot config template x64 = /tftpboot/linux/pxelinux.cfg/install-elilo-x64

so ab, dass hier Folgendes steht:

uefi netboot config template x64 = /tftpboot/linux/pxelinux.cfg/install-grub-x64

BIOS-Einstellungen

Die Menüs der unterschiedlichen BIOS-Versionen verwenden unterschiedliche Begriffe und Bezeichnungen. Wählen Sie im Zweifelsfall die Einstellung, die zu Ihrem Rechner passt:

  • Secure Boot deaktivieren: Die Einstellung finden Sie oft im Bereich Boot oder Startup, manchmal auch im Bereich Security. Weitere Informationen dazu finden Sie im Kapitel Secure-Boot-Unterstützung.

  • BIOS im UEFI-Modus: Wenn Sie die Wahl haben zwischen UEFI only, Legacy only oder Both, nehmen Sie UEFI only. Steht der Rechner auf Both, und lässt sich das nicht abschalten, kann es trotzdem sein, dass die Erweiterung funktioniert. Gibt es den Eintrag Legacy Support, so deaktivieren sie diesen. CSM Support in Verbindung mit UEFI only kann aktiviert bleiben, wenn Sie keine andere Wahl haben. UEFI Network Boot aktivieren Sie; der Eintrag kann auch Network Stack heißen und unterhalb von UEFI liegen. Haben Sie an dieser Stelle die Möglichkeit, die Einstellung gesondert für IPv4 und IPv6 zu setzen, ist IPv4 die richtige Wahl.

opsi-Unterstützung für UEFI/Netboot

Unsere Erweiterung ermöglicht die Anbindung von Clients über UEFI/Netboot. Es ist geplant, dieses Modul im Laufe der nächsten Jahre beständig weiterzuentwickeln. Zu der Erweiterung gehören die folgenden Komponenten:

  • Anpassung des netbootfähigen UEFI-Bootloaders GRUB2 an opsi bzw. die Client-Management Bedürfnisse

  • neuer opsipxeconfd, der neben Konfigurationsdateien für das bisherige PXE Boot auch Konfigurationsdateien für den opsi-GRUB2 bereitstellt

  • Bereitstellung neuer (64 Bit) opsi-Linux-Bootimages mit Werkzeugen für UEFI- und GPT-Management

  • Umbau aller Netboot-Produkte zur Betriebssystem-Installation (Windows/Linux) mit Unterstützung von UEFI/GPT (ausgenommen Betriebssysteme, die selbst keine UEFI-Unterstützung haben)

  • Speichern der Einstellung, ob der opsi-Server einen Client als UEFI-Client behandeln soll
    (clientconfig.dhcpd.filename=linux/pxelinux.cfg/shimx64.efi.signed)

  • Unterstützung einer Software-gesteuerten Umschaltung auf UEFI-Netboot

Soweit das Firmware Interface es ermöglicht (es also einen aktivierbaren Netboot-Eintrag im BIOS gibt), speichert der opsi-Server das UEFI-Netboot-Label des Clients (als clientconfig.uefinetbootlabel). Das erlaubt opsi-Produkten das Umstellen der Bootreihenfolge auf Netboot für den nächsten Neustart. Diese Technik ist in verschiedenen opsi-Produkten implementiert, beispielsweise im Produkt opsi-uefi-netboot. Es versucht, auf Netboot umzustellen und dann einen Reboot auszulösen. Wird kein UEFI-Netboot-Label gefunden oder handelt es sich nicht um einen UEFI-Rechner, wird nur ein Reboot ausgelöst. Dieses Produkt funktioniert unter Windows und Linux.

Installation

Alle notwendigen Pakete sind ab der opsi-Version 4.0.5 automatisch installiert.

Konfiguration des DHCP-Servers

Um UEFI-Clients per PXE zu booten, benötigen Sie einen entsprechenden Eintrag in der Bootdatei:

clientconfig.dhcpd.filename=linux/pxelinux.cfg/shimx64.efi.signed

Da in der Praxis vermutlich beide Varianten in der opsi-Umgebung vorhanden sind, muss der DHCP-Server den Clients die richtige Bootdatei auf dem opsi-Server zuweisen. Die nächsten beiden Abschnitte zeigen Konfigurationsbeispiele für einen DHCP-Server unter Linux und Windows.

Beispiel: Konfiguration unter Linux (ISC DHCP-Server)

Die Konfiguration des DHCP-Servers befindet sich in der Datei /etc/dhcp/dhcpd.conf. So richten Sie in dieser Datei eine Weiche ein:

filename "linux/pxelinux.0";

# Das ist die UEFI Detection:
if substring (option vendor-class-identifier , 19,1 ) = "0" {
        log (info, "pxe client");
        filename "linux/pxelinux.0";
}
else if substring (option vendor-class-identifier , 19,1 ) = "6" {
        log (info, "efi32 client");
        filename "linux/pxelinux.cfg/elilo-x86.efi";
}
else if substring (option vendor-class-identifier , 19,1 ) = "7" {
        log (info, "efi64 client");
        filename "linux/pxelinux.cfg/shimx64.efi.signed";
}
else {
        log (info, concat ( "Unhandled vendor class Arch: ", substring (option
        vendor-class-identifier , 19,1 )));
}
Im Univention-Forum gibt es eine Anleitung, wie Sie eine DHCP-Weiche unter Univention Corporate Server einrichten: https://help.univention.com/t/how-to-configure-a-dhcp-switch-for-uefi-and-non-uefi-boot/9931

Beispiel: Konfiguration unter Windows Server 2012 R2

Tragen Sie die Bootdatei für UEFI 64 Bit als Standard ein. Dazu passen Sie die DHCP-Optionen 66 und 67 wie folgt an:

  • 066 Hostname des Startservers: IP-Adresse des opsi-Servers

  • 067 Name der Startdatei: linux/pxelinux.cfg/shimx64.efi.signed

Zur Unterscheidung der Clients definieren Sie auf dem DHCP-Server eine Herstellerklasse:

  Herstellerklasse definieren
  Neue Herstellerklasse hinzufügen
  Klasse bearbeiten
    Anzeigename: Legacy BIOS
    Asci: PXEClient:Arch:00000:UNDI:002001

Ordnen Sie die vordefinierten Optionen dem Hestellerklasse-Identifier zu:

  Vordefinierte Optionen einstellen
  Optionen hinzufügen
    Optionsklasse: Legacy BIOS
    Hinzufügen
  Optionstyp anpassen
    Name: Legacy BIOS
    Datentyp: Zeichenfolge
    Code: 60
    Beschreibung:  PXEClient Class Legacy BIOS
  Vordefinierte Optionen und Werte
    Zeichenfolge: PXEClient

Definieren Sie eine DHCP-Richtlinie, welche die Bootdatei für PXE Boot (BIOS) der Herstellerklasse zuordnet:

  Neue Richtlinie
    Richtlinienname: PXE BootFile Legacy BIOS
    weiter
  Bedingungen hinzufügen
    Kriterien: Herstellerklasse
    Operator: ist gleich
    Wert: Legacy BIOS
    hinzufügen
  Möchten Sie einen IP-Adressbereich für die folgende Richtlinie konfigurieren: Nein
  Herstellerklasse: DHCP Standard Options
    067 Name der Startdatei
    Dateieingabe
      Zeichenfolgenwert: linux/pxelinux.0

In den Bereichsoptionen gibt es zwei Einträge für die Startdatei, die in einem Fall an eine Richtlinie gekoppelt ist, um BIOS-Clients zu erkennen:

067 Name der Startdatei: linux/pxelinux.cfg/shimx64.efi.signed	Richtlinie: Keine
067 Name der Startdatei: linux/pxelinux.0	Richtlinie: PXE BootFile Legacy BIOS

opsipxeconfd-Konfiguration

Ab Version 4.0.7.7 ist es möglich, den Pfad der als Vorlage verwendeten Dateien über die Konfigurationsdatei opsipxeconfd.conf anzupassen. Dazu geben Sie die Pfade über uefi netboot config template x86 bzw. uefi netboot config template x64 an.

Kriterien für ein "gutes" BIOS

Ob ein UEFI BIOS den Anforderungen eines Client-Management-Systems wie opsi genügt, hängt von unterschiedlichen Kriterien ab.

Diese Kriterien sagen nichts über die Qualität der Hardware aus — vielmehr geht es darum, wie gut es per Netboot gewartet werden kann.

Die folgende Tabelle zeigt ein paar beispielhafte Vergleiche:

Tabelle 2. Beispiele: UEFI-BIOS-Unterschiede
Lenovo Twist MS-Surface Dell Venue 11

UEFI pur

supported

supported

supported

UEFI + CSM

supported

unsupported

supported

Legacy

supported

unsupported

supported

Both

supported

unsupported

unsupported

UEFI Netboot

supported

supported

supported

Aktivierbarer Eintrag

supported

unsupported

supported

Netboot ohne Interaktion

supported

unsupported

supported

supported: Supported unsupported: Unsupported develop: Under Development discontinued: Discontinued

"Aktivierbarer Eintrag" heißt in diesem Zusammenhang, dass sich Netboot über die Standardsoftware für den nächsten Reboot aktivieren lässt, "Netboot ohne Interaktion" heißt, dass ein aktivierter Netboot-Eintrag beim Reboot ausgeführt wird und dazu keine Interaktion (z. B. Tastenkombinationen, [F12] usw.) von Seiten des Benutzers nötig ist. Nur wenn diese Voraussetzung erfüllt ist, können bestimmte opsi-Produkte einen Netboot auslösen. Das ist für die Automatisierung von Abläufen von großer Bedeutung. Ein Produkt, in dem das implementiert ist, ist das Localboot-Produkt opsi-uefi-netboot für Windows und Linux.

Technische Hintergründe

Die nächsten Abschnitte dienen als Wissensbasis zum Umgang mit UEFI/GPT (händisch oder geskriptet). Sie sind nicht erforderlich, um zu verstehen, wie opsi mit UEFI/GPT arbeitet.

UEFI-Hintergründe

Um die UEFI-Bootloader-Einträge unter Linux zu manipulieren, können Sie das Programm efibootmgr verwenden. Der Parameter -v gibt eine Liste der Einträge aus:

efibootmgr -v
BootCurrent: 000D
Timeout: 0 seconds
BootOrder: 0012,0011,000D,0010,000B,0009,0007,0008,000A,000C
Boot0000  Setup
Boot0001  Boot Menu
(..)
Boot0007* USB CD	030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0008* USB FDD	030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0009* ATA HDD0	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000D* PCI LAN	030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0010* ubuntu	HD(1,800,31801,faffb7b9-bdf9-4767-b475-0b8aee68d3ac)File(\EFI\ubuntu\grubx64.efi)
Boot0011* opsitempwinpe	HD(4,3c72800,7cf801,dc1cea68-a296-4fb8-a97a-263227ed86f4)File(\EFI\boot\bootx64.efi)
Boot0012* Windows Boot Manager	HD(1,800,31801,5e4ffde2-3e25-42dd-b0f7-fcb7ee5d2b20)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................

Unter Windows manipulieren Sie die UEFI-Bootloader-Einträge mit dem Programm bcdedit. Eine Liste der Einträge geben Sie so aus:

bcdedit /enum firmware

Firmware Boot Manager
- - - - - - - - - - - - - - -
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
                        {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
                        {11a8b986-99df-11e3-ae5c-b888e3e3cbb4}
Windows-Start-Manager
- - - - - - - - - - - - - - -
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b971-99df-11e3-ae5c-b888e3e3cbb4}
description             Setup
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b972-99df-11e3-ae5c-b888e3e3cbb4}
description             Boot Menu
(...)
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b978-99df-11e3-ae5c-b888e3e3cbb4}
description             USB CD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b979-99df-11e3-ae5c-b888e3e3cbb4}
description             USB FDD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b97a-99df-11e3-ae5c-b888e3e3cbb4}
description             ATA HDD0
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
description             PCI LAN
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
identifier              {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
device                  partition=X:
path                    \EFI\boot\bootx64.efi
description             opsitempwinpe

Mit beiden Programmen, efibootmgr und bcdedit, können Sie neue Einträge erstellen, vorhandene Löschen, nextboot setzen und die Bootreihenfolge ändern.

Beispiel: Eintrag für den nächsten Boot setzen:

  • Linux:

efibootmgr /bootnext <hexId>

  • Windows:

bcdedit /set {fwbootmgr} bootsequence <GUID>

GPT-Hintergründe

GPT kennt "neue" Partitionstypen, die an die bisher bekannten angelehnt sind. So wird beispielsweise aus dem Partitionstyp 07 (für NTFS) unter GPT 0700. Analog dazu heißen die beiden Linux-Partitionstypen 82 und 83 entsprechend 8200 und 8300. Um die Liste der bekannten Partitionstypen anzuzeigen, können Sie den folgenden Befehl eingeben:

# sgdisk -L
0700 Microsoft basic data  0c01 Microsoft reserved    2700 Windows RE
4100 PowerPC PReP boot     4200 Windows LDM data      4201 Windows LDM metadata
7501 IBM GPFS              7f00 ChromeOS kernel       7f01 ChromeOS root
7f02 ChromeOS reserved     8200 Linux swap            8300 Linux filesystem
8301 Linux reserved        8302 Linux /home           8400 Intel Rapid Start
8e00 Linux LVM             a500 FreeBSD disklabel     a501 FreeBSD boot
a502 FreeBSD swap          a503 FreeBSD UFS           a504 FreeBSD ZFS
a505 FreeBSD Vinum/RAID    a580 Midnight BSD data     a581 Midnight BSD boot
a582 Midnight BSD swap     a583 Midnight BSD UFS      a584 Midnight BSD ZFS
a585 Midnight BSD Vinum    a800 Apple UFS             a901 NetBSD swap
a902 NetBSD FFS            a903 NetBSD LFS            a904 NetBSD concatenated
a905 NetBSD encrypted      a906 NetBSD RAID           ab00 Apple boot
af00 Apple HFS/HFS+        af01 Apple RAID            af02 Apple RAID offline
af03 Apple label           af04 AppleTV recovery      af05 Apple Core Storage
be00 Solaris boot          bf00 Solaris root          bf01 Solaris /usr & Mac Z
bf02 Solaris swap          bf03 Solaris backup        bf04 Solaris /var
bf05 Solaris /home         bf06 Solaris alternate se  bf07 Solaris Reserved 1
bf08 Solaris Reserved 2    bf09 Solaris Reserved 3    bf0a Solaris Reserved 4
bf0b Solaris Reserved 5    c001 HP-UX data            c002 HP-UX service
ea00 Freedesktop $BOOT     eb00 Haiku BFS             ed00 Sony system partitio
ef00 EFI System            ef01 MBR partition scheme  ef02 BIOS boot partition
fb00 VMWare VMFS           fb01 VMWare reserved       fc00 VMWare kcore crash p
fd00 Linux RAID
Tatsächlich sind die hier gelisteten Partitionstypen nur "Abkürzungen" für die eigentlich verwendeten GUIDs, die dem Partitionierungs-Schema den Namen gegeben haben. So steht z. B. 0700 für Microsoft basic data und für die GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.

Eine vollständige Liste aller GUIDs finden Sie beispielsweise in der Wikipedia:

Die beiden Werkzeuge gdisk und sgdisk nutzen eine interne Tabelle zum Ersetzen unbekannter Partitionstypen. So gibt es etwa für den "alten" Partitionstyp für VFAT32 0b keine Entsprechung der Form 0b00. Wenn Sie aber 0b00 als Typ an sgdisk übergeben, ersetzt das Tool ihn durch 0700 — wahrscheinlich nach dem Motto "VFAT32, das wird wohl eine MS-Daten-Partition sein …​"

GPT-Partitionen kennen Attribute. Die nächste Tabelle zeigt eine Liste der zur Zeit bekannten Attribute:

Tabelle 3. Attribute von GPT-Partitionen

Wert

Beschreibung

Attributwert (sgdisk --info/diskpart gpt attribute)

0

Systempartition (system partition)

0000000000000001

1

Verstecke die Partition vor EFI (hide from EFI)

0000000000000002

2

Legacy Bootflag (legacy BIOS bootable)

0000000000000004

60

Nur lesen (read-only)

1000000000000000

62

Versteckt (hidden)

4000000000000000

63

Nicht Einhängen (do not automount)

8000000000000000

Um die Attribute zu setzen, verwenden Sie unter Linux sgdisk -A (--attributes) und unter Windows das Programm diskpart und das Kommando gpt attributes.

Beispiele:

sgdisk -t 1:0700 --attributes 1:clear:63 --attributes 1:set:62 -p /dev/sda
select disk 0
select partition 1
gpt attributes=0x0000000000000000

Um mit sgdisk die Partitionstabelle anzuzeigen, verwenden Sie den Parameter -p (--print):

sgdisk -p /dev/sda

Detaillierte Infos zu einer Partition (1) erhalten Sie über --info=:

sgdisk --info=1 /dev/sda

opsi-Roadmap für UEFI/GPT

  • UEFI: 32-Bit-Unterstützung

  • Andere netbootfähige UEFI Bootloader (GRUB2)

Netboot-Produkte mit UEFI-Unterstützung

Netboot Product opsi 4.2/4.1 Remark

opsi-clonezilla

supported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Tabelle 4. Standard Windows
Netboot Product opsi 4.2/4.1 Remark

win2022

supported

win2019

supported

win2016

supported

win2012-r2

supported

win2012

supported

win2008-r2

supported

win11-x64

supported

win10-x64

supported

win10

unsupported

win81-x64

supported

win81

unsupported

win7-x64

supported

win7

unsupported

winvista-x64

unsupported

winvista

discontinued

win2008-x64

discontinued

winxp

unsupported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Tabelle 5. Linux
Netboot Product opsi 4.2/4.1 Remark

ubuntu

supported

ubuntu22-04

supported

ubuntu20-04

supported

ubuntu18-04

discontinued

ubuntu16-04

discontinued

ubuntu14-04

unsupported

mint21-2

supported

mint21-1

supported

mint21

supported

mint20-3

supported

mint20-2

supported

mint20-1

supported

debian

supported

debian12

supported

debian11

supported

debian10

supported

debian9

discontinued

centos8

discontinued

alma9

supported

alma8

supported

rocky9

supported

rocky8

supported

oraclelinux9

supported

oraclelinux8

supported

centos70

discontinued

redhat9

develop

redhat8

develop

redhat70

develop

opensusel15-5

supported

opensusel15-4

supported

opensusel15-3

discontinued

sles15sp5

develop

sles15sp4

develop

sles15sp3

develop

sles15sp2

develop

sles15sp1

develop

sles15sp2

develop

sles12sp4

develop

sles12sp3

develop

sles12sp2

discontinued

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Tabelle 6. opsi-local-image
Netboot Product opsi 4.1/4.2 Remark

opsi-local-image-prepare

supported

opsi-local-image-backup

supported

opsi-local-image-restore

supported

opsi-local-image-wim-capture

supported

opsi-local-image-win*

supported

opsi-local-image-ubuntu

supported

opsi-local-image-opensuse13-2

discontinued

opsi-local-image-opensusel42-2

discontinued

opsi-vhd-win10-x64

supported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Netboot-Produkte mit Secure-Boot-Unterstützung

Tabelle 7. Windows
Netboot Product opsi 4.2

win2022

supported

win2019

supported

win2016

supported

win11-x64

supported

win10-x64

supported

win2012-r2

supported

win81-x64

supported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Tabelle 8. Linux
Netboot Product opsi 4.2 Remark

ubuntu

develop

ubuntu18-04

supported

since ubuntu18-04_4.1.0.2-1

ubuntu20-04

supported

since ubuntu20-04_4.1.0.2-1

ubuntu22-04

supported

debian

develop

debian10

supported

since debian10_4.1.0.3-1

debian11

supported

debian12

supported

opensusel15-3

discontinued

opensusel15-4

supported

opensusel15-5

supported

alma8

supported

alma9

supported

rocky8

supported

rocky9

supported

oraclelinux8

supported

oraclelinux9

supported

redhat8

unsupported

redhat9

unsupported

sles12sp2

discontinued

sles12sp4

unsupported

sles12sp4

unsupported

sles12sp5

unsupported

sles15sp1

unsupported

sles15sp2

unsupported

sles15sp3

unsupported

sles15sp4

unsupported

sles15sp5

unsupported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Tabelle 9. opsi-local-image
Netboot Product opsi 4.2

opsi-local-image-prepare

supported

opsi-local-image-backup

supported

opsi-local-image-restore

supported

opsi-local-image-wim-capture

supported

opsi-local-image-win10-x64

supported

opsi-vhd-win10-x64

supported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued