Preseed: why manual Linux installation doesn't scale
Manual Linux installation scales up to the first ten machines — after that, configuration drift begins.
Disk partitioning on each new machine is done from memory: somewhere root is 40 GB, somewhere 100 GB, volumes get different sizes, and a swap partition as a separate block exists on only half the servers. Formally it is the same server, in practice it is ten different ones.
Then packages and kernel versions diverge. The base set is assembled from a guide, from someone else's note, or from command history on a workstation, so a forgotten backup agent or monitoring client surfaces a week later already in prod.
Machines come from different repository snapshots and behave differently under load — differences are investigated during an incident, when it is already unclear what exactly failed.
Deployment errors cost not a redone installation, but nighttime downtime. Onboarding a new machine takes hours and depends on an engineer who remembers the sequence of steps; in a hurry, the steps change, and the result becomes non-reproducible.
Replication to another zone or failure recovery turns into a separate project with its own schedule.
We break down how this stage is addressed by server installation automation.
Preseed answers the installer questions in advance — disk partitioning, package set, accounts, network, post-first-boot finishing — and the machine comes up from a single description, identically on the first and the hundredth installation.
What automated server installation provides: the effect in numbers
Automated Linux installation pays off not through the speed of one installation, but through repeatability: a node comes into service from a single description and in a predictable state.
Below is a checklist we use to verify the result before and after moving to a template: provisioning time, share of operations without manual involvement, and the class of failures caused by differing machine configuration.
- Server deployment time. A node goes from power-on to role readiness in minutes instead of hours of manual clicks — disk partitioning, network, package set, and access are taken from the answer file.
- Share of operations without manual involvement. Installation, base configuration, and connection to monitoring happen without an engineer entering the console; only decisions requiring choice remain manual.
- Reduction of manual errors. A typo in partitioning, a forgotten partition for logs, a diverging package set — these causes go away because the template is single and passes review in the repository.
- Configuration repeatability. Two machines from one template are indistinguishable by package composition, kernel parameters, and access settings: there are no "special" nodes left that cannot be rebuilt.
- Single installation template. Preseed for Debian and derivatives, Kickstart for the Red Hat family, Autoinstall for current builds — the carrier is different, the rules are described the same way.
- Incidents caused by differing configuration. The share of failures rooted in machine desynchronization drops to isolated cases, and node recovery comes down to re-running the template.
Comparison of Preseed, Kickstart, and Autoinstall: what to choose
All three approaches address one task — automated Linux installation without manual answers to installer questions. The difference is in the distribution family and in how declaratively the node is described. In practice, the choice is dictated by the existing machine fleet, not by engineer preference.
Where each template is appropriate
| Approach | When it fits | Limitations and how they are compensated |
|---|---|---|
| Preseed | deb family in an existing fleet, installation from local media | Poorly describes complex partitioning and post-configuration — supplemented by post-first-boot scripts |
| Kickstart | RPM family: partitioning, packages, and initial configuration in one file | The template is sensitive to distribution branch changes — versioned and run on a reference image |
| Autoinstall | New deb-family nodes, network and cloud installations | Requires a network source and a recent installer — the older fleet remains on preseed |
The boundaries blur: preseed is supplemented with post-installation scripts, kickstart with a section containing post-configuration commands, autoinstall with modules that bring the node to a working state.
The installer answer template remains the single source of truth about partitioning, so it is stored in version control together with images.
We check compatibility by re-running on reference hardware and in a virtual environment: the result must match, without adding partitions on the second run. If the old and new fleets coexist, we assemble a hybrid scheme and document which template applies to which node.
Stages of implementing automated installation: from audit to acceptance
Automated installation breaks not on the answer template, but on an unaccounted configuration: a different disk controller, non-standard partitioning, an old boot method.
Therefore, implementing automated installation proceeds in stages, and each ends with a verifiable artifact — a failure is localized at a specific step rather than surfacing on a production server a month later.
- Infrastructure audit. Inventory of the fleet: models, disk controllers, network cards, current boot methods, and accumulated manual edits. The output is a table of machine groups and a list of what requires a separate profile.
- Disk partitioning scheme. For each role — hypervisor, database, application, workstation — we approve a unified scheme: boot partition, root, separate volumes for data and logs, encryption rules.
- Machine profile catalog. We bring Preseed, Kickstart, and Autoinstall templates into one repository: base profile, role layers, network and hostname variables. One source of truth instead of copies, changes through review.
- Installation service. Network boot and a local package mirror: dozens of machines are installed in parallel and do not depend on an external channel.
- Test bench. We verify not only the happy path: repeat installation, network interruption, missing disk, different memory size. Separately — failure behavior and rollback correctness.
- Pilot group. 5-10 machines from different groups: we measure time to a ready node and the share of installations without manual intervention, and adjust profiles based on facts.
- Deployment regulations and acceptance. We hand over documentation: how to add a role, update a profile, file an exception. Profiles are versioned — the customer retains a reproducible process.
Deliverables: configurations, schemes, and regulations
After the installation environment is handed over, the customer retains a working package, not a set of files on someone's laptop.
Everything related to automated Linux installation — answers for Preseed, Kickstart, and Autoinstall, partitioning, access, and the procedure for edits — is in your repository and described so that a new engineer can understand it without contacting us.
- Answer files by profile — a separate template per machine role (web node, database, balancer), with comments for each non-obvious parameter and variables moved outside instead of hardcoded values.
- Profile-to-hardware mapping — a table used to select the template when onboarding a new node, so that the configuration is not copied at random or edited in haste.
- Partitioning map — partition schemes, volume groups, mount order, and space reserve for logs and backups, agreed with data retention policies.
- Access policies for the installation service — who and with which key accesses the boot server and package repository, record lifetime, and the procedure for revoking them when an employee leaves.
- Installation regulations — a step-by-step procedure for the on-call shift: checking image checksums, profile selection, result control via logs, and actions on failure at each stage.
- Change procedure — any template edit passes a trial run in a virtual environment and review by a second engineer, and only then enters the production environment; rollback to the previous version is described.
- Knowledge transfer to the team — a walkthrough of the environment with your engineers, the procedure for accepting a new node, and an assigned owner, so that support does not depend on one person.
Case: a server fleet without manual installations
A fleet of several dozen nodes was deployed by hand: an engineer connected the image, answered installer questions, and separately configured network, partitioning, and access.
Onboarding one machine took 3–4 hours, installations were scheduled in nighttime windows, and configuration discrepancies surfaced already during commissioning. The on-call shift spent time handling identical failures instead of real tasks.
We started with inventory: we classified machines by class — web nodes, databases, service hosts — and for each described the installer answers in a template file.
For a Debian fleet this is Preseed, for other families — Kickstart and Autoinstall; the logic is the same: disk partitioning, time zone, network, access keys, package set, and initial security settings are specified in advance rather than entered manually.
The template is versioned and run on a test bench, so a new profile version does not break already deployed nodes.
What changed in the process
We separately addressed reproducibility: installation starts from the boot server over the network, after first boot the post-configuration runs, and the machine automatically joins the configuration management system.
The engineer does not enter the console — they only verify that the node has appeared in monitoring.
Metrics before and after
- Node provisioning time: 3–4 hours → 20–30 minutes, including verification.
- Share of identical failures at start: approximately every fifth node → isolated cases.
- Nighttime windows for installations: needed → not needed, deployment happens during working hours.
- New machine class: a week of manual work → a day to prepare the template.
- On-call shift load: routine installations → handling real failures.
The templates, class profiles, and procedure for adding new nodes were handed over to the customer's team — the fleet can now expand without our involvement.
What to do if part of the fleet is already deployed manually?
A mixed fleet is a normal state: some machines were once brought up by hand, some already go through automated installation.
The problem is not the fact itself, but that manual hosts diverge in package composition, partitioning, and access, and understanding how one differs from another is often more expensive than rebuilding it from a template.
We start with inventory: automated collection of an inventory captures the actual state of each machine — packages, running services and their dependencies, mount points, open ports, accounts, scheduled tasks.
The output is a table "host — role — load — owner," which shows which machines duplicate each other and which carry unique work.
Next, we assemble a reference automated installation answer template. Common to all — the base package set, disk partitioning, network parameters, access keys, update sources; everything role-specific is moved into variables.
One preset then produces both an application node and a database server, without manual finishing after installation.
The migration proceeds in stages.
First — machines that are easy to bring up again, then read nodes, removed from load balancing one at a time: the new host comes up automatically, is checked against the inventory before and after, is put into operation, and the old one remains in reserve until the end of the observation period. We touch write nodes last — with a maintenance window and a ready rollback plan.
As a result, any server comes from one source, and deviations are visible when comparing inventory with the template: manual edits cease to be the norm, and reinstallation takes minutes instead of an evening.
Common technical doubts and answers
Common questions about automated installation from engineers coincide: how one profile will fit different hardware, whether it is safe to keep credentials in it, how to update the template without risk to running machines, and what to do during an unsuccessful rollout. Below are brief answers to each.
Will one profile fit different server models?
Yes, if differences are moved into conditions: the network interface is selected by hardware address, a specific disk controller gets its own partitioning scheme, and rare models are covered by separate rules.
The profile is run on every machine in the fleet before rollout — discrepancies are visible in advance, not on the first production server.
Isn't the installation template a security hole?
The answer file contains installer credentials, so it is stored in a private repository, transmitted over an encrypted channel, and deleted from the machine after installation completes.
Passwords are injected when the profile is built, not stored in it in plain text; edits are role-based with a change log.
How to update profiles without breaking installed machines?
The profile is versioned like code: an edit is tested in a test environment and only reaches new installations. Already running servers are changed separately, through configuration management, so a template update does not affect them.
What to do if installation failed?
Disk partitioning and package composition are described declaratively, so a failed machine is reinstalled from scratch in minutes, without manual operations. The previous profile version remains in the repository — reverting to it reproduces the previous configuration entirely.
Let's discuss the task: where implementation begins
So that the estimate is tied to your fleet rather than an industry average, we need a snapshot of it during the task discussion. Answers to a few questions are enough — after that we will consolidate them into a scheme and define the scope of work.
- inventory: node roles, differing models, disk sizes, current partitioning, and boot method;
- boot network: is there a remote installation environment, own DHCP, or does it need to be isolated from production;
- target state: LVM or RAID, encryption, filesystem, mount points;
- system parameters: accounts and access keys, time zone, locale, required package set;
- non-standard cases: machines without wired network, nodes with UEFI and Secure Boot enabled, reinstallation over an existing one;
- post-installation control: which checks must pass automatically before the node goes into operation.
We choose the answer mechanism for the distribution — Preseed, Kickstart, or Autoinstall. It is important that one template covers the entire fleet without manual edits on site, otherwise automation turns into the same manual installation, only longer.
There are usually two starting options. A pilot run on three to five nodes is the fastest way to test the template on live hardware and see where automation stumbles, without breaking anything in prod.
If the fleet is homogeneous, it is more reasonable to migrate it entirely at once: the template is written once and then works on all machines.
Describe the task, the fleet, and access constraints — we will return with an estimate, a work plan, and a proposal for the starting option.