opsi with UEFI/GPT
Today’s computers usually ship with UEFI (Unified Extensible Firmware Interface). This firmware interface is the BIOS successor (Basic Input/Output System) and offers more flexibility and improved performance: UEFI supports 64-bit processors and, thanks to GPT (GUID Partition Table), hard disks with more than 2 TByte storage capacity. GPT is the successor to MBR (Master Boot Record) and theoretically allows unlimited partitions on a single hard disk ( all operating systems should support 128 partitions).
UEFI can often be switched to the so-called legacy mode (i.e. the old start-up mode). This makes it possible to install older operating systems or software that are not compatible with UEFI. However, there are an increasing number of devices that do not offer legacy mode (UEFI-only). These cannot be managed in opsi environments via PXE boot. To integrate such computers as well and to be able to use the advantages of UEFI, we have developed this extension. It allows BIOS and UEFI clients to be managed side by side.
| A list of netboot products with UEFI support and secure boot support can be found at the end of this chapter. |
What is different with UEFI?
UEFI is considerably more powerful than the conventional BIOS. Basically, the Unified Extensible Firmware Interface is a little mini-operating system of its own. Without going into great detail, here are some points that are of particular importance for the system administrator:
-
UEFI and classic BIOS sometimes coexist — sometimes one of them can be disabled, sometimes not. Sometimes UEFI is implemented with CSM (Compatibility Support Module), sometimes without. Netboot works or doesn’t work — of course, this is particularly important when it comes to client management systems.
-
In the classic BIOS, BIOS and operating system settings are (usually) separate. This means that the boot order is also fixed and cannot be changed by the operating system. With UEFI it is different: the operating system can change the boot order (and usually makes use of it). This also affects the netboot connection of the computers to the client management system.
-
UEFI contains its own boot manager with the boot entries of the operating systems. Operating systems can change the order of the entries (see above). This simplifies a coexistence of different operating systems on the device because the boot loaders no longer overwrite each other.
-
UEFI is implemented in 32 or 64 bit. This then also specifies the architectur of the operating system, i.e. a 32 bit OS cannot be installed on a 64 bit UEFI (and vice versa).
-
Secure boot is a UEFI feature which ensures that booting Windows only works if certain firmware elements (e.g. the boot loader) have not been modified by third parties. Secure boot is enabled by default since Windows 8.
-
Partitioning with GPT and additional partitions for the boot loaders:
-
1st partition: EFI System Partition (ESP) 100 to 260 MB; VFAT
-
2nd partition: Microsoft Reserved Partiion (MSR) 32 to 128 MB; NTFS
-
Starting from here are the actual OS partitions
-
What is different with GPT?
GPT (GUID Partition Table) replaces the previous MBR partition tables. GPT is part of the UEFI specification.
Key features for the system administrator are:
-
No 2 TB limit (now 8 zebibytes or 9.6 zettabytes, i.e. 9,600 million terabytes).
-
Theoretically any number of partitions (128 should be supported by all OS; no distinction between primary, extended and logical partitions)
-
Changed partition types (GUIDs)
-
New: Partition GUIDs
-
New: Partition attributes (read-only, hidden, etc.)
-
Other tools for editing:
gdisk.
In general, GPT can be used without UEFI. But UEFI only works with GPT. If UEFI is used, then one or two additional partitions are added:
-
EFI System Partition, ESP (here are the bootloaders)
-
Microsoft Reserved Partition, MSR
Prerequisites
| This module is a paid extension. This means that you need an activation file to unlock it. You will receive this file after you have purchased the extension. For evaluation purposes, we’re happy to provide you with a temporary license free of charge. Please contact us via email. |
More details can be found in opsi Extensions.
The extension requires opsi 4.1 or newer. The following table lists the required opsi packages:
| opsi Package | Version |
|---|---|
Netboot products |
>=4.1 |
opsi server |
>=4.1 |
|
>=4.1.1.20-3 |
|
>=20200506 |
General Requirements
opsi 4.0.5 only supports 64 bit UEFI installations.
For installation via PXE boot (Preboot eXecution Environment), you need a UEFI-capable WinPE_UEFI (a Windows PE version specifically designed to boot on systems with UEFI firmware). Often Windows PE (Windows Preinstallation Environment) already contains UEFI support (check if there is a folder EFI and a file winpe/bootmgr.efi of the opsi netboot product). Otherwise, use DISM (Deployment Image Servicing and Management) to create an up-to-date Windows PE (see section Manual PE Creation). A UEFI WinPE is expected in the winpe_uefi folder of the opsi netboot product.
If there is a Windows PE for both boot modes, you can replace winpe_uefi with a symbolic link to winpe.
|
You have to configure an external DHCP server to enable PXE boot via the opsi server. Enter opsi/opsi-linux-bootimage/loader/shimx64.efi.signed as the boot file.
In the management interface opsi-configed activate the checkbox UEFI-Boot for UEFI clients (since version 4.0.5.8.1). Alternatively, configure the host parameter clientconfig.dhcpd.filename for the clients and enter the boot file there:
clientconfig.dhcpd.filename=opsi/opsi-linux-bootimage/loader/shimx64.efi.signedYou can also change the setting using the following command:
opsi-admin -d method configState_create "clientconfig.dhcpd.filename" "<Host-ID>" "opsi/opsi-linux-bootimage/loader/shimx64.efi.signed"
If your opsi server had earlier package versions installed, you may need to modify the /etc/opsi/opsipxeconfd.conf file to ensure compatibility between the UEFI bootloader and the named pipe.
|
Change this line
uefi netboot config template x64 = /tftpboot/linux/pxelinux.cfg/install-elilo-x64so that it reads:
uefi netboot config template x64 = /tftpboot/lopsi/opsi-linux-bootimage/cfg/install-grub-x64BIOS Settings
The menus of the different BIOS versions use different terms and names. If in doubt, choose the setting that is suitable for your computer:
-
Disable secure boot: The setting is often found in the Boot or Startup section, sometimes under Security. For more information, see the Secure Boot Support chapter.
-
BIOS in UEFI mode: If you have the choice between UEFI only, Legacy only or Both, select UEFI only. If the computer is set to Both, and this cannot be switched off, the extension may still work. If the entry Legacy Support is present, disable it. CSM Support in connection with UEFI only can remain activated, if you have no other choice. UEFI Network Boot has to be enabled; the option may also be called Network Stack in the UEFI section. If you have the option to configure IPv4 and IPv6 separately, IPv4 is the correct choice.
opsi Support for UEFI/Netboot
Our extension enables the connection of clients via UEFI/netboot. It is planned to continuously develop this module over the next few years. The extension includes the following components:
-
Customization of the netbootable UEFI bootloader GRUB2 for opsi and the client management needs respectively
-
new
opsipxeconfd, which provides configuration files for the opsi-GRUB2 in addition to configuration files for the previous PXE boot -
providing new (64 bit) opsi Linux boot images with tools for UEFI and GPT management
-
Conversion of all netboot products for OS installation (Windows/Linux) with support for UEFI/GPT (except operating systems which do not have UEFI support themselves)
-
Store the setting if the opsi server should treat a client as UEFI client +. (
clientconfig.dhcpd.filename=opsi/opsi-linux-bootimage/loader/shimx64.efi.signed) -
support for software-controlled switching to UEFI netboot
As far as the firmware interface allows it (i.e. if a netboot entry in the BIOS can be activated), the opsi server stores the UEFI netboot label of the client (as clientconfig.uefinetbootlabel). This allows opsi products to change the boot order to netboot for the next reboot. This technique is implemented in several opsi products, for example in opsi-uefi-netboot. It tries to switch to netboot and then trigger a reboot. If no UEFI netboot label is found or if it is not a UEFI computer, only a reboot is triggered. This product works on Windows and Linux.
DHCP Server Configuration
To boot UEFI clients via PXE, you need a corresponding entry in the boot file:
clientconfig.dhcpd.filename=opsi/opsi-linux-bootimage/loader/shimx64.efi.signedSince both variants are probably present in the opsi environment, the DHCP server must assign the correct boot file on the opsi server to the clients. The next two sections show configuration examples for a DHCP server on Linux and on Windows.
Example: Configuration on Linux (ISC DHCP Server)
The configuration of the DHCP server is located in the file /etc/dhcp/dhcpd.conf. This is how to set up a switch in this file:
filename "opsi/opsi-linux-bootimage/loader/opsi-netboot.bios";
# this is the 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 "lopsi/opsi-linux-bootimage/loader/shimx64.efi.signed";
}
else {
log (info, concat ( "Unhandled vendor class Arch: ", substring (option
vendor-class-identifier , 19,1 )));
}
| The Univention forum has a guide on how to set up a DHCP switch on Univention Corporate Server: https://help.univention.com/t/how-to-configure-a-dhcp-switch-for-uefi-and-non-uefi-boot/9931 |
Example: Configuration on Windows Server 2012 R2
Enter the boot file for UEFI 64 bit as default. To do this, adjust the DHCP options 66 and 67 as follows:
-
066 Hostname of the start server: IP address of the opsi server.
-
067 Name of the start file:
opsi/opsi-linux-bootimage/loader/shimx64.efi.signed.
To distinguish the clients, define a manufacturer class identifier on the DHCP server:
Define manufacturer class
Add new manufacturer class
Edit class
Display name: Legacy BIOS
Asci: PXEClient:Arch:00000:UNDI:002001
Map the predefined options to the manufacturer class:
Set predefined options
Options
Option class: Legacy BIOS
Add
Adjust the option type
Name: Legacy BIOS
Data Type: String
Code: 60
Description: PXEClient Class Legacy BIOS
Predefined options and values
String: PXEClient
Define a DHCP policy that maps the boot file for PXE boot (BIOS) to the manufacturer class:
New policy
Policy Name: PXE BootFile Legacy BIOS
continue
Add conditions
Criteria: Manufacturer class
Operator: equals
Value: Legacy BIOS
add
Would you like to configure an IP address range for the following policy: No
Manufacturer class: DHCP Standard Options
067 Name of the start file
file input
String value: opsi/opsi-linux-bootimage/loader/opsi-netboot.bios
There are two entries in the range options for the star file, which in one case is linked to a policy to detect BIOS clients:
067 Name of the Start file: opsi/opsi-linux-bootimage/loader/shimx64.efi.signed Policy: None 067 Name of the Start file: opsi/opsi-linux-bootimage/loader/opsi-netboot.bios Policy: PXE BootFile Legacy BIOS
opsipxeconfd Configuration
Starting with version 4.0.7.7 it is possible to customize the path of the files used as template via the configuration file opsipxeconfd.conf. To do this, specify the paths with uefi netboot config template x86 or uefi netboot config template x64.
Criteria for a "good" BIOS
Whether a UEFI BIOS meets the requirements of a client management system like opsi depends on various criteria.
| These criteria say nothing about the quality of the hardware — rather, it’s about how well it can be managed by using netboot. |
The following table shows a few sample comparisons:
| 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
"Entry can be activated" means in this context that netboot can be activated via the standard software for the next reboot, "Netboot without interaction" means that an activated netboot entry is executed at reboot and no user interaction (e.g. pressing keyboard shortcuts, [F12], etc.) is necessary for this. Only if these preconditions are met, certain opsi products can trigger a netboot. This feature is very important for automated processing. A product in which this is implemented is the localboot product opsi-uefi-netboot for Windows and Linux.
Technical Background
The next sections serve as a knowledge base for handling UEFI/GPT (manual or scripted). They are not required to understand how opsi works with UEFI/GPT.
UEFI Background
To manipulate the UEFI boot loader entries on Linux, you can use the efibootmgr program. The -v parameter prints a list of the entries:
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................On Windows, you manipulate the UEFI boot loader entries with the bcdedit program. To print a list of the entries, type this:
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 opsitempwinpeBoth programs, efibootmgr and bcdedit, can be used to create new entries, delete existing ones, set nextboot and change the boot order.
Example: Setting the entry for the next boot:
-
Linux:
efibootmgr /bootnext <hexId>
-
Windows:
bcdedit /set {fwbootmgr} bootsequence <GUID>
GPT Background
GPT uses "new" partition types which are based on the previously known ones. For example, the partition type 07 (for NTFS) becomes 0700 under GPT. Correspondingly, the two Linux partition types 82 and 83 are called 8200 and 8300. To display the list of known partition types, you can enter the following command:
# 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
In fact, the partition types listed here are only "abbreviations" for the actual GUIDs used (which gave the partitioning scheme its name). For example, 0700 stands for Microsoft basic data and for the GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.
|
0700 stands for Microsoft basic data and for the GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
You can find a complete list of all GUIDs in Wikipedia, for example:
The tools gdisk and sgdisk use an internal table to substitute unknown partition types. For example, for the "old" partition type for VFAT32 0b there is no equivalent of the form 0b00. But if you pass 0b00 as type to sgdisk, the tool translates it to 0700 — probably along the lines of "VFAT32, this will probably be an MS data partition…"
GPT partitions support attributes. The next table shows a list of currently known attributes:
Value |
Description |
Attribute value ( |
0 |
System Partition |
0000000000000001 |
1 |
Hide Partition from EFI |
0000000000000002 |
2 |
Legacy Boot Flag (legacy BIOS bootable) |
0000000000000004 |
60 |
Read-only |
1000000000000000 |
62 |
Hidden |
4000000000000000 |
63 |
Do not automount |
8000000000000000 |
To set the attributes, use sgdisk -A (--attributes) on Linux and the diskpart program with the gpt attributes command on Windows.
Examples:
sgdisk -t 1:0700 --attributes 1:clear:63 --attributes 1:set:62 -p /dev/sdaselect disk 0
select partition 1
gpt attributes=0x0000000000000000To display the partition table with sgdisk, use the -p parameter (--print):
sgdisk -p /dev/sdaYou can get detailed info about a partition (1) with --info=:
sgdisk --info=1 /dev/sdaNetboot Products with UEFI Support
| Netboot Product | opsi 4.3 | Remark |
|---|---|---|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.3 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.3 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.3 | Remark |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
Netboot Products with Secure Boot Support
| Netboot Product | opsi 4.3 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: Supported
: Unsupported
: Under development
: Discontinued
| Netboot Product | opsi 4.3 | 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