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:
-
EFI System Partition, ESP (hier liegen die Bootloader)
-
Microsoft Reserved Partition, MSR
Voraussetzungen
| Dieses Modul was bis opsi 4.2 eine kostenpflichtige Erweiterung. Mit opsi 4.3 haben wir das Modul freigegeben. |
Die Erweiterung setzt opsi 4.1 oder neuer voraus. Die folgende Tabelle listet die benötigten opsi-Pakete auf:
| opsi-Paket | Version |
|---|---|
Netboot-Produkte |
>=4.1 |
opsi-Server |
>=4.1 |
|
>=4.1.1.20-3 |
|
>=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-Produktes). 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-Produktes.
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 opsi/opsi-linux-bootimage/loader/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=opsi/opsi-linux-bootimage/loader/shimx64.efi.signedSie können die Einstellung auch über das folgende Kommando vornehmen:
opsi-admin -d method configState_create "clientconfig.dhcpd.filename" "<Host-ID>" "opsi/opsi-linux-bootimage/loader/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-x64so ab, dass hier Folgendes steht:
uefi netboot config template x64 = /tftpboot/opsi/opsi-linux-bootimage/cfg/install-grub-x64BIOS-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=opsi/opsi-linux-bootimage/loader/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.
Konfiguration des DHCP-Servers
Um UEFI-Clients per PXE zu booten, benötigen Sie einen entsprechenden Eintrag in der Bootdatei:
clientconfig.dhcpd.filename=opsi/opsi-linux-bootimage/loader/shimx64.efi.signedDa 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 "opsi/opsi-linux-bootimage/loader/opsi-netboot.bios";
# Das ist die UEFI Detection:
if substring (option vendor-class-identifier , 19,1 ) = "0" {
log (info, "pxe client");
filename "opsi/opsi-linux-bootimage/loader/opsi-netboot.bios";
}
else if substring (option vendor-class-identifier , 19,1 ) = "7" {
log (info, "efi64 client");
filename "opsi/opsi-linux-bootimage/loader/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:
opsi/opsi-linux-bootimage/loader/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: opsi/opsi-linux-bootimage/loader/opsi-netboot.bios
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: opsi/opsi-linux-bootimage/loader/shimx64.efi.signed Richtlinie: Keine 067 Name der Startdatei: opsi/opsi-linux-bootimage/loader/opsi-netboot.bios 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:
| Lenovo Twist | MS-Surface | Dell Venue 11 | |
|---|---|---|---|
UEFI pur |
|
|
|
UEFI + CSM |
|
|
|
Legacy |
|
|
|
Both |
|
|
|
UEFI Netboot |
|
|
|
Aktivierbarer Eintrag |
|
|
|
Netboot ohne Interaktion |
|
|
|
: Supported
: Unsupported
: Under Development
: 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 opsitempwinpeMit 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:
Wert |
Beschreibung |
Attributwert ( |
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/sdaselect disk 0
select partition 1
gpt attributes=0x0000000000000000Um mit sgdisk die Partitionstabelle anzuzeigen, verwenden Sie den Parameter -p (--print):
sgdisk -p /dev/sdaDetaillierte Infos zu einer Partition (1) erhalten Sie über --info=:
sgdisk --info=1 /dev/sdaNetboot-Produkte mit UEFI-Unterstützung
| Netboot Product | opsi 4.2/4.1 | Remark |
|---|---|---|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.2/4.1 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.2/4.1 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.1/4.2 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
Netboot-Produkte mit Secure-Boot-Unterstützung
| Netboot Product | opsi 4.2 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.2 | Remark |
|---|---|---|
|
|
|
|
|
since ubuntu18-04_4.1.0.2-1 |
|
|
since ubuntu20-04_4.1.0.2-1 |
|
|
|
|
|
|
|
|
|
|
|
since debian10_4.1.0.3-1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.2 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued