Server Upgrade from 5.0 to 5.2

Uyuni 5.0 must be stopped before the upgrade.

Uyuni server hosts that are hardened for security may restrict execution of files from the /tmp folder. In such cases, as a workaround, export the TMPDIR environment variable to another existing path before running mgradm.

For example:

export TMPDIR=/path/to/other/tmp

In Uyuni updates, tools will be changed to make this workaround unnecessary.

Before upgrading, verify that every root and intermediate CA certificate used by Uyuni marks X509v3 Basic Constraints as critical and includes CA:TRUE. Strict certificate validators, including Python 3.13 and later, reject CA certificates that miss the critical flag.

If your installation uses an older self-signed CA generated by Uyuni, you might need to create a new CA and new server certificates, then deploy the new root CA to all clients. For the verification command, certificate replacement, and client root-CA deployment procedure, see administration:ssl-certs-imported.adoc#ssl-certs-verify-ca-basic-constraints, administration:ssl-certs-selfsigned.adoc#ssl-certs-selfsigned-create-replace, and administration:ssl-certs-imported.adoc#ssl-certs-import-deploy-root-ca.

SSL certificates are needed at a later stage. If not using the self-signed generated CA and certificates, ensure you have the following before starting:

  • A certificate authority (CA) SSL public certificate. If you are using a CA chain, all intermediate CAs must also be available.

  • An SSL database private key.

  • An SSL database certificate.

All files must be in PEM format.

The hostname of the SSL server certificate must match the fully qualified hostname of the machine you deploy them on. You can set the hostnames in the X509v3 Subject Alternative Name section of the certificate. You can also list multiple hostnames if your environment requires it. Supported Key types are RSA and EC (Elliptic Curve).

In the past, database SSL certificate required reportdb and db as Subject Alternative Name. This is no longer needed, and only the Server FQDN (used to access the report database) is mandatory as Subject Alternative Name.

The database container needs only the externally facing fully qualified domain name. The old certificates with db and reportdb SANs can be still used.

The same certificate can be used for both the main container and the database one.

In order to pass the new certificates to the upgrade command, use the --ssl-db-ca-root, --ssl-db-cert and --ssl-db-key parameters.

Upgrading to specific version

If you do not specify the tag parameter, it will default to upgrading to the most recent version. To upgrade to a specific version, provide the tag parameter with the desired image tag.

During a migration the server SSL certificate and CA chain are copied from the source server.

1. SLE Micro 5.5 to SL Micro 6.2

This document provides the tested procedure to upgrade a SLE Micro 5.5 host deployed with Uyuni 5.0 Server to SL Micro 6.2 and migrate to Uyuni 2026.06.

1.1. Prerequisites

  • Uyuni 5.0 is installed and running on SLE Micro 5.5.

  • System is registered and has active subscriptions with SCC.

1.2. Distribution upgrade and server migration

Procedure: Migration from Uyuni 5.0 to Uyuni 2026.06

  1. Verify current product status.

    SUSEConnect --status-text

    Confirm:

    • Base OS: SUSE Linux Enterprise Micro 5.5

    • Extension: SUSE Manager Server 5.0 Extension

  2. Ensure the system is updated.

    transactional-update patch

    • If patches were applied, stop the server and then reboot the system before proceeding to migration:

      mgradm stop
reboot

    • If no updates were found, you can proceed directly to the migration step.

  3. Start the migration.

    transactional-update migration --auto-agree-with-licenses --gpg-auto-import-keys

    Follow the prompts and select the available migration to SUSE Linux Micro 6.2 and Uyuni Server Extension 2026.06.

  4. Clean up the unused container images to free disk space:

    podman image prune -a

    In some upgrades, multiple *.rpmnew and *.rpmsave files may be generated. The presence or number of these files does not indicate that manual action is required. In SUSE Multi-Linux Manager container environments, required configuration changes are applied automatically during the upgrade process. These files are created as a result of differences between packaged defaults and existing configuration files, and may also include internal or informational changes that are not intended to be merged. If manual action is required for a configuration change, it will be explicitly documented in the release notes or upgrade documentation.

    Do not treat these files as a post-upgrade checklist or merge them in bulk. Only review a file if you are actively troubleshooting a specific issue and understand the impact of the configuration it contains. If a change is required, it should be applied intentionally based on a known requirement, not by copying differences from these files. If you are unsure, leave the file unchanged.

  5. Stop the server and then reboot to apply changes.

    mgradm stop
reboot

  6. Perform post-reboot checks.

    Verify Uyuni extension and Uyuni version:

    SUSEConnect --status-text
mgradm --version

    Expected output:

    • Extension: SUSE Multi-Linux Manager Server 2026.06 Extension

    • Version: referencing 5.2.0 or higher

  7. Verify PostgreSQL database version.

    podman ps

    Expected output:

    • server:5.2.0 or higher

    • server-postgresql:5.2.0 or higher

  8. Upgrade server containers.

    Risk of Automated Version Downgrade and PTF Loss

    Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

    To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

    Before running mgradm upgrade podman, check whether /etc/systemd/system/uyuni-server.service contains explicit IPv6 port bindings in the form -p [::]:PORT:PORT. These bindings are incompatible with netavark on SL Micro 6.2 and cause malformed nftables rules that prevent the web UI from being reachable after the upgrade.

    If such lines are present, remove them before proceeding:

      -p 80:80 \
- -p [::]:80:80 \
  -p 443:443 \
- -p [::]:443:443 \

    Then reboot the host before continuing:

    systemctl reboot
    		 
    mgradm start
mgradm upgrade podman

    Follow the prompts to pull and configure the new 5.2.x containers.

  9. Verify running containers:

    podman ps

    You should see all the expected server containers are up and running.

  10. Clean up the unused container images to free disk space:

    podman image prune -a

    In some upgrades, multiple *.rpmnew and *.rpmsave files may be generated. The presence or number of these files does not indicate that manual action is required. In SUSE Multi-Linux Manager container environments, required configuration changes are applied automatically during the upgrade process. These files are created as a result of differences between packaged defaults and existing configuration files, and may also include internal or informational changes that are not intended to be merged. If manual action is required for a configuration change, it will be explicitly documented in the release notes or upgrade documentation.

    Do not treat these files as a post-upgrade checklist or merge them in bulk. Only review a file if you are actively troubleshooting a specific issue and understand the impact of the configuration it contains. If a change is required, it should be applied intentionally based on a known requirement, not by copying differences from these files. If you are unsure, leave the file unchanged.

1.3. Migration complete

The server host system is now running SL Micro 6.2 with updated Uyuni 2026.06 Server packages.

If you have a Uyuni 5.0 proxy connected to this server, proceed to the Proxy Migration 5.0 > 5.2 guide to upgrade the proxy host.

Validate your setup before resuming production operations.

1.4. Database Backup Volume

Server migration or upgrade with mgradm migration or mgradm upgrade can create a volume with the database backup.

When the PostgreSQL database version is increased, the old database must be stored in a separate location before running the upgrade. For this purpose mgradm dynamically creates the volume var-pgsql-backup. When the migration or upgrade is done and the user has validated that the new system is working as expected, this volume can be removed safely.

2. SUSE Linux Enterprise Server 15 SP6 to 15 SP7

This document provides the procedure to upgrade a SUSE Linux Enterprise Server 15 SP6 host deployed with Uyuni 5.0 Server to SUSE Linux Enterprise Server 15 SP7 and migrate to Uyuni 2026.06.

2.1. Prerequisites

  • Uyuni 5.0 is installed and running on SUSE Linux Enterprise Server 15 SP6.

  • System is registered and has active subscriptions with SCC.

2.2. Distribution upgrade and server migration

Procedure: Upgrade and Migrate Uyuni on SUSE Linux Enterprise Server 15 SP6

  1. Verify current product status.

    SUSEConnect --status-text

    Confirm:

    • Base OS: SUSE Linux Enterprise Server 15 SP6

    • Extension: SUSE Manager Server 5.0 Extension

  2. Ensure the system is updated.

    zypper patch

    If patches were applied, stop the server and then reboot before proceeding:

    mgradm stop
reboot

  3. Perform the migration to SP7 and Uyuni 2026.06.

    zypper migration

    Select to migrate to:

    • SUSE Linux Enterprise Server 15 SP7

    • Uyuni Server Extension 2026.06

  4. Stop the server and reboot.

    mgradm stop
reboot

  5. Perform post-reboot checks.

    Verify Uyuni extension:

    SUSEConnect --status-text

    Expected output:

    • Extension: SUSE Multi-Linux Manager Server 2026.06 Extension

  6. Verify Uyuni version.

    mgradm --version

    Expected output:

    • Version: referencing 5.2.0 or higher

  7. Upgrade server containers.

    Risk of Automated Version Downgrade and PTF Loss

    Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

    To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

    		 
    mgradm start
mgradm upgrade podman

    Follow the prompts to pull and configure the new 5.2.x containers.

  8. Verify containers:

    podman ps

    Expected output:

    • server:5.2.0 or higher

    • server-postgresql:5.2.0 or higher

2.3. Migration complete

The server host system is now running SUSE Linux Enterprise Server 15 SP7 with updated Uyuni 2026.06 Server packages.

If you have a Uyuni 5.0 proxy connected to this server, proceed to the Proxy Migration 5.0 > 5.2 guide to upgrade the proxy host.

Validate your setup before resuming production operations.

2.4. Database Backup Volume

Server migration or upgrade with mgradm migration or mgradm upgrade can create a volume with the database backup.

When the PostgreSQL database version is increased, the old database must be stored in a separate location before running the upgrade. For this purpose mgradm dynamically creates the volume var-pgsql-backup. When the migration or upgrade is done and the user has validated that the new system is working as expected, this volume can be removed safely.