Automated installation of SUSE Linux Enterprise Server using Agama

Agama focuses on core installation tasks such as user authentication, network configuration, storage setup and software installation, delegating further configuration to other tools such as Ansible Salt, Cockpit or OpenSCAP.

You can define installation parameters for the target system in an easily readable and editable JSON or Jsonnet profile. Existing XML based AutoYaST are also supported with some exceptions.

The profile allows detailed setup including user authentication, product registration, network connections, storage (drives, partitions, LVM, RAID, encryption, resizing, deleting), software selection by patterns and packages, localization (language, keyboard, timezone) and many other aspects of the target system that are not exposed in the graphical or web-based interface. This helps in a more granular control over the installation parameters.

Agama supports dynamic profiles using Jsonnet, injecting hardware information that can be processed at runtime. This avoids reliance on AutoYaST's rules or ERB for dynamic configurations.

Agama offers a mechanism to reuse existing AutoYaST profiles to a great extent. It supports some dynamic features such as pre-scripts, rules/classes, and Embedded Ruby (ERB) when using AutoYaST profiles. A legacyAutoyastStorage section allows direct use of the AutoYaST profile's partitioning section for backwards compatibility.

Profiles can define pre-installation, post-partitioning, chroot, and init scripts that run at specific stages. You can include scripts by URL, location in the hard drive, or embed the script content in the profile itself.

The typical way to start an unattended installation from an ISO image is using the inst.auto kernel boot option, pointing to the profile URL or it's location in the hard drive. You can also use the agama profile import command from the Agama CLI to load a profile, followed by the agama install command. The CLI also allows inspection, modification, validation of the profile, and subsequent monitoring of the installation process.

The product identifier used to select the base SUSE product to be installed.

The registration code for the product obtained from SUSE Customer Center, and used to activate repositories and receive updates.

The email address associated with the registration account used during product activation.

The full URL of the registration server. If you are using SUSE Customer Center, you can omit this field. However, it is useful when registering from a custom server.

A list of optional add-on modules or extensions to be activated alongside the base product.

The persistent hostname written to /etc/hostname. This name remains consistent across system reboots and is used by default if no transient hostname is specified.

A temporary hostname applied at runtime. This may be used during deployment or installation to reflect an ephemeral identity. For example, it can be set via DHCP or by installation tooling like Agama.

Boolean flag indicating whether the password field contains a hashed value. If set to true, the password must be a SHA-512 crypt hash (starting with $6$). If false or omitted, the value is treated as plain text.

The root user's password. If hashedPassword is true, this must be a pre-generated hash (For example, using openssl passwd -6). Otherwise, plain text is accepted and will be hashed during installation.

You can generated a hashed password by running the following command:

> sudo openssl passwd -6

An optional SSH public key to be added to the root user's ~/.ssh/authorized_keys file. This allows passwordless root login over SSH. The key must be in OpenSSH format. For example, starting with ssh-rsa or ssh-ed25519.

You can generate an SSH public key by running the following command:

> sudo ssh-keygen -t rsa -b 4096 -C "YOUR-EMAIL@EXAMPLE.COM"

Based on your requirements, choose the key type and the key size. However, it's better to adopt a stronger security.

Boolean flag indicating whether the password field contains a hashed value. If set to true, the password must be a pre-hashed SHA-512 crypt value. Otherwise, the plain text password will be hashed during installation.

The full name of the user, typically used for display purposes in graphical environments. For example, Jane Doe.

The system login name for the user. This becomes their Linux username and home directory under /home. For example, jane.

The user's password, in plain text or pre-hashed depending on the hashedPassword flag. If plaintext is provided, it will be automatically hashed.

Optional boolean that determines whether the user should be automatically logged into a graphical session at boot. This setting is only relevant for desktop installations.

The system language and locale, specified as a locale string. For example, en_US.UTF-8 or de_DE. This controls messages, number formats, date formats, and default encoding.

The default keyboard layout identifier. For example, us or de. This affects key mapping on both text consoles and graphical desktops.

The system time zone, using a region/location format. For example, Europe/Berlin. This sets the default system clock and affects date/time display.

A list of software patterns to be installed. Patterns are curated collections of packages designed to serve a functional role. For example, minimal_base, gnome, app_server. For a complete list of patterns available for SUSE Linux Enterprise Server and your target architecture, refer to the SUSE Customer Center.

A list of individual packages to install in addition to those brought in by selected patterns. For example, vim, htop and curl. For a complete list of packages available from the official SUSE Linux Enterprise Server repositories for your target architecture, refer to the SUSE Customer Center.

A list of disks on which partitions will be defined.

Boolean flag that, if set to true, forces the system to stop at the GRUB boot menu instead of proceeding automatically. This is useful for debugging or choosing alternate boot options manually.

Number of seconds the GRUB boot menu is shown before continuing with the default entry. Set to 0 to boot immediately.

Additional kernel command-line parameters to append to the default ones during boot. These are passed directly to the Linux kernel. For example, console=ttyS0 or quiet splash.

Unique name for the network connection.

Name of the network interface to bind to (for example, eth0).

IPv4 addressing method (auto, manual, etc.).

IPv6 addressing method (auto, manual, etc.).

List of static addresses in CIDR format.

IPv4 and IPv6 default gateway addresses.

List of DNS server IPs.

Boolean. Whether the connection is brought up automatically.

Defines wireless-specific settings:

Defines bridge-specific settings:

Defines bonding configuration:

Defines enterprise authentication settings:

A list of custom SSL certificates to install into the system’s trust store. Each item specifies the certificate’s fingerprint and the hashing algorithm used.

Scripts executed before the installation begins. Useful for pre-flight checks or environment preparation.

Scripts run immediately after partitioning is completed, but before packages are installed.

Scripts run after installation finishes. These can optionally execute within the target system’s root via chroot.

Scripts executed during the first boot of the installed system. These are useful for final configuration, logging, or notifications.

File name used to identify the script on disk. Required for all scripts.

Inline script body. Must begin with a shebang (for example, #!/bin/bash).

HTTP/HTTPS location from which to fetch the script. Cannot be combined with content.

Boolean. If true, the script is executed inside the installed system’s root via chroot. Applies only to post scripts.

Required absolute path where the file will be written inside the target system. For example, /etc/MYAPP/CONFIG.YAML.

Inline string representing the content of the file. This field is mutually exclusive with url; one of the two must be present.

URL (relative or absolute) to fetch the file content from. Used instead of inline content. One of url or content is required.

Optional file mode string (octal), such as 0644 or 0755, to set on the created file.

Optional owner username to assign to the file. The user must already exist in the installed system.

Optional owner group to assign to the file. The group must already exist in the installed system.

An array of JSON objects compatible with the XML structure used in AutoYaST’s partitioning section. This allows experienced administrators to reuse complex partitioning logic without switching to Agama-native storage syntax.

The iSCSI initiator name (IQN) of the client system. Must follow the iSCSI naming convention. For example, iqn.2025-05.com.suse:agama-client.

An array of target definitions to connect to. Each target supports the following fields:

A list of DASD devices to configure. Each device is represented as an object with the following fields:

Existing infrastructure-as-code assets can inform Agama profile structure, minimizing rework.

Administrators familiar with AutoYaST can map known modules to Agama fields incrementally.

Supported AutoYaST elements can be reused while unsupported ones are refactored or omitted over time.

Reviewing legacy profiles helps surface deprecated patterns and adapt them to Agama’s declarative model.

AutoYaST profiles often rely on execution order, embedded scripts, and imperative constructs, which have no counterpart in Agama’s declarative design.

Many AutoYaST modules encapsulate behavior or assumptions not explicitly modeled in Agama, leading to subtle incompatibilities or misconfigurations during reuse.

Profiles imported from AutoYaST tend to obscure the declarative simplicity of Agama, making troubleshooting and peer review harder.

Clinging to legacy profiles may prevent users from fully adopting Agama’s modular, readable, and cloud-native configuration style.

Either efi or partition. Determines how the partition is treated.

Size of the partition in MiB. If omitted, the remaining space is used.

Mount point inside the target filesystems. Must be specified unless the partition is unmounted.

Filesystems type, such as xfs, ext4, or btrfs. Required unless format is false.

Boolean flag. When true, existing data on this partition is preserved. Defaults to false.

Boolean flag. When true, the partition will be freshly formatted. Defaults to true unless preserve is set.

Must be set to crypt to declare a LUKS encrypted volume.

Name for the mapped LUKS device, used in /dev/mapper.

Encryption cipher. For example, aes-xts-plain64.

Key size in bits. Common values are 256 or 512.

The passphrase used to unlock the encrypted volume. Can be replaced with keyFile if using an external key.

The block device definition that will reside within the LUKS container. Often a single partition, but can also be a volume group.

Set to volumeGroup to define a new LVM volume group container.

Name of the volume group. Used for identifying the group in /dev/<vg-name>/.

List of logical volumes within this volume group. Each volume is defined using fields like name, mountPoint, fsType, and size.

Must be set to mdraid to define a software RAID device.

The RAID level to use (e.g., 0, 1, 5, 6, or 10).

List of block devices that participate in the array.

The volume definition describing what should be created on top of the RAID array. It may be a regular filesystem partition, a LUKS container, or an LVM setup.

Must be set to btrfs to define a Btrfs partition.

The mount point for the root of the Btrfs volume (e.g., /).

Whether to format the Btrfs partition. Must be set to true to create new filesystems.

List of Btrfs subvolumes. Each subvolume is an object with at least a name, and optionally a mountPoint.

If set to true, this partition or volume will take up any leftover space after allocating other defined volumes.

Marks the partition as an EFI System Partition. This is required for UEFI boot setups when using a separate /boot partition.

Human-readable label to assign to the partition or logical volume. For example, HOME or BOOT.

Unique identifier used to reference this partition in other sections or mount relationships. Optional, but useful for referencing volumes in complex setups.

If true, the existing content of the volume will not be deleted or reformatted. This is useful when retaining data directories like /home or reuse across installations. The target must already be formatted with a valid filesystem.

Represents a physical or virtual block device. It contains a list of partitions or other volume definitions.

Represents a filesystem partition on a disk. Most commonly used for mount points like /boot, /home, or /.

Marks a partition to be encrypted using LUKS. Must be opened later using luks_open.

Refers to an encrypted volume defined via luks. It allows specifying filesystem and mount point on the decrypted device.

Initializes a partition as a physical volume (PV) for LVM. Used in combination with lvm_vg.

Defines a volume group that aggregates one or more PVs. Contains logical volumes with their own mount points and filesystems.

Used to define software RAID arrays (e.g., RAID1, RAID5) over multiple disks or partitions.

Defines a Btrfs subvolume and mount point within a Btrfs-formatted volume. Requires a parent Btrfs filesystem to exist.