# 3. Installing Boot the USB stick you wrote in chapter 2. The live system starts the Alloy installer by itself; there is nothing to type at a prompt and no desktop to find it in. On an already-installed machine the same unit is inert, so the installer cannot fire by accident. The installer is `alloy install`, a wizard over `bootc install to-disk`. bootc does the real work: partitioning, the ostree deploy, and the bootloader. The wizard asks four questions, shows you what it is about to run, and runs it. ## The six screens **1. Disk.** Every disk the machine can see, with its size and model. This is the one answer nothing later recovers from, so it comes first: if the disk you expect is not listed, stop here rather than after typing a password. **2. Hostname.** What the machine is called on your network and in your prompt. **3. Account.** Your username, your password, and an SSH public key. Alloy creates one account and does not enable a root login. The key is optional at this screen and it is not optional if you ever want to reach this machine over the network; see "Signing in over SSH" below. On a medium you minted with a key baked in, this field arrives already filled with that key. **4. Encryption.** Optional, and if you say yes you type a passphrase and then see a recovery phrase. Read the next section before deciding. **5. Summary.** Every command the installer is about to run, in order, before any of them runs. Nothing is hidden behind a progress bar. **6. Credits.** What Alloy ships, each project's license, and its URL. It is the only screen that asks nothing, and the install starts from here rather than from the summary: the last screen before a disk is erased should be the one naming whose work is about to be written to it. Then the install runs, streaming its output, for the several minutes bootc takes. ## Encryption and the recovery phrase Choosing encryption sets up LUKS on the root filesystem and binds it to the machine's TPM, so the disk unlocks at boot without a password prompt. That binding has one failure mode that ends in permanent data loss: the TPM stops answering. Clearing it, replacing the board, or moving the disk to another machine all do that. So Alloy enrolls two ways in rather than one: - **Your passphrase**, the one you typed. - **A recovery phrase**, eight words the installer generates and shows you once. Write the recovery phrase down on paper. It is not stored anywhere you can read it back from later, it is never rotated, and it is what stands between a dead TPM and a lost disk. Words rather than a random key string because this is a phrase a person reads off one screen and types into another, months later. If you skip encryption, none of this applies and the disk is readable by anyone holding it. ## After the install Reboot and remove the medium. You land on the greeter (tuigreet on VT1), sign in with the account you made, and sway starts. A machine installed from a locally built medium has its update timer disabled. It will never poll anything. Chapter 8 covers what updating means instead. ## Signing in over SSH Alloy accepts a key and nothing else. `PasswordAuthentication` is off, the keyboard-interactive path that can authenticate a password behind it is off, and root is key-only. That is the policy for every install, both profiles, and it is set in `/etc/ssh/sshd_config.d/10-alloy.conf` rather than left to whatever the Fedora base happens to default to. The account screen is where a key gets onto the machine. Paste the public half of a keypair you already hold, usually the contents of `~/.ssh/id_ed25519.pub` on the machine you will connect from. The installer checks it is a public key sshd will actually read, writes it to the new account's `~/.ssh/authorized_keys`, and sets the modes sshd insists on. You may finish an install without a key, and for a desktop that is a reasonable answer: you are sitting at the greeter, so you log in on the console and add a key afterwards. The installer says so on the summary and again on the gate before it writes the disk, because from the far side of a reboot there is no way to tell a machine you did that to from a broken one. On a machine with no screen it is not a reasonable answer, and there is nothing to recover with. Put a key on the account screen. ### Adding a key after the fact From a console session on the machine: ``` mkdir -p ~/.ssh chmod 700 ~/.ssh cat >> ~/.ssh/authorized_keys # paste the key, then Ctrl+D chmod 600 ~/.ssh/authorized_keys ``` The modes are not decoration. sshd refuses to read an `authorized_keys` that anyone but its owner can write, and it refuses silently as far as the client is concerned: you get "permission denied" and the reason goes only to the server's journal. ## Installing without a screen `alloy install` needs a terminal, and on a machine with no display that terminal comes over the network. Mint the medium with a key and a hostname baked in, boot it, and continue from another machine: ``` ssh installer@.local ``` The connection lands in the installer itself rather than in a shell, so there is no command to get wrong. The key you connect with is also what the account screen offers you for the machine being installed, so you are not pasting back the credential you are already holding. Two things make that flow work and both are worth knowing. The `installer` account exists only on the live medium, so an installed machine has no such user and no way to reach `alloy install` over SSH. And the machine is found by mDNS, which means the LAN it is on and not Tailscale; a freshly booted medium has joined no mesh. Chapter 2, "Baking in a key and a hostname", covers minting such a medium.