openEuler

This page describes installation and image profiles for three openEuler LTS release families: 20.03, 22.03 and 24.03. It covers management nodes, installed and diskless service nodes, and stateful and stateless compute nodes.

Release profiles

Qualification uses one service pack from each LTS release:

Release	Architecture	xCAT OS name
20.03 LTS SP4	x86_64	`openeuler20.03sp4`
22.03 LTS SP4	x86_64	`openeuler22.03sp4`
24.03 LTS SP4	x86_64	`openeuler24.03sp4`
24.03 LTS GA	ppc64le	`openeuler24.03`
24.03 LTS SP4	riscv64	`openeuler24.03sp4`

Earlier service packs are outside this qualification. The POWER GA image is a functional exception; its qualification does not establish maintained POWER service-pack support. Consult the distribution’s maintenance policy separately.

The baseline uses virtual BIOS boot on x86_64 and KVM Open Firmware on ppc64le. It includes management nodes, installed and diskless service nodes, and both compute modes through each serving role. Stateless images use cpio with gzip compression. SQLite serves standalone management nodes; MariaDB serves the service-node hierarchy. Additional firmware, database, image-format and network combinations need separate qualification.

On riscv64, the qualification covers installed and stateless compute nodes from the RVA23 media, managed from a riscv64 management node that runs Ubuntu 26.04. xCAT publishes no openEuler riscv64 packages, so riscv64 management and service nodes are outside it. The test hardware could not boot from the network, so firmware network boot is not qualified either. See RISC-V 64-bit (riscv64).

openEuler also publishes RVA20 media for riscv64. Both builds of a release have the same target directory, and copycds refuses to copy one over the other. Import the build that matches the nodes, or copy the other build to another directory with -p.

The tested provisioning networks use IPv4 and ISC DHCP on isolated links, with separate upstream and downstream interfaces on service nodes. The qualification covers on-link access to the assigned management or service node. The 20.03 SP4 and 22.03 SP4 direct stateless cases use net.ipv4.ip_forward=0 without a DHCP default router. Off-subnet reachability is outside this qualification.

The tested service-node hierarchies use sharedtftp=1 and disjointdhcps=1. The 20.03 SP4 and 22.03 SP4 installed-service-node cases and the 24.03 SP4 cases use installloc=/install. The 20.03 SP4 and 22.03 SP4 hierarchy cases use hierarchicalattrs=postscripts.

Keep the complete OS name in node, image and repository definitions. For example, openeuler24.03sp4 must not be shortened to openeuler24 or replaced with an EL version. Profile lookup prefers the exact service pack, then its LTS release, then the generic openEuler profile. It does not select a profile from another service pack.

Management-node packages

Use native openEuler RPMs for the selected release and architecture. Prepare signed xcat-core, xcat-dep and distribution repositories, including the native dependency packages needed by the selected roles. An EL repository does not supply the openEuler dependency closure.

The native repository target is <osname>/<architecture>, for example openeuler24.03sp4/x86_64. Configure repository files with the matching base URLs, trusted signing keys and gpgcheck=1. Then use the normal bootstrap command with those files:

./go-xcat --xcat-core=/path/to/xcat-core.repo \
          --xcat-dep=/path/to/xcat-dep.repo --yes install

For an offline installation, make the complete signed dependency closure available locally before running this command. Preserve the repository metadata, package versions and signing-key fingerprints with the installation record. This page does not identify a published openEuler package channel.

Follow Configure xCAT Software Repository for site configuration and Verify xCAT Installation for management-node checks. openEuler uses the ISC DHCP backend. Configure the provisioning interfaces explicitly before starting DHCP.

Media and installed nodes

Import the official DVD without an OS-name override. For 24.03 SP4:

copycds -i /path/to/openEuler-24.03-LTS-SP4-x86_64-dvd.iso
copycds -w /path/to/openEuler-24.03-LTS-SP4-x86_64-dvd.iso
lsdef -t osimage openeuler24.03sp4-x86_64-install-compute

The import creates compute and service installation images, a compute netboot image, and a management-node profile. It does not create StateLite images. Review pkgdir, pkglist, template and otherpkgdir before using an image. Put custom assets under /install/custom and select them through the image attributes.

After defining the node’s network, target disk and hardware-control method, select the installation image and boot the node:

nodeset cn01 osimage=openeuler24.03sp4-x86_64-install-compute
rpower cn01 boot

Check the installation status, executed postscripts and installed disk boot. Keep the imported native repositories available for installation and updates. The openEuler post-installation path disables the distribution’s default openEuler.repo file in the resulting system.

Stateless compute images

Build the image on an openEuler host of the target architecture, using its native kernel, modules and package repositories. Check the image’s network drivers and interface settings before generation. genimage checks every package against the signing keys in the build host’s RPM keyring. A new openEuler installation has no key there. Import the openEuler key first:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-openEuler

For the imported compute profile:

genimage openeuler24.03sp4-x86_64-netboot-compute
packimage -m cpio -c gzip openeuler24.03sp4-x86_64-netboot-compute
nodeset cn01 osimage=openeuler24.03sp4-x86_64-netboot-compute
rpower cn01 boot

The commands above select the cpio/gzip image path. Other pack formats need their own qualification. Preserve the previous packed image before updating it. Verify a second network boot, loss of transient root contents, an image update and rollback. Image generation alone does not verify node operation.

Service nodes

Use MariaDB on the management node for the baseline service-node hierarchy. SQLite is for standalone management-node operation. Install the matching native database client modules on each service node. PostgreSQL is outside the baseline qualification; its client package does not provide a server.

Use the normal Hierarchical Clusters / Large Cluster Support procedures for database credentials, service-node definitions, resource sharing and downstream ownership. Configure the downstream interface before activating its services. When that interface needs confignetwork, order the node’s postscripts as confignetwork,servicenode.

The installed service profile is openeuler24.03sp4-x86_64-install-service. Its other-package list expects these repository paths below otherpkgdir:

xcat/xcat-core/openeuler24.03sp4/x86_64/
xcat/xcat-dep/openeuler24.03sp4/x86_64/

Each directory needs its RPMs and repository metadata. The selected service profile supplies xCATsn and goconserver through these repositories.

Make the repository signing keys available inside each service-node image. For installed service nodes, run the site’s key-import postscript before otherpkgs. Verify the keys against trusted fingerprints and keep package signature checking enabled.

Create a diskless service image from the imported compute template, then select every service asset explicitly:

mkdef -t osimage -o oe24-service \
    --template openeuler24.03sp4-x86_64-netboot-compute \
    profile=service provmethod=netboot
chdef -t osimage oe24-service \
    pkglist=/opt/xcat/share/xcat/netboot/openeuler/service.openeuler.pkglist \
    exlist=/opt/xcat/share/xcat/netboot/openeuler/service.openeuler.exlist \
    postinstall=/opt/xcat/share/xcat/netboot/openeuler/service.openeuler.postinstall \
    otherpkglist=/opt/xcat/share/xcat/netboot/openeuler/service.openeuler24.03sp4.x86_64.otherpkgs.pkglist \
    otherpkgdir=/install/post/otherpkgs/openeuler24.03sp4/x86_64 \
    rootimgdir=/install/netboot/openeuler24.03sp4/x86_64/oe24-service

Set the service-node network and postscript attributes, then run genimage and packimage for oe24-service. The imported definitions do not include a netboot-service template. Build a separate image for each selected release and architecture.

Verify both service-node forms after reboot, including remote database writes and provisioning of installed and stateless downstream nodes. Follow Verify Service Node Installation for service checks. Resource replication and manual takeover require their own configured paths and tests.

Discovery, security and upgrades

Install Genesis packages for each payload architecture served by the management node. mknb x86_64 and mknb ppc64le use different payloads. An openEuler Genesis build includes native UTF-8 locale data and mktemp. Automatic discovery registration is outside the baseline qualification. Sequential discovery rejects virtual nodes. Provision explicitly defined nodes with the installation and netboot procedures above. A successful mknb command alone does not establish working discovery.

The current validation configuration disables SELinux and the host firewall. It uses signed packages, TLS client authorization, SSH keys and secure-root mode. Enforcing SELinux and a host firewall policy are not qualified by these results. Keep the provisioning network isolated and configure access for the services selected in the site and hierarchy definitions.

Before an xCAT RPM upgrade, back up the database, /etc/xcat and customized service and image configuration. Keep xcatd running during CSV database restore. Check restore errors and table contents, then verify services and data after reboot. Use the native repositories with the normal Updating xCAT procedure.

An xCAT RPM upgrade does not qualify an operating-system service-pack upgrade. Document each supported OS transition separately; no cross-LTS in-place upgrade or downgrade is implied. Offline installation and RPM upgrade preservation are qualified separately on 24.03 SP4. Physical platform certification, automatic discovery, manual service-node takeover and mixed-distribution provisioning are outside the baseline qualification. Virtual firmware results do not establish physical BIOS, UEFI or Petitboot support.

Crash dump arming is not qualified. Some 24.03 guests reported a failed kdump service without a reserved crash kernel.

The POWER console test verified input and responses. The client required forced termination; graceful exit remains unqualified.