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: .. list-table:: :header-rows: 1 * - 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 :doc:`/guides/admin-guides/manage_clusters/riscv64/index`. 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 ``/``, 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 :doc:`/guides/install-guides/yum/configure_xcat` for site configuration and :doc:`/guides/install-guides/yum/verify_xcat` 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 :doc:`/advanced/hierarchy/index` 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 :doc:`/advanced/hierarchy/provision/verify_sn` 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 :doc:`/guides/install-guides/yum/update_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.