7.3 KiB
suse-autoyast-workflows
Practical, honestly-labeled AutoYaST deployment workflows for openSUSE Leap, SLES, and Tumbleweed.
REFER TO ALL RELEVANT OFFICIAL SOFTWARE MANUALS
Public domain. Built in Brianza. Designed for anyone deploying SUSE with AutoYaST.
What This Is
A set of process workflows for partially unattended openSUSE installation via AutoYaST — covering client device profiling, VM-based pre-deployment testing, and the bare-metal deployment that follows it. Built from real, documented deployment experience, not theoretical best practice.
[WARNING] This repository is a guiding template, not a source of truth. SUSE's own documentation — documentation.suse.com — is authoritative for whatever SLES/Leap/Tumbleweed release is actually being deployed. Find and read the AutoYaST Guide for that specific release; don't assume an example seen elsewhere still applies. AutoYaST syntax, package availability, default groups, and repo layout all shift between releases; a detail confirmed here on one version is not a standing guarantee for another. Adapt this repo's guidance to the current release's own manual before relying on it, every time, not just on first use.
This isn't a theoretical caution. The project that generalized into this repo burned real time chasing exactly this: assuming a detail true for one openSUSE release still held for the target being deployed, when it didn't. Thirteen install passes traced back, in part, to not re-checking the current release's own guide closely enough at each step. Don't repeat that mistake by trusting this repo the way it should have trusted the current manual instead.
[WARNING] The same applies to the virtualization tooling this repo's
workflows depend on. libvirt, virt-install, virt-viewer, and QEMU
each version independently of the SUSE release being deployed and of
each other — flag syntax, default behavior, and firmware/TPM support
change between releases. The
libvirt documentation and each tool's
own man page are authoritative, not this repo. A command confirmed
working here on one host's package versions is not a standing guarantee
on a different host, a different tinkerpad13 update cycle, or a
different distro's packaging of the same tools.
AutoYaST automates the configuration decisions — package selection, partitioning, privilege escalation setup — but this is not a walk-away install. Physical presence (or its VM equivalent, a watched console) matters throughout: AutoYaST's own documentation notes that some interactive dialogs bypass suppression entirely, and this repo's workflows are built around staying attended for exactly that reason. "Partially unattended" is the honest description — the profile does the deciding, a person does the watching.
This repository is in progress. Several referenced sub-workflows don't exist yet (see Status below) — what's here is published as an honest work in progress, not withheld until complete. Consider this the technical process layer: version selection, media policy, VM tooling, test-cycle mechanics. It does not cover AutoYaST profile authoring itself, which lives in its own not-yet-written workflow, or any business-process content around client engagement — this repo is deployment mechanics only.
Where This Comes From
This workflow set was generalized out of a real deployment project —
migrating a ThinkPad from Alpine to openSUSE Tumbleweed via AutoYaST,
across thirteen documented install passes. That project surfaced the
core technical problem this repo's guidance is built around: openSUSE's
Defaults targetpw sudo behavior, which breaks the standard RHEL-style
privilege escalation pattern unless addressed explicitly.
That original project's full build log — warts, false starts, and all — stays a separate, private record. This repository is downstream of it, not a sanitized copy of it: everything here is written fresh, as general-purpose process, not as an account of what happened on any one specific machine.
Scope
Covered: openSUSE Leap and SLES, as the primary target — point releases where a DVD image stays representative of what actually installs, making genuine pre-deploy VM testing possible. Tumbleweed is not excluded, but its rolling-release nature changes the guarantees the test cycle can offer; see the deploy workflow's own notes on this.
Not covered: AutoYaST profile authoring itself (package selection, partitioning, post-install script content) — referenced from this repo's workflows but documented separately. Client engagement mechanics and pricing (how a handoff is billed, structured, or negotiated) are deliberately kept out of this repository entirely; that's specific to whoever's deploying and isn't this repo's business.
Covered, at the principle level: client empowerment as a closing step. This repo's deploy workflow recommends ending every deployment with a handoff — a portable copy of the deployed VM in whatever deliverable form suits the situation, plus a basic usage guide the deployer writes for that specific client. What form the guide takes, how the copy is delivered, and how any of it is billed are left entirely to the deployer; the recommendation is that a handoff happens and empowers the client, not a specification of how.
Two example handoff documents are included as reference: a generic
user's guide (suse-user-guide-example.md) and a planned
administrator's guide, showing the kind of thing this recommendation
actually produces. Neither contains, nor should ever contain, real
credentials, passwords, or any client-specific detail — a guide
documents how to authenticate, never what to authenticate with. Treat
them as a starting shape to adapt, not a template to fill in verbatim.
Status
Early, actively being refined. One real-world deployment (Tumbleweed) informs the current guidance; Leap and SLES guidance is not yet verified against an actual test pass. Several sub-workflows this repo's documents reference are not yet written:
| Referenced | Covers |
|---|---|
autoyast-crafting-workflow.md |
Authoring/selecting the AutoYaST profile itself — not yet written |
autoyast-error-debugging-workflow.md |
Diagnosing a failed verification check to root cause — not yet written |
suse-deploy-post-install-testing-workflow.md |
Post-install inspection beyond pass/fail — not yet written |
device-profile.md |
Client device intake sheet — not yet written |
suse-autoyast-deploy-phase2.md |
Bare-metal deployment at the client site — closes with the client handoff recommendation — not yet written |
suse-user-guide-example.md |
✅ Written — generic user's guide, worked example |
administrator-guide-example.md |
Generic administrator's guide — not yet written |
[UNVERIFIED] tags throughout the existing documents mark specific
claims not yet confirmed on Leap/SLES — check these explicitly before
relying on them for a real deployment.
Licence
All original content in this repository is released to the public domain under the Unlicense.
Project
Cervello Elettrico OS — git.jhoeven.net/ceos
Brianza, Italy · servizi@cervelloelettrico.it · cervelloelettrico.it
Crafted by John A. Hoeven with the ethical assistance of Claude AI (Anthropic).