Installing Arch Linux, part 1: boot and disks

If you read why Arch Linux and decided you want the do-it-yourself machine it offers, this is where the building starts. This part covers everything from downloading the installation image to the moment your disk is partitioned, formatted, and mounted, ready to receive the operating system. Everything here mirrors the official Arch Installation guide, which you should keep open in another tab — this post explains why each step exists, but the wiki is the source of truth and is kept current against the rolling release.

level:Intermediate verified:Jun 2026

ℹ️ Hands-on — run these in the Arch live environment on a real or virtual machine. Each section says where you are: the live ISO, inside the chroot, or the booted system.

⚠️ Read this on a second screen, on a machine you can afford to wipe. Keep this guide open on a phone or another computer — the machine you're installing on boots into a bare console with no browser. A manual Arch install will surprise you, and a wrong choice somewhere often means starting over; that is normal the first time. Use a spare box or a VM where losing everything costs you nothing.

⛔ Danger — Partitioning erases data. Do this on a spare machine, a spare disk, or a virtual machine for your first run, and back up anything you care about before you touch a disk.

Here is the whole arc of this post at a glance — the first few steps happen on your current computer, the rest inside the booted Arch live environment:

flowchart TD
    A["Download ISO"] --> B["Verify checksum<br/><i>and signature</i>"]
    B --> C["Write bootable USB"]
    C --> D["Enter boot menu<br/><i>vendor key</i>"]
    D --> E["Boot live environment"]
    E --> F["Connect to network"]
    F --> G["Sync the clock"]
    G --> H["Partition the disk"]

The flow from your current machine into the Arch live environment; the network/clock/partition steps are identical on every host OS.

Get the ISO and verify it

Download the installation image from the official download page. The what here is the ISO file — a single bootable disk image; the why is that this is the only place the Arch project officially publishes it. The download itself is the same on every operating system: pick a mirror close to you, or use the BitTorrent link (which is often faster and spreads load off the mirrors). Grab the ISO file, and alongside it the PGP signature (.sig) for that exact ISO.

The signature is what lets you confirm the file you downloaded is genuinely the one Arch published and was not tampered with in transit — which matters most when you grab the ISO from a community mirror rather than directly from archlinux.org. Skipping verification is common and usually fine, but it is a genuine security step and takes a minute. There are two pieces you can check: the SHA-256 checksum (catches a corrupted or truncated download) and the PGP signature (proves it was signed by an Arch developer). The signature is the stronger guarantee. How you run the check depends on the computer you are doing it from — this is a host-machine step, done before you boot anything:

• os:windows check the checksum in PowerShell with Get-FileHash -Algorithm SHA256 archlinux-version-x86_64.iso and compare the output against the value on the download page. For the PGP signature, install Gpg4win and run gpg --verify archlinux-version-x86_64.iso.sig.
• os:macos check the checksum with shasum -a 256 archlinux-version-x86_64.iso. For the signature, install GnuPG (for example via Homebrew, brew install gnupg) and run gpg --verify archlinux-version-x86_64.iso.sig.
• os:linux check the checksum with sha256sum archlinux-version-x86_64.iso. If you already have an Arch system, verify the signature in a single command with pacman-key -v archlinux-version-x86_64.iso.sig; on any other distribution use gpg --verify archlinux-version-x86_64.iso.sig.

The download page links full signature verification instructions. The principle, as the wiki notes, is that the signature itself could be tampered with if you got it from a mirror, so you confirm the public key's fingerprint matches the Arch developer who signed the image. If you want the background, see public-key cryptography.

Write a bootable USB

You now need to put that ISO onto a USB flash drive so the target machine can boot from it. The why: the installer is not something you "install" onto your current system — it is a live environment the target machine boots straight off the stick, so the ISO has to be written as a raw bootable image, not just copied as a file. There are several ways, all covered on the wiki's USB flash installation medium page. This is still a host-machine step, so it differs by the computer you are using:

• os:windows use a graphical tool, since dd is not available. Rufus is the standard choice: pick the ISO, pick the USB device, write it. Alternatively, Ventoy installs once onto a stick and then boots any ISO you simply copy onto it — convenient if you try several distributions.
• os:macos the easiest option is the balenaEtcher GUI (select image, select drive, flash). If you prefer the terminal, dd works the same as on Linux — see the command below.
• os:linux use balenaEtcher for a GUI, or dd from a terminal, which writes the ISO byte-for-byte to the device.

For the dd route (macOS or Linux), confirm the device with lsblk (Linux) or diskutil list (macOS) first, then:

⛔ Danger — dd writes raw bytes to whatever device you name and gives no confirmation prompt. Name the wrong disk and you erase it instantly — point of= at the USB stick (e.g. /dev/sdb), never your system drive.

dd if=path/to/archlinux-version-x86_64.iso of=/dev/sdX bs=4M conv=fsync oflag=direct status=progress

Here if= is the input file (your ISO) and of= is the output device (your USB stick, something like /dev/sdb — not a partition like /dev/sdb1). Any of these tools produces the same bootable Arch installer.

Boot the live environment

Plug the USB into the target machine and tell it to boot from the stick. The how is to press a key during the power-on screen to reach either a one-time boot menu (lets you pick the USB just for this boot) or the firmware setup (where you can change boot order and Secure Boot). The exact key is set by the machine's vendor, not by Arch, and the prompt usually flashes briefly at power-on. This is the last host-machine-specific step before everything becomes identical, so by vendor the common keys are:

• Generic desktop motherboards: F12 or F8 for the boot menu, Del or F2 for firmware setup.
• Dell: F12 for the one-time boot menu, F2 for setup.
• HP: Esc for the menu, then F9 to choose a boot device (F10 for setup).
• Lenovo: F12 for the boot menu, or the small Novo button on many ThinkPad/IdeaPad models.
• ASUS: Esc or F8 for the boot menu, Del or F2 for setup.
• Acer: F12 for the boot menu (may need enabling in setup first), F2 for setup.
• Apple (Intel Macs): hold the Option (Alt) key at the chime to reach the startup picker. (Apple Silicon Macs cannot boot Arch this way.)

When in doubt, check your motherboard or laptop manual.

⚠️ Warning — Arch installation images do not support Secure Boot. You must disable Secure Boot in your firmware to boot the installer; you can set it up again later if you want it.

When the installer's boot menu appears, choose Arch Linux install medium and press Enter. After a moment you are logged in automatically as the root user and dropped at a shell prompt. There is no graphical interface — this is the bare console, and everything from here is typed.

ℹ️ Where you are: the live ISO. From this point on, every command runs in the booted Arch live environment as root (the prompt looks like root@archiso ~ #) — not on your current machine anymore. This holds for the rest of part 1: network, clock, partitioning, formatting, and mounting all happen here.

What UEFI is

Modern computers start up using UEFI (Unified Extensible Firmware Interface), the firmware that initializes the hardware and hands control to an operating system's boot loader. It replaced the much older BIOS (Basic Input/Output System) that PCs used for decades. The practical differences that matter to you: UEFI understands a real filesystem and reads boot loaders from a dedicated partition (you will create one shortly), it supports disks larger than 2 TiB via the GPT partition scheme, and it is what essentially every machine made in the last decade uses. BIOS — sometimes presented as "legacy" or "CSM" mode in firmware settings — is the old way, and a few of the steps below differ depending on which mode you are in. This guide assumes UEFI, which is almost certainly what you have.

Confirm you booted in UEFI mode

Before going further, confirm the live environment actually booted in UEFI mode rather than legacy BIOS, because the partitioning and (in part 2) the boot loader depend on it. The current wiki check inspects the UEFI bitness:

cat /sys/firmware/efi/fw_platform_size

Read the result the way the wiki does: if it returns 64, you are in UEFI mode with a 64-bit (x64) UEFI — the normal case. If it returns 32, you are in UEFI mode but with a 32-bit (IA32) UEFI, which is supported but limits your boot loader choices. If it returns No such file or directory, the system is not in UEFI mode — it likely booted in BIOS/CSM mode, and you should go back into your firmware settings and switch to UEFI boot if that is what you want.

Console keyboard layout

The live console defaults to a US keyboard layout. If yours differs, set it now so the passwords and paths you type actually match the keys you press. List the available layouts with localectl list-keymaps, then load yours with loadkeys. For example, for a German layout:

loadkeys de-latin1

Replace de-latin1 with your layout (for instance uk for a UK keyboard). The wiki section also covers larger console fonts via setfont if the default text is too small on a high-resolution screen.

Connect to the internet

The installer downloads packages from Arch's mirrors, so you need a working connection. The wiki's procedure starts by confirming your network interface is present:

ip link

Wired Ethernet is the easy case: plug in the cable and you are essentially done — the live image runs systemd-networkd and systemd-resolved, so DHCP gets you an address and DNS automatically.

Wi-Fi takes a few more steps using iwctl, the control program for the iwd wireless daemon that the live environment ships. iwctl is interactive — you do not paste the next few commands all at once. Running it drops you into its own prompt where you type one command at a time and read each result before the next. Start it:

iwctl

You now have a prompt that begins with [iwd]#. The blocks below are steps inside that interactive session — type the part after the [iwd]# prompt. The iwd wiki page gives the exact sequence. First, find your wireless device's name:

[iwd]# device list

That shows a device name such as wlan0. Using that name, scan for networks (this command prints nothing — that is expected):

[iwd]# station wlan0 scan

List what it found:

[iwd]# station wlan0 get-networks

Then connect to your network by its SSID (the network name), substituting your device name and SSID:

[iwd]# station wlan0 connect SSID

You will be prompted for the passphrase if one is needed. Quote the SSID if it contains spaces. When connected, exit the prompt with Ctrl+d.

Whichever method you used, verify you are actually online with a ping:

ping ping.archlinux.org

Stop it with Ctrl+c. If you get replies, your connection works.

Update the system clock

An accurate clock matters more than it looks: a wrong time causes package signature verification failures and TLS errors mid-install. The live system enables systemd-timesyncd by default, so once you are online the clock synchronizes on its own. Confirm it with:

timedatectl

The wiki just asks you to check that the clock reads as synchronized; there is no manual setting to do here in the normal case.

Partition the disks

This is the step that erases data, so identify your target disk precisely first. List the disks and their current partitions:

fdisk -l

You get one block per disk, something like this for a single empty NVMe drive:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 980
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disks appear as block devices like /dev/sda (SATA) or /dev/nvme0n1 (NVMe). Entries ending in rom, loop, or airootfs are the installer's own bits — ignore them. Find the disk you intend to install onto and note its name; everything below uses it.

What a partition is

A physical disk is one continuous expanse of storage. A partition is a labelled region carved out of it — a way of dividing one drive into separate areas that the system treats as independent volumes. The partition layout is recorded in a small table at the start of the disk; on UEFI systems that table uses the modern GPT (GUID Partition Table) scheme. You partition because different parts of the system want different jobs: one region holds the boot loader, one holds your actual operating system and files, and optionally one is set aside as swap. The disk partitioning explainer covers GPT versus MBR and the EFI system partition in more depth.

What a filesystem is

A partition is just raw space until you put a filesystem on it. A filesystem is the structure that organizes that raw space into files and directories, tracking where each file lives, its name, size, and permissions. "Formatting" a partition means writing a fresh, empty filesystem onto it. Different filesystems make different trade-offs (ext4 vs btrfs vs xfs walks through them); for a standard Linux root partition, ext4 is the reliable, boring default, and FAT32 is required for the boot partition because UEFI firmware can read it.

💡 Tip — Not sure which filesystem to pick? Use ext4. It is the dependable default and nothing in this guide needs anything fancier.

What the EFI system partition is

The EFI system partition (ESP) is a small, FAT32-formatted partition that UEFI firmware reads at startup to find boot loaders. It is the bridge between the firmware and your operating system: when the machine powers on, UEFI looks at the ESP, finds the boot loader there, and runs it. Every UEFI install needs one. Important: if your disk already has an ESP — for example because Windows is installed — you reuse the existing one rather than creating a second, and you must not reformat it, or you will wipe the other system's boot loader.

The layout

Open a partitioning tool on your target disk. fdisk is the wiki's example; cfdisk offers a friendlier text menu and gdisk is another GPT-aware option — any of them works. Like iwctl, fdisk is interactive: this command does not partition anything by itself, it opens a prompt where you step through single-letter commands (g for a new GPT table, n for a new partition, t to set a type, w to write and exit). Nothing is written to the disk until you type w, so you can back out with q if you make a mistake. Open it on your target disk:

fdisk /dev/the_disk_to_be_partitioned

Working inside that prompt, the wiki's recommended UEFI/GPT layout is three partitions (swap is optional):

• EFI system partition — mounted at /boot on the installed system, type EFI system partition, suggested size 1 GiB.
• Swap — type Linux swap, at least 4 GiB (optional; you can skip it and add a swap file or zram later instead).
• Root — mounted at /, type Linux x86-64 root (/), using the remainder of the device, at least 23–32 GiB.

Inside the partitioning tool you create each partition at the sizes above and set its partition type, then write the changes. Take the wiki's advice and plan this layout deliberately — re-partitioning later is risky and tedious.

flowchart LR
    D["One disk<br/><i>/dev/the_disk</i>"] --> E["EFI system partition<br/>FAT32, 1 GiB<br/>mount /boot"]
    D --> S["Swap<br/>4 GiB, optional<br/>mount swap"]
    D --> R["Root<br/>ext4, remainder<br/>mount /"]

One disk carved into the wiki's UEFI/GPT layout: ESP at /boot, an optional swap area, and root at /.

Format the partitions

With the partitions created, give each one a filesystem. Replace the example device names with your actual partitions (use fdisk -l again if you need to confirm them — your three partitions should now show up as numbered devices under the disk):

Device            Start        End   Sectors  Size Type
/dev/nvme0n1p1     2048    2099199   2097152    1G EFI System
/dev/nvme0n1p2  2099200   10487807   8388608    4G Linux swap
/dev/nvme0n1p3 10487808 1000215182 989727375  472G Linux root (x86-64)

Create an ext4 filesystem on the root partition:

mkfs.ext4 /dev/root_partition

If you made a swap partition, initialize it:

mkswap /dev/swap_partition

Format the EFI system partition as FAT32:

⛔ Danger — Only format the ESP if you created it during partitioning. If a pre-existing ESP was already there (from Windows, say), skip this command — reformatting it destroys the other operating system's boot loader.

mkfs.fat -F 32 /dev/efi_system_partition

These commands follow the wiki's Format the partitions section exactly.

Mount the filesystems

Finally, assemble the partitions into the directory tree that the installer will write into. The installer treats /mnt as the root of the system being built. Mount your root partition there first:

mount /dev/root_partition /mnt

Then mount the EFI system partition at /mnt/boot. The --mkdir option creates the mount point directory for you in the same step — this is the current wiki convention, with the ESP mounted at /boot:

mount --mkdir /dev/efi_system_partition /mnt/boot

If you created a swap partition, enable it:

swapon /dev/swap_partition

Order matters: mount root first, then the partitions that sit underneath it in the hierarchy. The resulting tree, rooted at /mnt, looks like this:

flowchart TD
    M["/mnt<br/><i>root partition, ext4</i>"] --> B["/mnt/boot<br/><i>EFI system partition, FAT32</i>"]
    SW["swap partition<br/><i>swapon, no mount point</i>"] -.-> M

The installer builds the new system under /mnt: root mounted first, the ESP nested at /mnt/boot; swap is enabled but has no mount point.

You do not need to manually record any of this in a configuration file yet — in part 2, genfstab detects the mounted filesystems and swap automatically and writes them out for you.

A short close

Your disk is now partitioned, formatted, and mounted at /mnt, the machine is online, the clock is right, and you confirmed you booted in UEFI mode. That is genuinely the fiddliest part of an Arch install behind you — the irreversible, get-it-right-the-first-time part. Everything from here is more forgiving. The next post picks up exactly where the official guide moves into its Installation section, beginning with pacstrap, the command that installs the actual base system onto the disk you just prepared, and then makes the machine bootable on its own. Continue to part 2: base system and boot. If you want to revisit why you are doing this by hand at all, the reasoning is in why Arch Linux.