Install with setup

You have a root shell on the live system. Four commands install the machine, with a fifth for a tunnel if you want one, each a page of this chapter:

Command	What it does	Changes the target?
setup host	Asks what this machine is, and writes it down	No
setup disk	Partitions, encrypts, formats and mounts the disk, adds swap	Erases the disk
setup install	Installs, makes it boot, sets up network, accounts and SSH	Writes to /mnt
setup wireguard	Gives it a WireGuard tunnel of its own (optional)	Writes to /mnt
setup reboot	Checks everything, then unmounts and reboots	No

Run setup with no arguments and it shows the same list, with a mark next to each step already done, and offers to run the next one.

How setup behaves

• It reads the host repo and nothing else. Every step starts by reading /root/arch/host.env, never a shell variable, so a dropped SSH session loses nothing: reconnect and run the step again.
• Every step is safe to run again. A step that has already been done says so and skips, or only does what is missing. The one step that cannot be repeated – erasing the disk – makes you type the hostname first.
• It shows you before it does anything. Each step prints a review screen and asks. setup --yes <step> answers yes for you, except to erasing a disk.
• It walks you through. setup with no arguments shows which steps are done and offers to run the next one, then the one after that, so an install is one command and a series of questions rather than four commands typed from the book. Declining stops there, and so does a step that fails. The reboot at the end is the exception: pressing Enter declines it, because wanting a look around before the machine goes down is the normal case.
• It prints what it runs. Every command is echoed with a leading + before it runs, so the output is a transcript of exactly what was done to the machine.
• It keeps that transcript. All of it is written to logs/000_SETUP.txt in the host repo, committed, and copied to the installed machine, with a header per step recording the time, whether the clock was synchronised, and which image did the installing. Months later, git log in ~/arch still answers “how was this machine built?”. Passwords and passphrases are not in it: they are read from the terminal, never printed.
• It is one readable file. setup is a bash script at /usr/local/bin/setup. less $(which setup) is the documentation of last resort, and the pages that follow say which part of it does what.

just provision copies the current setup onto the stick’s config partition, and the live system prefers that copy to the one built into the image, so a fix to setup reaches a stick without rebuilding it.

Three machines

Three machines are in play during an install, and the command blocks in this chapter say which one each runs on:

Machine	What it is
your workstation	The computer you are already sitting at, running your editor and SSH client.
the live system	The target machine booted from the BOOMSTICK, running in RAM. setup runs here.
the target	The system being installed, mounted under /mnt until it boots on its own.

setup works on the target from the live system, using arch-chroot /mnt for each command that has to run inside it, so you never have to keep track of which side of the chroot you are on.