How to Configure AutoYaST for Automated SLES 15 Deployment

A SLES 15 installation that waits at a partitioning prompt, asks for the same settings on every server, or fails halfway through a batch usually points to a profile that does not match the target machines or cannot be fetched at boot. AutoYaST automates SLES installation from an XML profile, but unattended does not mean assumption-free: disk layouts, network access, software sources, credentials, and boot parameters must all be correct for the machine being installed.

This guide walks from a safe first test to network-based deployment, using the current SUSE AutoYaST Guide for SLES 15 SP7, published October 1, 2026. Check the documentation for the exact service pack and architecture you deploy; older SLES 15 profiles and settings may differ. SUSE documents profile validation during installation from SLES 15 SP3 onward, but validation cannot prove that a chosen disk is safe to erase or that every target has identical hardware.

1. Inventory the machines before writing the profile

Start with a small inventory of the target systems. Record the SLES service pack and architecture, disk device names and sizes, firmware mode, network interfaces, DHCP or static addressing requirements, hostname rules, registration method, software repositories, and packages each server needs. SUSE specifically recommends collecting hardware and network details, including disk types and sizes and, when known, interface MAC addresses.

This matters most for storage. A profile copied from one reference machine may name a disk that does not exist on another machine, or may repartition a data disk unintentionally. Decide whether the install should erase a dedicated system disk, preserve existing data, or use a carefully scoped partition layout. Test destructive storage actions on a disposable virtual machine first.

Verified: AutoYaST profiles can configure storage, network settings, software selection, and other YaST-managed resources. Target-dependent: the correct device names, partitions, package sources, and network values. Action: compare your inventory with every hardware-specific value in the profile before deploying to a fleet.

2. Create a reference profile with YaST

On a clean, representative SLES 15 system, install or confirm the AutoYaST configuration tools. SUSE’s guide names the autoyast2 and autoyast2-installation packages. In YaST, open the Autoinstallation Configuration module and use Tools > Create Reference Profile to select the configuration sections you need. For a full clone, run:

sudo yast clone_system

Both methods create /root/autoinst.xml. Treat this as a starting point, not a fleet-ready answer: a cloned profile can contain machine-specific storage, network, and identity settings. Remove or generalize values that should vary between targets.

Review the generated XML with an editor that understands XML. The profile root uses the SUSE YaST namespaces, and its sections must follow the schema expected by the matching SLES release. Prefer YaST’s profile tools or SUSE’s documented examples for complex sections such as partitioning and boot loader configuration; do not paste an unverified fragment into a production profile.

Action: save a working copy of the profile outside /root, restrict read access, and keep the untouched generated copy as a reference for comparison. See SUSE’s AutoYaST Guide for SLES 15 SP7 and its chapter on creating a control file.

3. Adapt the profile for repeatable installs

Make changes deliberately, section by section. Common areas to review include general installation behavior, registration and extensions, partitioning, software selection, network configuration, time settings, users, services, and any post-installation scripts. Keep the profile as similar as possible across machines and vary only what must differ.

For several hardware groups, SUSE supports rules and classes to combine a base profile with machine- or group-specific settings. It also supports ERB templates and pre-installation scripts for dynamic profiles. These features add flexibility and more ways to make an install fail, so begin with one static profile unless you have a real need to branch. A subtle but important detail: the SLES 15 SP7 guide says rules and classes are supported with the autoyast=URL boot parameter; autoyast2=URL retrieves a single control file and does not activate rules processing.

Handle credentials carefully. Profiles can contain password hashes, registration information, or other sensitive values. Use encrypted passwords where supported, avoid plain-text secrets, and do not expose a profile directory to the public internet. Protect both the file and any web or network service that serves it. Scripts and ERB in a profile are powerful: they may run with root privileges during installation.

Action: put reusable settings in a base profile, isolate per-model or per-role changes in rules/classes only when needed, and review the final rendered XML for secrets and unintended disk operations before publishing it.

4. Validate the XML and AutoYaST interpretation

First check that the document is well-formed XML and matches the SLES 15 schema. SUSE documents validating tools such as xmllint or jing. On an installed SLES system with the relevant AutoYaST tools, run the profile checker:

sudo yast2 autoyast check-profile \
  filename=autoinst.xml output=result.xml

The checker reads, builds, and can import the profile to identify problems before installation. Review both its messages and result.xml; AutoYaST may normalize or clean up the profile, so the processed output can differ from the source file. If your profile includes scripts or ERB, only enable options that execute them after reviewing the code. SUSE warns that such code can run as root. Check the profile in an isolated test environment using trusted files.

Validation results can differ from the install environment if the host used for checking has different YaST packages, architecture, or service-pack media. Installation-time validation is enabled by default on SLES 15 SP3 and later; do not disable it simply to get past an error. Correct the profile or explain and verify the exception instead.

Action: run schema validation and check-profile against the exact profile you plan to serve, then repeat the check after every change to partitioning, software, scripts, or dynamic rules. SUSE’s SLES 15 SP7 AutoYaST manual documents the checker and its limitations.

5. Serve the profile where the installer can reach it

For a network installation, place the control file on a reachable server using HTTPS, HTTP on a trusted isolated provisioning network, NFS, or another transport supported by the installer. HTTPS protects the connection in transit when configured correctly. Make sure the installer can initialize its network before fetching the profile; SUSE documents combining network setup with the AutoYaST parameter, for example:

netsetup=dhcp autoyast=https://provision.example.net/sles15/autoinst.xml

For USB or custom installation media, the profile can also be supplied locally. SUSE documents automatic discovery of a file named autoinst.xml at the root of custom media, as well as explicit file and USB URLs. Choose the transport that fits your boot process and access controls.

Do not put a username and password directly into the boot URL for convenience: boot parameters may be recorded in logs or visible to operators. Use a restricted provisioning network or an access method appropriate to your environment, and protect files that contain sensitive values.

If serving profiles by target, AutoYaST can retrieve a profile from a directory based on system identity. The URL must be a directory path ending in a slash, and the server must contain the matching filenames documented by SUSE. For rules/classes, the expected rules file is under the rules subdirectory. These are different lookup patterns; test the exact requested URL from a target-equivalent environment before booting a machine.

Action: from the installer network, confirm DNS resolution, routing, certificate trust, and profile availability. Use a test machine’s logs or web-server access logs to prove that it fetched the intended file, not merely that the provisioning server is online.

6. Start the SLES installer with AutoYaST

Boot the target from the matching SLES 15 installation medium or network boot environment. At the boot loader, add the AutoYaST kernel parameter pointing to the profile. For a single profile, the documented pattern is:

autoyast=https://provision.example.net/sles15/autoinst.xml

The exact menu labels and method for editing boot parameters depend on the ISO, boot loader, firmware, and network installation setup; follow the guide for your medium. Confirm that the profile URL and installation source refer to the intended SLES 15 service pack. A profile can be valid XML and still select unavailable repositories or packages if paired with the wrong media.

For the first test, install a virtual machine with disk size and network behavior similar to the intended server. Watch for profile validation errors, missing repositories, unexpected prompts, registration failures, and reboot behavior. Do not launch a full batch until one complete installation reaches the expected login state and passes your checks.

7. Verify the installed system before scaling out

After the test installation finishes, check the result against a short acceptance list:

• The machine installed the intended SLES 15 service pack and architecture.
• The expected disk was partitioned, and no unrelated disk or data was changed.
• Hostname, network configuration, DNS, time synchronization, registration, and repositories are correct.
• Required packages and services are present, and unwanted services are disabled.
• The machine reboots without returning to the installer and can be administered through your normal secure access method.
• The logs show that the intended AutoYaST profile was fetched and that no unresolved validation or script errors remain.

Only after the test passes should you add more hardware classes or deploy to a larger group. Capture the profile revision, installation media version, hardware identity, and any differences in the outcome. If different systems need different layouts or network settings, expand the profile with rules/classes and validate each resulting profile before the next rollout.

Common mistakes and the useful check

• A profile from an older SLES release will work unchanged. Not necessarily; SUSE notes that SLES 15 brought significant AutoYaST changes. Start from a profile generated for the SLES 15 release you intend to install, then validate it against that release’s media.
• A successful XML parse means the installation plan is safe. XML validity does not confirm disk selection, repository availability, or the result on different hardware. Review destructive settings and run a test installation on a disposable target.
• A dynamic profile can be tested without executing its code. Some profile transformations and scripts change the final XML. Test only trusted code, understand when it runs, and inspect the rendered result before using it on production systems.
• Any AutoYaST boot parameter supports rules and classes. In SLES 15 SP7, SUSE documents rules/classes for autoyast=URL, not autoyast2=URL. Use the documented parameter and directory layout, then verify which file was fetched.

AutoYaST makes SLES deployment repeatable when the profile, media, and target assumptions agree. A successful test install is the practical proof: it should complete without manual prompts, produce the planned disk and software layout, and pass your own post-install checks. Revalidate whenever the SLES service pack, hardware family, profile logic, or repository set changes.