An automated setup that stops halfway feels worse than a manual install failing — the machine did it, not you, so where do you even look? This page gives the calm order: find where it stopped, fix the cause, then decide between continuing and rebuilding.
Automated installs fail for boring reasons: a network cable that was not seated, a mirror that was down, a disk name that differed, an answer file with one wrong line. The good news is that the installer writes down what it was doing when it stopped. Your job is to read that record instead of guessing, because guessing at a half-built server creates a machine nobody fully understands.
Every automated setup keeps a log. On cloud-style and first-boot setups it is commonly /var/log/cloud-init.log and the matching output log; installer-based setups keep their log on the install console and in the installer’s log directory. If the machine will not boot at all, boot the install media again and read the log from there.
tail -n 30 /var/log/cloud-init.logMost half-finished setups stop at one of a handful of stages, and each has a short list of usual suspects.
Good setup tools are written to be idempotent — running them again skips what is already done and only does what is missing. Package installs and service enables behave this way. But not everything does: a step that creates a user will complain the user already exists; a step that appends a line to a file may append it twice. A rerun is safe when the failing stage and everything after it is all that runs again, or when the recipe is known to check before it acts.
Choose with this rule. Continue when the failure was external (network, mirror, power) and the stages before it are verifiably complete. Rebuild when the failure was in your answers about the disk, accounts or core design — a clean rerun with corrected answers takes minutes on an automated setup, and it gives you a machine whose history you fully know. A patched-up half-install is a debt every future problem will collect on.
Keep this routine beside you the first time you run any automated setup — including the one in the video — and a failure becomes a ten-minute detour instead of a lost evening.
▶️ Watch Full VideoBoot the machine from the install media again and choose its rescue or shell option, or attach the disk to another Linux machine. The log files sit on the half-installed disk exactly where they would be on a finished system, and they can be read without the server booting.
Often yes, and for answer-file installers that is the designed path — the disk stage wipes and starts clean anyway. For first-boot script setups, check whether the steps tolerate a second run. When in doubt, the clean rebuild is the honest answer.
Fix the answer file, not just the machine. If the mirror was down, that is weather; but if a package name was wrong or a disk name differed, the recipe itself needs the correction, plus a note in your own words beside it.