Arch Linux: Installation, pacman, and the AUR

Arch Linux holds a unique place in the distribution landscape: no graphical installer by default, no preset configuration, no versions. You build your system piece by piece, and in return you get a machine you understand completely, always up to date, backed by the best documentation in the Linux world. This guide is aimed at users who are already comfortable with the command line: we cover the full installation, mastering pacman, the AUR, and above all long-term maintenance, which is where the success of an Arch installation is decided.

1. Philosophy: Rolling Release and KISS

Arch is built on two principles that explain all of its technical choices.

Rolling release: there is no “version” of Arch. The system is updated continuously; a properly maintained installation from 2020 is identical to an installation today. You will never perform a major upgrade, but you must update regularly and read the announcements.

KISS (Keep It Simple, Stupid): simplicity, in Arch’s sense, means the absence of abstraction layers, not ease of use. Packages are delivered as close as possible to what upstream developers publish (vanilla), without distribution patches. Configuration is done in the software’s original files, not through in-house tools.

In practical terms: you are responsible for your system. Arch doesn’t protect you from yourself, but nothing in it is magic or hidden.

2. Installation Summary, Step by Step

The official installation is done on the command line from the ISO. The archinstall tool automates the process, but walking through the manual installation once is the best educational investment you can make. Here is the complete walkthrough for a UEFI machine.

Preparation and partitioning

# Verify boot in UEFI mode (the directory must exist and be populated)
ls /sys/firmware/efi/efivars

# Verify the network connection (Wi-Fi is configured with iwctl)
ping -c 3 archlinux.org

# Synchronize the clock
timedatectl set-ntp true

# Partition the disk: one EFI partition and one root partition
fdisk /dev/nvme0n1
# g            -> new GPT table
# n, 1, +1G    -> EFI partition (type: EFI System)
# n, 2, rest   -> root partition (type: Linux filesystem)
# w            -> write and quit

# Format
mkfs.fat -F32 /dev/nvme0n1p1
mkfs.ext4 /dev/nvme0n1p2

# Mount
mount /dev/nvme0n1p2 /mnt
mount --mkdir /dev/nvme0n1p1 /mnt/boot

pacstrap: installing the base system

# Install the foundation: base, kernel, firmware, and a few essentials
pacstrap -K /mnt base linux linux-firmware nano networkmanager sudo

fstab and chroot

# Generate the filesystem table from the current mounts
genfstab -U /mnt >> /mnt/etc/fstab

# Check the result before continuing
cat /mnt/etc/fstab

# Enter the new system
arch-chroot /mnt

Basic configuration inside the chroot

# Time zone and hardware clock
ln -sf /usr/share/zoneinfo/America/Montreal /etc/localtime
hwclock --systohc

# Locales: uncomment en_US.UTF-8 (or your preferred locale) in /etc/locale.gen
nano /etc/locale.gen
locale-gen
echo "LANG=fr_CA.UTF-8" > /etc/locale.conf

# Hostname
echo "archbox" > /etc/hostname

# Root password
passwd

# Create a user with sudo access
useradd -m -G wheel votre_nom
passwd votre_nom
EDITOR=nano visudo   # uncomment: %wheel ALL=(ALL:ALL) ALL

# Enable networking at boot
systemctl enable NetworkManager

Bootloader

# systemd-boot, simple and sufficient on UEFI
bootctl install

# Create the boot entry
cat > /boot/loader/entries/arch.conf << 'EOF'
title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=/dev/nvme0n1p2 rw
EOF

# Exit the chroot, unmount, and reboot
exit
umount -R /mnt
reboot

After rebooting, you get a text-mode login prompt: a minimal, working Arch system, ready to receive your graphical environment and your tools.

3. pacman: the Package Manager

pacman packs all of its operations into single-letter options. The syntax is puzzling at first, then becomes remarkably fast.

Core operations

# Install a package (S = sync, from the repositories)
sudo pacman -S firefox

# Update the ENTIRE system: the most important command on Arch
# S = sync, y = refresh indexes, u = upgrade
sudo pacman -Syu

# Remove a package
sudo pacman -R firefox

# Remove a package, its orphaned dependencies, and its configuration
sudo pacman -Rns firefox

# Search the repositories
pacman -Ss navigateur

# Show details of a repository package
pacman -Si firefox

Absolute rule: never run pacman -Sy package (refreshing the indexes and then installing without upgrading everything). This “partial upgrade” installs a package built against newer libraries than those on your system and can break it. It’s -Syu, always.

Querying the installed system (Q)

# List all installed packages
pacman -Q

# Explicitly installed packages (your shopping list)
pacman -Qe

# Details of an installed package
pacman -Qi firefox

# List a package's files
pacman -Ql firefox

# Find the package that owns a file
pacman -Qo /usr/bin/firefox

# List orphans (dependencies that are no longer needed)
pacman -Qdt

# Remove all orphans
sudo pacman -Rns $(pacman -Qdtq)

Managing the cache

pacman keeps every downloaded version in /var/cache/pacman/pkg/, which allows rollbacks but quickly consumes several gigabytes.

# Cache size
du -sh /var/cache/pacman/pkg

# Keep the last 3 versions of each package (paccache is in pacman-contrib)
sudo pacman -S pacman-contrib
sudo paccache -r

# Remove versions of uninstalled packages
sudo paccache -ruk0

# Automate weekly cleanup
sudo systemctl enable --now paccache.timer

4. The AUR: the Community Repository

The AUR (Arch User Repository) is Arch’s real strength: a community repository of more than 80,000 build recipes covering just about any software in existence. Note: the AUR does not contain binary packages, but PKGBUILDs, scripts that describe how to build the package. Nothing there is vetted by Arch developers: caution is your responsibility.

Manual installation from the AUR

Understand the manual process before using a helper:

# Prerequisites for building
sudo pacman -S --needed base-devel git

# Clone the recipe
git clone https://aur.archlinux.org/visual-studio-code-bin.git
cd visual-studio-code-bin

# ALWAYS read the PKGBUILD before building
less PKGBUILD

# Build and install (s = install dependencies, i = install the package)
makepkg -si

yay and paru: AUR helpers

AUR helpers automate cloning, building, and above all updating AUR packages. The two current go-to options are yay (written in Go) and paru (written in Rust, by yay’s original maintainer).

# Install yay... from the AUR, by hand (just once)
git clone https://aur.archlinux.org/yay.git
cd yay && makepkg -si

# After that, yay unifies the official repositories and the AUR
yay -S spotify              # install (repositories or AUR)
yay -Syu                    # update everything, AUR included
yay -Ss teams               # search everywhere
yay -Qua                    # list pending AUR updates

paru is used with exactly the same options. One notable difference: paru displays the PKGBUILD by default before building, a safer setting that you can also enable in yay.

Anatomy of a PKGBUILD

# Minimal PKGBUILD example
pkgname=mon-outil
pkgver=1.2.0
pkgrel=1
pkgdesc="Un outil d'exemple"
arch=('x86_64')
url="https://exemple.com"
license=('MIT')
depends=('glibc')
makedepends=('go')
source=("$url/releases/$pkgname-$pkgver.tar.gz")
sha256sums=('...')

build() {
    cd "$pkgname-$pkgver"
    go build -o "$pkgname"
}

package() {
    cd "$pkgname-$pkgver"
    install -Dm755 "$pkgname" "$pkgdir/usr/bin/$pkgname"
}

What to check when reading a PKGBUILD: does the source point to the project’s official site? Do the build() and package() functions do anything other than compile and copy files? A malicious PKGBUILD can run anything with your privileges.

5. Maintaining a Rolling Release

This is where the longevity of your installation is decided. A well-maintained Arch system runs for years; an Arch system neglected for six months gets updated painfully.

The update routine

# 1. Check the announcements before a big update
# https://archlinux.org/news/ (possible manual interventions)

# 2. Update
sudo pacman -Syu

# 3. Handle .pacnew files (see below)

# 4. Reboot after a kernel or systemd update

Recommended frequency: at least once a week. After several months without updating, first update the keyring (sudo pacman -Sy archlinux-keyring then -Su) to avoid signature errors.

.pacnew files

When a package ships a new version of a configuration file that you have modified, pacman does not overwrite your version: it drops the new one alongside with the .pacnew extension. Ignoring them indefinitely eventually causes malfunctions.

# Locate pending .pacnew and .pacsave files
sudo pacman -S pacman-contrib
pacdiff --output

# Merge interactively (uses vim -d by default)
sudo pacdiff

# With a different merge tool
DIFFPROG=meld sudo -E pacdiff

Rolling back (downgrade)

If an update breaks something, pacman’s cache lets you reinstall the previous version:

# Reinstall a version from the local cache
sudo pacman -U /var/cache/pacman/pkg/firefox-128.0-1-x86_64.pkg.tar.zst

# Temporarily freeze the package while the bug is fixed upstream
# (add to /etc/pacman.conf, [options] section)
# IgnorePkg = firefox

For versions missing from the cache, the Arch Linux Archive keeps every package ever published, and the downgrade tool (AUR) automates the search. Keep the freeze temporary: a rolling release with permanently pinned packages ends up in a partial-upgrade state, which is the one state to avoid at all costs.

6. Rolling Release Pitfalls

• The partial upgrade: never pacman -Sy package, never a permanent IgnorePkg. The whole system moves forward together.
• Updating right before a trip or an important deadline: if something breaks, you won’t have time to fix it. Update when you have an hour to spare.
• Updating the kernel without rebooting: the old kernel’s modules are removed from disk, so plugging in a USB drive may fail until you reboot.
• AUR packages that break after a library update: rebuild them (yay -S package --rebuild) after major version bumps (Python, ICU, OpenSSL).
• No backups: Btrfs snapshots with snapper, or Timeshift, turn a failed update into a five-minute incident.

7. The Arch Wiki: Your Permanent Reference

The Arch Wiki (wiki.archlinux.org) is widely regarded as the best Linux documentation in existence, to the point that Debian, Fedora, and Gentoo users consult it daily. Every page follows the same structure: installation, configuration, use cases, troubleshooting.

# Browse the wiki offline, from the terminal
sudo pacman -S arch-wiki-lite
wiki-search "systemd-boot"

A habit to build: before asking a question on a forum, look up the wiki page for the software in question. Nine times out of ten, the answer is there, with Arch-specific details documented.

Best Practices

• Do the manual installation at least once before using archinstall: it’s the best crash course on how a Linux system works.
• Run a full pacman -Syu at least weekly, and never a partial -Sy.
• Check the archlinux.org announcements before major updates.
• Handle .pacnew files with pacdiff after every update.
• Read every PKGBUILD before installing it from the AUR, even through yay or paru.
• Clean the cache with paccache -r, but keep a few versions so you can downgrade.
• Set up snapshots (snapper + Btrfs, or Timeshift) before you need them.
• Keep the installation ISO on a USB drive: arch-chroot from the live environment is the universal rescue tool.

Conclusion

Arch Linux demands more up front and gives back more afterward: a minimal system you assembled yourself, always up-to-date packages, no major upgrade to dread, and reference-grade documentation. The trade-off is a permanent responsibility: regular updates, reading the announcements, handling .pacnew files. If that discipline suits you, you will probably never go back; and even if you stay on a mainstream distribution, an Arch installation carried through to the end will have taught you more about Linux than months of ordinary use. The natural next step: exploring Btrfs snapshots, pacman hooks to automate your maintenance, and why not writing your own PKGBUILDs.