Important Notes

opsi 4.3, being a major release, has dedicated repositories. To upgrade, you need to add these new package sources to the respective configuration files on your systems and remove the repositories from the previous version.

Ensure that all installed packages are updated to the latest opsi 4.2 version before proceeding with the upgrade to 4.3. Also, update other packages (such as the MySQL server), as outdated versions could hinder the upgrade process.

Prior to upgrading, make sure to update the opsi-script, opsi-client-agent, opsi-linux-client-agent, and opsi-mac-client-agent packages on all clients!

opsi Linux Boot Image and DHCP Server

In the opsi Linux boot image for version 4.3, the bootloaders are now located in the path <TFTP-ROOT>/opsi/opsi-linux-bootimage/loader. If you are using Netboot/PXE, you may need to manually adjust the DHCP server configuration, specifically option 67 (BootFile Name), to reflect these changes.

  • Legacy BIOS: opsi/opsi-linux-bootimage/loader/opsi-netboot.bios

  • UEFI-BIOS: opsi/opsi-linux-bootimage/loader/shimx64.efi.signed

Update OS Packages

Make sure you are using the most recent opsi 4.2 packages from the stable branch at the time of the upgrade!

Update opsi Packages

opsi packages are typically compatible with both opsi 4.2 and opsi 4.3.

The official 4.3 repositories contain packages compatible with opsi 4.3.

Please note that the packages in these repositories may not always include 4.3 in their version names, yet they are still compatible with opsi 4.3.

Backend Extensions

The extension methods that were once located in /etc/opsi/backendManager/extend.d are now permanently integrated into opsiconfd. As a result, the /etc/opsi/backendManager/extend.d directory will be empty by default. The default files that were previously included will be relocated during the upgrade process.

However, the extend mechanism remains available for use. You can implement your own methods in custom .conf files placed in the /etc/opsi/backendManager/extend.d directory.

Workbench, Depot, and Repository

With the update to opsi 4.3, fixed directories for the workbench, depot, and repository are now used under the /var/lib/opsi path. This new structure means that dynamic configurations set through depotLocalUrl, repositoryLocalUrl, and workbenchLocalUrl at the depots will no longer be recognized.

If your workbench, depot, and repository directories are currently situated in different locations, you should relocate them to /var/lib/opsi. Alternatively, instead of physically moving these directories, you can create symbolic links (symlinks) that point to their new location under /var/lib/opsi.

Sorting Algorithm

In opsi 4.3, there is a single, new sorting algorithm for product actions, eliminating the previous distinction between algorithm1 and algorithm2. This updated algorithm generally yields results comparable to those produced by the former algorithm1.

opsi Packages

The new opsi packages are now located at

Please note that the packages offered there do not necessarily have to have the version number 4.3 in their name in order to run under opsi 4.3!

With a few exceptions, the behaviour of the opsi package tools remains the same - which is why not much has to change in the workflows.


opsi-newprod now creates a control file (control.toml) in TOML format. The contained values behave exactly as before, only the format now follows the TOML standard.

For compatibility with 4.1 and 4.2 servers, opsi-makepackage automatically generates a control file in the old format, but the package must be maintained via control.toml. If the specified version in the control is newer than in the control.toml, an error is thrown (because the control is ignored as soon as a control.toml is found)!


An existing control file can be converted into a control.toml with opsi-makepackage --control-to-toml. From then on, maintenance must be carried out via control.toml.

You can also use Markdown in control.toml. For example, you can use links in the description that are clickable in opsi-configed.

With opsi-makepackage 4.3 there is only the serialisation tar. The default compression is zstd (compatible with opsi >= 4.2). If packages are still to be built for opsi 4.1, the compression can be changed to gz. The file /etc/opsi/makepackage_marker_use_gz is created for this purpose.

opsi Tools

The tools opsi-configed, opsi-setup-detector-setup, the WebGUI, and others are now accessible at](


The actions available for products in the context menu (accessed by right-clicking on a product) have undergone revisions. The options Save and execute and Save and execute (selected products only) now take into account the configuration setting opsiclientd.control_server.process_actions_even.

Context Menu of the right Mouse Button
Figure 1. Context Menu of the right Mouse Button

The configuration can have the following values:

  • auto: Triggers timer event in WAN mode, otherwise on_demand (default).

  • on_demand: The on_demand event is always triggered.

  • timer: The timer event is always triggered.

In opsi 4.3 it is no longer necessary to differentiate between UEFI and Legacy, as the GRUB2 bootloader is used in each case. The UEFI hook is therefore not required for switching. After an OS installation via opsi, the tick indicates whether the system was installed via UEFI or legacy. The configuration value clientconfig.uefibootlabel is decisive for this.

UEFI hook
Figure 2. UEFI hook