Installing Arch Linux, part 2: base system and first boot

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.

In part 1 you booted the live ISO, partitioned the disk, made filesystems, and mounted everything under /mnt — with your EFI System Partition mounted at /mnt/boot. If lsblk still shows your layout mounted there, you are exactly where this post picks up. Nothing below this line touches partitions; we now install software into that mounted tree and turn it into a system that boots on its own.

This is the longest part of the install, but none of it is hard. It is mostly typing commands carefully and understanding what each one does. I will explain the unfamiliar concepts — chroot, fstab, initramfs, bootloaders — as we hit them, because Arch is one of the few installs where you actually see these pieces rather than having an installer hide them. That visibility is the point: when something breaks later, you will know where to look.

A quick word on accuracy. Every command here mirrors the current Arch Linux Installation guide and its linked pages. Arch is a rolling release and details drift, so if something does not match what you see on screen, the wiki is the authority — not this post.

Here is the whole path this post walks, end to end — install software into the mounted tree, describe it, step inside, configure, then make it bootable and leave:

flowchart TD
    A["pacstrap base linux<br/>linux-firmware"] --> B["genfstab -U /mnt<br/>describe the tree"]
    B --> C["arch-chroot /mnt<br/>step inside"]
    C --> D["timezone, locale,<br/>hostname"]
    D --> E["root passwd, useradd,<br/>sudo via wheel"]
    E --> F["initramfs<br/><i>already built</i>"]
    F --> G["install bootloader<br/>systemd-boot or GRUB"]
    G --> H["exit, umount -R /mnt,<br/>reboot"]

The straight line from empty disk to a system that boots on its own — each box below is one section.

Optional: pick fast mirrors first

pill:Optional

Still in the live ISO. pacstrap (next step) downloads packages over the network, so it helps to download from mirrors that are close and fast. The live ISO ships reflector, which can sort the mirror list for you. This is optional — the default list works — but it can speed things up noticeably:

reflector --country Estonia,Finland,Germany --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

Swap in countries near you. --age 12 keeps only mirrors synced in the last 12 hours, --sort rate orders by download speed, and --save writes the result to the list pacman reads. If you skip this, pacstrap simply uses whatever order the ISO came with.

Install the base system

Still in the live ISO. This is the command that turns an empty directory tree into Arch. From the Installation guide:

pacstrap -K /mnt base linux linux-firmware

pacstrap installs packages into the system mounted at /mnt instead of into the live environment. The three packages are the minimum: base is the core package group, linux is the kernel, and linux-firmware is the blob of device firmware most hardware needs (Wi-Fi, GPUs, and so on). The -K flag tells pacstrap to initialise a fresh pacman keyring inside the new system — that is what the K stands for, and it is the recommended default.

In practice you want more than the bare minimum, because once you reboot there is no installer to fall back on. The wiki explicitly suggests adding, at least, a kernel headers package if you will build modules, a text editor, a way to get online, and documentation tools. A sensible expanded command:

pacstrap -K /mnt base linux linux-firmware base-devel networkmanager nano vim man-db man-pages sudo

What each addition buys you:

base-devel — the compilers and build tools (make, gcc, fakeroot, etc.). You will need this in part 3 to build from the AUR, and it is painful to add later from a half-configured system.
networkmanager — so you can get online after reboot. The live ISO has its own networking; your installed system does not until you provide some. We enable it in part 3.
nano and vim — text editors. The base system has no editor at all, and you need one in a moment to edit config files. Pick whichever you prefer; I list both so you are not stuck.
man-db, man-pages — the manual pages. Worth having from minute one.
sudo — needed to grant your user admin rights, which we do below.

If you have an Intel or AMD CPU, also add the microcode package — intel-ucode or amd-ucode — now. It ships CPU bug fixes the bootloader loads early, and we will reference it in the boot entry later.

This step downloads a few hundred megabytes and takes a few minutes.

Generate the fstab

Still in the live ISO — this reads the mounts the live environment set up under /mnt and writes them into the new system's fstab.

genfstab -U /mnt >> /mnt/etc/fstab

genfstab inspects what is currently mounted under /mnt and prints matching /etc/fstab lines. The -U flag makes it identify each filesystem by UUID rather than by device name like /dev/sda2. The >> appends that output to the new system's fstab.

⛔ Danger Use >> (append), not > (overwrite). A stray single arrow here clobbers the file: > truncates /mnt/etc/fstab to nothing and writes only the new lines, while a slip the other way can destroy whatever the redirect target points at. Type the two arrows deliberately.

After running it, read the file back before moving on, because a wrong fstab is the most common reason a fresh Arch install fails to boot cleanly:

cat /mnt/etc/fstab

You should see one entry per filesystem you mounted, each keyed by UUID=.

What fstab is

fstab is the "filesystem table": a plain-text file at /etc/fstab that tells the system, at every boot, which filesystems to mount, where to mount them, and with what options. Each line is one filesystem — the device (here a UUID), the mount point (/, /boot, etc.), the filesystem type, mount options, and two numbers for dump and fsck ordering.

Reading a single line left to right, this is what the six fields mean:

flowchart LR
    A["UUID=...<br/><i>which filesystem</i>"] --> B["/<br/><i>mount point</i>"]
    B --> C["ext4<br/><i>fstype</i>"]
    C --> D["rw,relatime<br/><i>options</i>"]
    D --> E["0<br/><i>dump</i>"]
    E --> F["1<br/><i>fsck order</i>"]

One fstab line, field by field — the UUID is the stable handle that replaces a wobbly /dev/sda2.

Why UUIDs instead of /dev/sda2? Because device names are not stable. Plug in a USB drive at boot and yesterday's /dev/sdb might become today's /dev/sdc, and a fstab pointing at the wrong device mounts the wrong thing — or nothing. A UUID is baked into the filesystem itself and does not move. See the fstab wiki page for the full format.

Enter the new system with chroot

Everything so far ran in the live environment — a temporary Arch running from RAM. To configure the system you just installed, you need to step inside it:

arch-chroot /mnt

ℹ️ You're now inside the chroot. Every path below (/etc/...) is the new system's, not the live ISO's. Commands here act on the install you're building.

Your shell prompt changes, and from now until you type exit, commands act on the installed system, not the live one.

What chroot is

chroot — "change root" — runs a command (here, a shell) with a different directory treated as /. After arch-chroot /mnt, the /mnt/usr/bin/bash binary believes it lives at /, so /etc/locale.conf means /mnt/etc/locale.conf, passwd edits the new system's password file, and so on. It is how you configure a system from the outside as if you had already booted into it. The arch-chroot wrapper additionally mounts the kernel's special filesystems (/proc, /sys, /dev) into the target first, which a plain chroot does not — that is why the wiki has you use it rather than the bare command.

Configure: timezone, clock, locale, hostname

Now we set the basics. These steps are from Configuration in the install guide.

Timezone. Symlink your zone into place, then write the hardware clock:

ln -sf /usr/share/zoneinfo/Region/City /etc/localtime
hwclock --systohc

Replace Region/City with yours — for example Europe/Tallinn. Tab-completion under /usr/share/zoneinfo/ helps you find the exact name. ln -sf creates (-s) and force-replaces (-f) the /etc/localtime symlink. hwclock --systohc sets the hardware (RTC) clock from the system clock and generates /etc/adjtime; the wiki assumes the hardware clock runs in UTC, which is the sane default.

Localisation. This controls the language, character encoding, and number/date formats. First edit /etc/locale.gen and uncomment the locale(s) you want — for most people that is en_US.UTF-8 UTF-8 (remove the leading #):

nano /etc/locale.gen

The line to uncomment in /etc/locale.gen:

en_US.UTF-8 UTF-8

Then generate them:

locale-gen

Then set the system language by creating /etc/locale.conf:

nano /etc/locale.conf

with the single line — /etc/locale.conf:

LANG=en_US.UTF-8

If you changed the console keyboard layout in part 1 (with loadkeys), make it permanent in /etc/vconsole.conf. This file only affects the text console, not your future graphical desktop:

nano /etc/vconsole.conf

/etc/vconsole.conf:

KEYMAP=us

Use the keymap you actually want — de, fi, et, etc. See Locale and Linux console/Keyboard configuration for the full details.

Hostname. This is the machine's name on the network. Create /etc/hostname:

nano /etc/hostname

with one line — whatever you want to call the machine, e.g. archbox. /etc/hostname:

archbox

See Network configuration.

What initramfs is

Before the bootloader, one concept. The initramfs ("initial RAM filesystem") is a tiny temporary root filesystem the kernel unpacks into memory and runs before it mounts your real root filesystem. Its job is to load the drivers needed to find and mount that real root — disk controllers, RAID, LUKS encryption, LVM — and then hand off. Without it, the kernel often cannot reach the disk holding the system it is supposed to boot.

ℹ️ Note pacstrap already generated a working initramfs when it installed the kernel, so for a standard install you usually do nothing here.

You only regenerate it if you change the generator config in /etc/mkinitcpio.conf — for example to add hooks for full-disk encryption or to bake in extra modules. When you do, the command that rebuilds the image for every installed kernel is:

mkinitcpio -P

(-P means "all presets".) Remember this command exists; for a plain unencrypted install you can move on.

Set passwords and create your user

Set the root password first:

passwd

Now create a regular user for daily use — logging in as root is bad practice. The -m makes a home directory and -G wheel adds the user to the wheel group, which we will grant admin rights in a moment:

useradd -m -G wheel yourname
passwd yourname

See Users and groups for the full set of useradd options.

sudo and the wheel group

sudo lets a normal user run individual commands as root after typing their own password — far safer than logging in as root or sharing the root password. By convention the wheel group is the set of users allowed to do this. Your user is already in wheel; you just need to tell sudo to honour that group.

Edit the sudoers file — but never with a plain editor. Use visudo, which validates the file before saving so a typo cannot lock you out of admin entirely:

EDITOR=nano visudo

EDITOR=nano tells visudo which editor to open (it defaults to vi). Note this file is edited through visudo, never saved directly — visudo validates it before writing so a typo cannot lock you out. Find the line to uncomment in /etc/sudoers (remove the leading # ):

# %wheel ALL=(ALL:ALL) ALL

so it reads:

%wheel ALL=(ALL:ALL) ALL

Save and exit. That single line is what makes sudo work for everyone in wheel. The current wiki documents exactly this line on the sudo page.

Install a bootloader

What a bootloader is

When your computer powers on, the firmware (UEFI on any modern machine) hands control to a small program whose job is to load the Linux kernel and its initramfs into memory and start them. That program is the bootloader. Without one, the firmware has a kernel sitting on disk but no instructions for launching it, and the machine does nothing useful. (For the full comparison of the choices below, see systemd-boot vs GRUB.)

The bootloader is one link in a short hand-off chain. Each stage loads the next and gets out of the way:

flowchart LR
    A["firmware<br/>UEFI"] --> B["bootloader<br/>systemd-boot or GRUB"]
    B --> C["kernel<br/>+ initramfs"]
    C --> D["real root<br/>filesystem"]
    D --> E["systemd<br/><i>PID 1</i>"]

Power-on to login prompt — the bootloader you install below is the second box, the one piece the firmware cannot supply itself.

The install guide lists several options. I will cover the two most common honestly, then give a recommendation.

💡 Tip For a single Arch install on one modern UEFI machine, reach for systemd-boot. It ships with systemd (nothing to install), its config is two short text files you can read at a glance, and fewer moving parts means fewer ways to break a boot you cannot yet repair. Save GRUB for when you actually need it — dual-booting Windows, or an old BIOS-only machine.

Option A: systemd-boot (recommended for a simple UEFI single-boot). systemd-boot is a minimal UEFI boot manager that ships with systemd — so it is already installed, nothing to add. It only works on UEFI systems, and it wants your EFI partition mounted at /boot (which is the layout part 1 used). Install it:

bootctl install

That copies the boot manager onto the EFI partition and registers it with the firmware. Confirm it landed with bootctl status, which prints the installed version and the firmware boot entries it registered. Now create two small text files. First the loader config — /boot/loader/loader.conf:

default  arch.conf
timeout  3
console-mode max
editor   no

editor no disables the boot-time kernel-parameter editor, which is a small security hardening. Then a boot entry — /boot/loader/entries/arch.conf:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=PARTUUID=XXXX rw

If you installed CPU microcode, add its initrd line before the main one:

initrd  /intel-ucode.img

(or /amd-ucode.img). The order matters — microcode first.

The one fiddly part is the root= value: it must point at your root partition. Get its PARTUUID with:

blkid -s PARTUUID -o value /dev/sdXn

replacing /dev/sdXn with your actual root partition (e.g. /dev/nvme0n1p2), and paste the result after root=PARTUUID=. Using PARTUUID, like with fstab, keeps the entry stable regardless of device-name shuffling. You can verify the install afterwards with bootctl status, and on future systemd updates bootctl update refreshes the installed loader.

Option B: GRUB (more features, multi-boot, BIOS support). GRUB is the heavyweight: it boots BIOS and UEFI systems, handles dual-boot with Windows gracefully, and auto-detects other operating systems. The trade-off is more moving parts. Install it plus the EFI tool:

pacman -S grub efibootmgr

Install GRUB to the EFI partition (still mounted at /boot here):

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB

--efi-directory points at the mounted EFI partition; --bootloader-id is the name registered with the firmware. Then generate the config — GRUB builds this automatically by scanning your kernels:

grub-mkconfig -o /boot/grub/grub.cfg

You do not hand-write boot entries with GRUB; you re-run that last command whenever kernels change (a pacman hook usually handles it for you).

Which to pick, and why? The decision is about what your machine is, not preference. Pick systemd-boot for a single Arch install on a modern UEFI laptop: the why is that it ships with systemd (already installed — nothing to add), its config is two short text files you can read at a glance, and fewer moving parts means fewer ways to break a boot you cannot yet repair. The how is the bootctl install plus two files shown in Option A. Pick GRUB when systemd-boot cannot do the job: you are dual-booting Windows (GRUB auto-detects and chainloads it), you are on an old BIOS-only machine (systemd-boot is UEFI-only), or you want its menu and scripting features. The how there is grub-install plus grub-mkconfig from Option B. Both are first-class on Arch; choose the smaller one unless a concrete need pushes you to the bigger one.

Reboot into your system

You are done inside the chroot. Leave it, unmount everything cleanly, and reboot:

exit
umount -R /mnt
reboot

exit drops you back into the live environment. umount -R /mnt recursively unmounts /mnt and everything below it, flushing any pending writes to disk — important, do not skip it. Then reboot. Remove the USB stick when the screen goes black so you boot from the disk, not the ISO again.

If all went well you will see your bootloader menu, then a text login prompt. Log in as the user you created. There is no desktop yet — that is deliberate, and it is exactly where part 3 begins: networking, GPU drivers, audio, a desktop environment, and the AUR.

A short close

The base system is the part that feels like surgery and is actually just careful bookkeeping: install packages into a mounted tree, describe that tree in fstab, step inside with chroot, set the locale and clock, make a user, and point the firmware at a kernel. Every concept here — fstab, chroot, initramfs, the bootloader — is something other distros' installers do silently. Having done it by hand once, you will read those words on any Linux system and know exactly what they mean. If you want to go deeper on the systemd machinery your new install runs on, where the word "daemon" comes from is a good companion read. Otherwise, on to part 3 and a usable desktop.