Arch Linux Install (UEFI + Wi‑Fi + Desktop) Without the Usual Suffering

The production mindset: how to not brick your own laptop

Arch installation is not a rite of passage. It’s a change request. Your goal is a bootable system with networking, a desktop, and a recovery path. That’s it. Fancy is optional.

Rules that prevent the classic disasters

• Identify the target disk three different ways before you write a partition table. Humans are bad at “/dev/nvme0n1 vs /dev/nvme1n1” at 1 a.m.
• Make UEFI status a fact, not a vibe. If /sys/firmware/efi isn’t there, you’re not in UEFI mode, no matter what the firmware setup screen claims.
• Network first, install second. A half-installed system without networking is an unforced error.
• Keep it reversible. Use a simple partition scheme, keep the ESP intact, and don’t do clever boot tricks on day one.
• Prefer defaults that other people can debug. systemd-boot + NetworkManager + a mainstream desktop is boring. That’s why it’s good.

One quote that belongs on every on-call runbook, attributed to a notable SRE voice, is a paraphrased idea from Ben Treynor Sloss (Google SRE): paraphrased idea: reliability is a feature, and you design for it intentionally—not by hoping your changes behave.

Joke #1: The fastest way to find the wrong disk is to partition the wrong disk. The second fastest is to run lsblk first.

Interesting facts and short history (because context prevents mistakes)

1. UEFI replaced the old BIOS world not just for bigger disks, but for a standardized boot manager and pre-boot environment. That “standardization” still varies wildly by vendor.
2. GPT is not just “the new partition table.” It stores redundant headers and CRCs, which is why you can sometimes recover from partial corruption.
3. The EFI System Partition (ESP) is a FAT filesystem by spec. It’s not there for Windows; it’s there for firmware. Treat it like shared infrastructure.
4. systemd-boot used to be gummiboot. The rename wasn’t cosmetic—it signaled that it’s part of the systemd ecosystem and stays intentionally minimal.
5. wpa_supplicant has been the Wi‑Fi backbone for years, but many users interact with it indirectly via iwd or NetworkManager. Debugging often means knowing which layer you’re actually using.
6. Arch’s pacman and rolling releases push you toward current kernels and drivers, which is great for new laptops and a little spicy for “don’t touch my workstation” teams.
7. Btrfs subvolumes became popular in desktop Linux partly because snapshots are real operational leverage when updates go sideways.
8. Microcode updates (Intel/AMD) are not “optional performance tweaks.” They ship CPU bug fixes that can matter for stability and security.

Preflight checks from the live ISO (UEFI, disks, Wi‑Fi)

Boot the Arch ISO. If possible, use the newest monthly image so your kernel and Wi‑Fi firmware aren’t from the Paleozoic. You’re going to validate three things before you touch storage: UEFI mode, time, and network device detection.

Task 1: Confirm you’re in UEFI mode

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  runtime  runtime-map  systab

What it means: If that directory exists and has entries, the ISO booted in UEFI mode.

Decision: If it’s missing, reboot and pick the UEFI boot option in firmware (often there are two entries for the same USB stick). Do not proceed with a UEFI plan in legacy mode.

Task 2: Find your disks and understand naming

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME         MODEL                 SIZE TYPE FSTYPE MOUNTPOINTS
nvme0n1      Samsung SSD 980 PRO  931.5G disk
nvme0n1p1                          512M part vfat
nvme0n1p2                          100G part
nvme0n1p3                        831.0G part
sda          USB SanDisk 3.2       28.7G disk iso9660

What it means: You can see the internal NVMe (likely your target) and the USB ISO device (not your target). Models matter; names lie.

Decision: Write down the target disk (e.g., /dev/nvme0n1). If multiple internal disks exist, decide now which one you’ll install to and which one you’ll leave untouched.

Task 3: Check the clock (because TLS hates time travel)

cr0x@server:~$ timedatectl
               Local time: Sat 2026-02-05 12:41:02 UTC
           Universal time: Sat 2026-02-05 12:41:02 UTC
                 RTC time: Sat 2026-02-05 12:41:01
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

What it means: You’re not synced yet. If the clock is wrong, package downloads and mirror TLS checks can fail in ways that look like network problems.

Decision: If Wi‑Fi is up, sync time. If Wi‑Fi isn’t up, get Wi‑Fi up first, then come back.

cr0x@server:~$ timedatectl set-ntp true

Wi‑Fi on the Arch ISO: make it work, then make it stay working

On modern Arch ISOs, your best path is usually iwd + iwctl (often already present) or NetworkManager (install later on the target system). The live environment’s job is simple: connect reliably long enough to install.

Task 4: Identify the Wi‑Fi device and driver

cr0x@server:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DORMANT group default qlen 1000

What it means: The Wi‑Fi interface exists (wlp0s20f3). If you don’t see a wireless interface, you’re in driver/firmware territory.

Decision: If no wireless interface appears, check dmesg for firmware errors and confirm your hardware.

cr0x@server:~$ dmesg -T | grep -iE 'firmware|iwlwifi|ath|brcm|rtw'
[Sat Feb  5 12:44:11 2026] iwlwifi 0000:00:14.3: loaded firmware version 78.8f3d2a8a.0

What it means: Firmware loaded. That’s a green light.

Decision: Proceed to connecting. If you see “failed to load firmware,” you may need a newer ISO or the right firmware package later; for the live ISO, a newer image is usually faster than heroics.

Task 5: Connect with iwctl (iwd)

cr0x@server:~$ iwctl
[iwd]# device list
                                    Devices
----------------------------------------------------------------
  Name              Address          Powered   Adapter   Mode
----------------------------------------------------------------
  wlp0s20f3         34:de:1a:xx:xx   on        phy0      station

[iwd]# station wlp0s20f3 scan
[iwd]# station wlp0s20f3 get-networks
                               Available networks
----------------------------------------------------------------
  Network name                    Security      Signal
----------------------------------------------------------------
  CorpGuest                       open          -63 dBm
  HomeNet                         psk           -48 dBm

[iwd]# station wlp0s20f3 connect HomeNet
Type the network passphrase for HomeNet psk.
Passphrase: ********

What it means: You can scan and connect. Signal strength matters; “-85 dBm” is where installs go to die mid-download.

Decision: If signal is weak, move closer, switch bands, or tether. Fix physics before you debug “random pacman failures.”

Task 6: Verify you got an IP and DNS works

cr0x@server:~$ ip addr show wlp0s20f3
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:de:1a:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.44/24 brd 192.168.1.255 scope global dynamic wlp0s20f3
       valid_lft 86371sec preferred_lft 86371sec

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Link 2 (wlp0s20f3)
Current Scopes: DNS
     Protocols: +DefaultRoute

What it means: You have DHCP and DNS configured via systemd-resolved in the live ISO environment.

Decision: If DNS is broken, don’t “fix” it with random /etc/resolv.conf hacks yet. First confirm the router’s DNS, then try a different network. You can survive a flaky install, but you’ll hate yourself.

Partitioning you can explain to Future You

UEFI + GPT. One ESP. One root. Optionally a swap. That’s the adult baseline. If you’re dual-booting, keep the existing ESP; don’t make two ESPs unless you enjoy firmware roulette.

A sane default layout (single-disk laptop)

• ESP: 512 MiB, type EFI System, FAT32, mounted at /boot (or /efi). Pick one and be consistent.
• Root: the rest (or most) as ext4 or Btrfs, mounted at /.
• Swap: optional. If you want hibernation, you need swap sized for RAM (and then some margin).

Task 7: Inspect existing partition table before editing

cr0x@server:~$ sgdisk -p /dev/nvme0n1
Disk /dev/nvme0n1: 1953525168 sectors, 931.5 GiB
Model: Samsung SSD 980 PRO
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 8A2D7C7D-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Partition table holds up to 128 entries
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB  EF00  EFI system partition
   2         1050624      210763775   100.0 GiB  8300  Linux root
   3       210763776     1953523711   831.0 GiB  8300  Linux home

What it means: You already have an ESP and separate root/home. Great if that’s what you want.

Decision: If you’re reinstalling, decide whether to reuse p1 as ESP and reformat p2/p3. If dual-booting, do not delete the ESP unless you enjoy recovery weekends.

Task 8: Create partitions with parted (example: new disk)

cr0x@server:~$ parted -s /dev/nvme0n1 mklabel gpt
cr0x@server:~$ parted -s /dev/nvme0n1 mkpart ESP fat32 1MiB 513MiB
cr0x@server:~$ parted -s /dev/nvme0n1 set 1 esp on
cr0x@server:~$ parted -s /dev/nvme0n1 mkpart root 513MiB 100%

What it means: GPT label created; first partition is ESP, second is root.

Decision: If you need separate /home or swap, add them now. Otherwise keep it simple: one filesystem is easy to back up and easy to reinstall.

Task 9: Format the ESP and root

cr0x@server:~$ mkfs.fat -F32 /dev/nvme0n1p1
mkfs.fat 4.2 (2021-01-31)
cr0x@server:~$ mkfs.ext4 -F /dev/nvme0n1p2
mke2fs 1.47.2 (2025-01-05)
Creating filesystem with 244170752 4k blocks and 61046784 inodes
Filesystem UUID: 8e2f3c2a-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

What it means: Filesystems are created; ext4 reports block counts and UUID, which will show up in fstab.

Decision: If you expected Btrfs and you just formatted ext4, stop now and fix it. Yes, I’ve watched people “convert later” and quietly never do.

Filesystem choices: ext4 vs Btrfs (and what I’d ship)

Ext4 is still the “I need my laptop to boot every day” filesystem. Btrfs is the “I want snapshots and I accept that I must understand subvolumes” filesystem. Both are fine. Pick based on your operational habits, not Reddit bravado.

My opinionated take

• Pick ext4 if this is your first Arch install, you value predictability, and your backup strategy is “I promise I’ll do it later.”
• Pick Btrfs if you’ll actually use snapshots (pre-upgrade, pre-kernel changes), and you’re willing to keep the layout consistent.

Task 10 (optional): Btrfs subvolume layout that doesn’t get weird

cr0x@server:~$ mkfs.btrfs -f /dev/nvme0n1p2
btrfs-progs v6.15
cr0x@server:~$ mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ btrfs subvolume create /mnt/@
Create subvolume '/mnt/@'
cr0x@server:~$ btrfs subvolume create /mnt/@home
Create subvolume '/mnt/@home'
cr0x@server:~$ umount /mnt
cr0x@server:~$ mount -o subvol=@,compress=zstd:3 /dev/nvme0n1p2 /mnt
cr0x@server:~$ mkdir -p /mnt/home
cr0x@server:~$ mount -o subvol=@home,compress=zstd:3 /dev/nvme0n1p2 /mnt/home

What it means: Separate subvolumes allow snapshotting root without snapshotting home every time.

Decision: If you do this, commit to it. “One subvolume today, eleven tomorrow” is how you build an un-debuggable workstation.

Base install: pacstrap, fstab, locale, time

Now we do the boring part that should be boring. Mount filesystems, install base packages, generate fstab, and configure time/locale. Keep your install set small. You can always add packages. Removing confusion is harder.

Mount targets

cr0x@server:~$ mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ mkdir -p /mnt/boot
cr0x@server:~$ mount /dev/nvme0n1p1 /mnt/boot

Task 11: Pick mirrors (quick sanity, not mirror-nerdery)

cr0x@server:~$ reflector --country "United States" --latest 10 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

What it means: Mirrorlist is refreshed to a reasonable default set.

Decision: If reflector fails due to DNS or TLS, stop and fix time/network. Don’t keep going with a half-broken package manager.

Task 12: Install base system + essentials

cr0x@server:~$ pacstrap -K /mnt base linux linux-firmware sof-firmware nano sudo man-db man-pages networkmanager iwd
:: Synchronizing package databases...
 core                 129.2 KiB   623 KiB/s 00:00 [######################] 100%
 extra               1640.8 KiB  4.21 MiB/s 00:00 [######################] 100%
:: Installing packages...
(1/155) installing filesystem ...
(155/155) installing linux ...

What it means: The base OS is installed. -K copies the keyring into the new system so pacman trust works immediately inside chroot.

Decision: If you have modern audio hardware, keep sof-firmware. For laptops, it prevents “no sound device” surprises later.

Generate fstab and chroot

cr0x@server:~$ genfstab -U /mnt >> /mnt/etc/fstab
cr0x@server:~$ arch-chroot /mnt

Task 13: Set time zone, hardware clock, and locale

cr0x@server:/# ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
cr0x@server:/# hwclock --systohc
cr0x@server:/# sed -i 's/^#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen
cr0x@server:/# locale-gen
Generating locales...
  en_US.UTF-8... done
Generation complete.
cr0x@server:/# printf "LANG=en_US.UTF-8\n" > /etc/locale.conf

What it means: You’re setting a predictable locale and correct clock behavior.

Decision: If you dual-boot Windows, consider keeping RTC in local time on Windows side instead of breaking Linux. Linux should stay sane (UTC RTC is sane).

Task 14: Hostname and basic networking services

cr0x@server:/# printf "archbox\n" > /etc/hostname
cr0x@server:/# systemctl enable NetworkManager
Created symlink '/etc/systemd/system/multi-user.target.wants/NetworkManager.service' → '/usr/lib/systemd/system/NetworkManager.service'.

What it means: NetworkManager will start on boot and manage Wi‑Fi on your desktop like a normal OS.

Decision: For laptops/desktops, NetworkManager is the right default. Save “systemd-networkd everywhere” for servers, or for people who enjoy writing YAML with feelings.

Users, sudo, and microcode

cr0x@server:/# passwd
New password:
Retype new password:
passwd: password updated successfully
cr0x@server:/# useradd -m -G wheel -s /bin/bash cr0x
cr0x@server:/# passwd cr0x
New password:
Retype new password:
passwd: password updated successfully
cr0x@server:/# EDITOR=nano visudo

What it means: You have a non-root user with wheel group. In visudo, you should uncomment %wheel ALL=(ALL:ALL) ALL.

Decision: Don’t daily-drive root. It’s not hardcore; it’s sloppy.

cr0x@server:/# pacman -S --noconfirm intel-ucode
resolving dependencies...
looking for conflicting packages...
Packages (1) intel-ucode-20260120.1-1
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                     [######################] 100%
(1/1) installing intel-ucode                       [######################] 100%

What it means: Microcode is installed. For AMD, use amd-ucode.

Decision: Install the correct microcode package now. It’s low effort and reduces mysterious instability.

Bootloader on UEFI: systemd-boot done cleanly

On UEFI laptops, systemd-boot is a great default: minimal, predictable, and it doesn’t try to outsmart the firmware. GRUB is fine too, but if you don’t need its features, don’t pay its complexity tax.

Task 15: Install systemd-boot to the ESP

cr0x@server:/# bootctl install
Created "/boot/EFI/systemd".
Created "/boot/EFI/BOOT".
Created "/boot/loader".
Created "/boot/loader/entries".
Random seed file /boot/loader/random-seed successfully written (32 bytes).
Created EFI boot entry "Linux Boot Manager".

What it means: The bootloader files are placed on the ESP and a NVRAM boot entry was created.

Decision: If bootctl complains it can’t find the ESP, your /boot mount is wrong. Fix mounts before proceeding.

Task 16: Create loader entry with correct root identifier

Get the root filesystem UUID:

cr0x@server:/# blkid /dev/nvme0n1p2
/dev/nvme0n1p2: UUID="8e2f3c2a-xxxx-xxxx-xxxx-xxxxxxxxxxxx" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="f0a1b2c3-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

What it means: You have the UUID for kernel parameters and fstab verification.

Decision: Prefer UUID in the kernel command line. Device names can change; UUIDs don’t (unless you reformat).

Create /boot/loader/entries/arch.conf:

cr0x@server:/# cat > /boot/loader/entries/arch.conf <<'EOF'
title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root=UUID=8e2f3c2a-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw
EOF

And set a default loader config:

cr0x@server:/# cat > /boot/loader/loader.conf <<'EOF'
default arch.conf
timeout 3
console-mode max
editor no
EOF

Decision: Keep timeout short. If you need to debug, you can always mash a key. If you leave it long, you’ll watch it every day.

Task 17: Build initramfs and verify kernel install

cr0x@server:/# mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  - Building image with: /usr/bin/mkinitcpio -g /boot/initramfs-linux.img
==> Image generation successful

What it means: Your initramfs exists on the ESP-mounted /boot, where systemd-boot will look for it.

Decision: If you mounted ESP at /boot, this is correct. If you mounted it at /efi, your kernel and initramfs likely live on root—different setup. Pick one approach and keep it consistent.

Desktop setup: NetworkManager, GPU drivers, KDE/GNOME

Booting is the first milestone. A usable desktop is the second. Here’s the trick: enable the right services, install the right drivers, and avoid the “I installed three display managers to be safe” maneuver.

Task 18: Enable NetworkManager and (optionally) iwd backend

You already enabled NetworkManager. If you want NetworkManager to use iwd instead of wpa_supplicant, set it explicitly.

cr0x@server:/# mkdir -p /etc/NetworkManager/conf.d
cr0x@server:/# cat > /etc/NetworkManager/conf.d/wifi_backend.conf <<'EOF'
[device]
wifi.backend=iwd
EOF

Decision: Don’t mix-and-match Wi‑Fi stacks randomly. Choose one, then debug within that system.

Task 19: Install graphics stack (choose one path)

Figure out your GPU(s):

cr0x@server:/# lspci -k | grep -A3 -E 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller
        Subsystem: Lenovo Device xxxx
        Kernel driver in use: i915
        Kernel modules: i915

What it means: Intel iGPU using i915. That’s usually “it just works” with Mesa.

Decision: If you have NVIDIA, install NVIDIA packages deliberately and accept that you’re opting into driver management. For AMD/Intel, the open stack is typically simpler.

Install basics for a desktop session:

cr0x@server:/# pacman -S --noconfirm xorg-server xorg-xinit mesa

Task 20: Pick a desktop and a display manager (one each)

KDE Plasma (with SDDM):

cr0x@server:/# pacman -S --noconfirm plasma kde-applications sddm
cr0x@server:/# systemctl enable sddm
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/sddm.service'.

Decision: Plasma is a good “works out of the box” choice, especially if you want GUI network controls and sane defaults.

Or GNOME (with GDM):

cr0x@server:/# pacman -S --noconfirm gnome gdm
cr0x@server:/# systemctl enable gdm
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/gdm.service'.

Decision: Pick KDE or GNOME on day one. Installing both is a great way to debug themes and session files instead of getting work done.

Task 21: Audio and Bluetooth (because laptops)

cr0x@server:/# pacman -S --noconfirm pipewire pipewire-audio pipewire-pulse wireplumber bluez bluez-utils
cr0x@server:/# systemctl enable bluetooth
Created symlink '/etc/systemd/system/dbus-org.bluez.service' → '/usr/lib/systemd/system/bluetooth.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/bluetooth.service' → '/usr/lib/systemd/system/bluetooth.service'.

Decision: PipeWire is the default reality now. Don’t resurrect old PulseAudio-era advice unless you’re debugging a very specific problem.

First reboot

cr0x@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Joke #2: If the first boot works, don’t celebrate yet—your laptop will wait until you’re late for a meeting to reveal the missing Wi‑Fi firmware.

Practical tasks (commands + output + decisions)

You already saw many tasks in-line. Here are additional high-signal checks that save time when something doesn’t behave. These are the commands I actually run when I want answers, not vibes.

Task 22: Confirm ESP is mounted where you think it is

cr0x@server:~$ findmnt /boot
TARGET SOURCE         FSTYPE OPTIONS
/boot  /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

What it means: ESP mounted at /boot, so kernels/initramfs live on FAT unless you chose another layout.

Decision: If /boot is ext4 and your ESP is elsewhere, don’t run bootctl blindly. Confirm your chosen design and stick to it.

Task 23: Verify boot entries in NVRAM

cr0x@server:~$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* Linux Boot Manager  HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0001* UEFI: USB SanDisk 3.2  PciRoot(0x0)/Pci(0x14,0x0)/USB(0x3,0x0)
Boot0000* Windows Boot Manager  HD(1,GPT,yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

What it means: Firmware knows about your bootloader. Order indicates which boots first.

Decision: If “Linux Boot Manager” disappears after reboot, your firmware may be “helpful.” In that case, keep a fallback path: ensure \EFI\BOOT\BOOTX64.EFI exists (systemd-boot installs it).

Task 24: Check Wi‑Fi on the installed system (NetworkManager)

cr0x@server:~$ systemctl status NetworkManager --no-pager
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: disabled)
     Active: active (running) since Sat 2026-02-05 13:21:12 UTC; 2min ago

What it means: NetworkManager is running.

Decision: If it’s not active, fix that before touching Wi‑Fi drivers. Service state is the first layer.

cr0x@server:~$ nmcli device status
DEVICE      TYPE      STATE         CONNECTION
wlp0s20f3   wifi      connected     HomeNet
lo          loopback  unmanaged     --

What it means: Wi‑Fi is connected via NetworkManager.

Decision: If state is “disconnected” but device exists, check rfkill, credentials, and regulatory domain. Don’t reinstall your OS because your Wi‑Fi password changed.

Task 25: Check for rfkill blocks (the “airplane mode” trap)

cr0x@server:~$ rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

What it means: No block. If hard blocked is yes, there’s a physical switch or firmware toggle.

Decision: If blocked, fix that first. No amount of driver reinstall will beat an RF kill switch.

Task 26: Confirm DNS is sane on the installed system

cr0x@server:~$ resolvectl query archlinux.org
archlinux.org: 95.217.xx.xx                     -- link: wlp0s20f3
              (archlinux.org)

-- Information acquired via protocol DNS in 34.1ms.
-- Data is authenticated: no

What it means: DNS resolution works and latency is reasonable.

Decision: If DNS fails but IP connectivity works, focus on resolved/NetworkManager integration—not on “the internet is down.”

Task 27: Diagnose boot logs when the graphical login doesn’t appear

cr0x@server:~$ journalctl -b -p err --no-pager
Feb 05 13:20:58 archbox sddm[612]: Authentication error: SDDM::Auth::ERROR_INTERNAL
Feb 05 13:21:01 archbox kernel: i915 0000:00:02.0: [drm] *ERROR* failed to load DMC firmware

What it means: Errors since boot. Some are fatal, some are noise.

Decision: If display manager errors, validate user/session packages. If GPU firmware errors, ensure linux-firmware is installed and up to date, and that you’re not pinning ancient kernels.

Task 28: Validate that your initramfs contains what you think it contains

cr0x@server:~$ lsinitcpio -a /boot/initramfs-linux.img | head
usr/lib/modules/6.12.8-arch1-1/kernel/drivers/
usr/lib/modules/6.12.8-arch1-1/kernel/drivers/base/
usr/lib/modules/6.12.8-arch1-1/kernel/drivers/block/

What it means: You can inspect initramfs contents. Useful when root device drivers or filesystems aren’t available early boot.

Decision: If you use encryption, RAID, or odd storage controllers, ensure correct hooks in /etc/mkinitcpio.conf and rebuild.

Fast diagnosis playbook: find the bottleneck quickly

When something fails, don’t thrash. Identify which layer is broken. Most “Arch is broken” reports are one of: not actually booted in UEFI, wrong partition mounted, missing firmware, or a service not enabled.

First: are you booting what you think you’re booting?

• Check UEFI mode: ls /sys/firmware/efi
• Check boot entry: efibootmgr -v
• Check kernel cmdline: cat /proc/cmdline

Goal: Confirm the firmware loaded your intended bootloader and kernel, with the intended root= parameter.

Second: is storage mounted correctly (and consistently)?

• List block devices: lsblk -f
• Check mounts: findmnt
• Check fstab: cat /etc/fstab

Goal: Ensure root and ESP align with your design. “Kernel on ext4 but bootloader expects it on ESP” is a classic self-inflicted wound.

Third: is networking failing at link, IP, or DNS?

• Link state: ip link, rfkill list
• IP/DHCP: ip addr, nmcli device status
• DNS: resolvectl status, resolvectl query example.com

Goal: Don’t debug DNS when you don’t have an IP, and don’t reinstall drivers when the interface is hard-blocked.

Fourth: is the desktop failing because of display manager, GPU, or session?

• Display manager status: systemctl status sddm or systemctl status gdm
• GPU detection: lspci -k
• Boot errors: journalctl -b -p err

Goal: Separate “no GUI” into a single failing service versus a driver/kernel issue.

Common mistakes: symptom → root cause → fix

1) Symptom: “bootctl install” works, but system won’t boot (firmware goes to BIOS or another OS)

Root cause: You installed in legacy mode, or the ESP wasn’t mounted where you thought, or the NVRAM entry didn’t stick.

Fix:

• Verify UEFI: ls /sys/firmware/efi.
• Verify ESP mount: findmnt /boot and check that /boot/EFI/systemd/systemd-bootx64.efi exists.
• Check entries: efibootmgr -v. If missing, reinstall with ESP mounted and rerun bootctl install.

2) Symptom: pacstrap fails with TLS or “could not resolve host”

Root cause: Wrong clock, broken DNS, captive portal, or weak Wi‑Fi dropping connections.

Fix:

• Sync time: timedatectl set-ntp true then re-check timedatectl.
• Check DNS: resolvectl query archlinux.org.
• For captive portals, use a phone tether or a known-good network. The ISO doesn’t negotiate hotel Wi‑Fi terms of service.

3) Symptom: Wi‑Fi device missing entirely

Root cause: Missing kernel driver or firmware; sometimes Secure Boot policies or vendor quirks.

Fix:

• Check dmesg for firmware failures: dmesg -T | grep -i firmware.
• Use a newer Arch ISO (often the best fix).
• If installed system is missing firmware, confirm linux-firmware is installed and updated.

4) Symptom: You boot, but it drops to an emergency shell complaining it can’t find root

Root cause: Wrong root= UUID in loader entry, wrong filesystem driver in initramfs, or you reformatted and forgot to update configs.

Fix:

• From ISO, run blkid and compare to /boot/loader/entries/arch.conf.
• Rebuild initramfs inside chroot: mkinitcpio -P.

5) Symptom: Desktop login loop (enter password, screen flashes, back to login)

Root cause: Session misconfiguration, missing home permissions, broken GPU stack, or mixing display managers/desktop sessions.

Fix:

• Check errors: journalctl -b -p err and journalctl -u sddm (or gdm).
• Ensure home ownership: ls -ld /home/cr0x should show user owns it.
• Don’t install multiple display managers at once. Pick one, enable one.

6) Symptom: No sound devices in desktop

Root cause: Missing sof-firmware (common on Intel laptops), PipeWire not installed, or WirePlumber not running.

Fix:

• Install: pacman -S sof-firmware pipewire wireplumber
• Check user services/logs: systemctl --user status wireplumber

Checklists / step-by-step plan

Checklist A: Minimal “I need a working desktop today” plan

1. Boot ISO in UEFI mode; confirm /sys/firmware/efi exists.
2. Connect Wi‑Fi with iwctl; confirm IP and DNS.
3. Identify target disk with lsblk -o NAME,MODEL,SIZE.
4. Create GPT: ESP (512 MiB FAT32) + root (rest).
5. Format ESP FAT32; format root ext4.
6. Mount root to /mnt, mount ESP to /mnt/boot.
7. pacstrap base + kernel + firmware + NetworkManager.
8. Generate fstab; chroot.
9. Set timezone, locale, hostname; set root password; create user; configure sudo.
10. Install microcode; install systemd-boot; create loader entry.
11. Enable NetworkManager; install desktop (KDE+SDDM or GNOME+GDM); enable display manager.
12. Reboot; verify Wi‑Fi via GUI; run updates.

Checklist B: Dual-boot safety plan (Windows already installed)

1. Back up Windows BitLocker keys (if used). If you don’t know what that means, stop and learn before touching partitions.
2. In Windows, shrink volume using Windows tools if needed. Do not shrink NTFS from Linux unless you enjoy living dangerously.
3. On ISO, do not reformat the existing ESP. Mount it and reuse it.
4. Create a new Linux root partition in free space.
5. Install systemd-boot; confirm efibootmgr shows both Windows and Linux entries.
6. Keep Windows Boot Manager entry intact. Your firmware might “prefer” it later; you want both to work.

Checklist C: “I want snapshots” plan (Btrfs)

1. Create Btrfs root, create subvolumes @ and @home.
2. Mount with compress=zstd and consistent subvol options.
3. Generate fstab, verify subvolume mounts in /etc/fstab before reboot.
4. Adopt a snapshot workflow before upgrades. If you won’t, don’t bother with Btrfs for the filesystem features alone.

Three corporate mini-stories from the land of “it worked on my machine”

Mini-story 1: The incident caused by a wrong assumption

A company decided to standardize developer laptops on Arch because new hardware support mattered. The rollout was going fine—until a batch of machines arrived with two internal NVMe drives. One smaller “system” drive and one larger “data” drive, depending on the model.

The internal wiki install notes said: “Install to /dev/nvme0n1.” It had been true for months. Then one vendor revision flipped enumeration order. A handful of installs wiped the wrong disk. Nothing malicious, just a wrong assumption that device names are stable identifiers.

The postmortem was boring and useful. They changed the procedure to require disk identification by model + size and to paste the output of lsblk -o NAME,MODEL,SIZE,SERIAL into the ticket before partitioning. They also added a “confirm you’re not on the USB” check by verifying the installer ISO device name and ensuring it isn’t the target.

After that, the issue vanished. Not because Linux became nicer, but because the process became less trusting of human memory.

Mini-story 2: The optimization that backfired

An IT team wanted faster installs. Someone suggested keeping a local cache of packages and aggressively pruning the ISO-time package list: “We don’t need linux-firmware; it’s huge. We can add it later.” On paper, this reduced download time.

In practice, it created a class of failures that were hard to diagnose. The machines booted, but Wi‑Fi and sometimes graphics were missing on certain models. Developers would fix it by installing firmware after the fact—if they had Ethernet. Without Ethernet, they were stuck with a system that couldn’t fetch the package that would make the network work. Very elegant.

The team reverted the optimization and documented a principle: firmware packages are baseline, not optional. You don’t optimize by removing the parts that make the hardware function. You optimize by improving mirrors, caching, or using better connectivity during provisioning.

They still achieved speedups later with a smarter mirror selection and local caching, without turning first boot into a scavenger hunt.

Mini-story 3: The boring but correct practice that saved the day

A different org ran Arch on a fleet of kiosks. Rolling releases made management nervous, so they did something deeply unsexy: before every update window, they captured a snapshot (Btrfs) and verified they could boot the previous snapshot from the boot menu.

One update introduced a regression with a specific GPU driver and their display hardware. The kiosks rebooted into a black screen. No remote desktop, no GUI, no easy access—just a tiny set of humans who could physically reach the devices.

Because they had rehearsed rollback, the response was straightforward. They booted to the previous snapshot entry, restored service, and then pinned the affected package version while coordinating a proper fix. No panic, no heroic debugging while customers stared at a dead kiosk.

That practice didn’t make headlines. It did make uptime. In operations, that’s the only applause that matters.

FAQ

1) Should I mount the ESP at /boot or /efi?

If you’re using systemd-boot, mounting ESP at /boot keeps the model simple: bootloader, kernel, and initramfs all live together. Mounting at /efi can also work, but then you must ensure the bootloader can find kernel/initramfs (often via separate steps). Pick one and stay consistent.

2) Do I need swap in 2026?

Not strictly, but it’s useful for memory pressure and required for hibernation. If you don’t hibernate and you have plenty of RAM, you can skip it. If you’re on a laptop and you hibernate, plan swap accordingly.

3) iwd or wpa_supplicant?

Use iwd as the backend if your setup works with it; it’s lean and integrates well. If you hit enterprise Wi‑Fi edge cases (certain EAP configurations), wpa_supplicant might be more compatible. The key is not to mix stacks without knowing which one is active.

4) Why does pacman complain about keys or signatures?

Usually because the keyring is stale or the clock is wrong. On the ISO, the fix is often “get network working, sync time, then retry.” On the installed system, ensure archlinux-keyring is up to date.

5) Can I install Arch without Ethernet?

Yes. The live ISO plus iwctl is usually enough. The common failure mode is missing firmware for very new Wi‑Fi chipsets; a newer ISO is the best first move.

6) systemd-boot vs GRUB: which should I choose?

systemd-boot if you want minimal moving parts and UEFI-only. GRUB if you need complex multi-boot features, legacy support, or unusual setups. For a modern single-OS laptop, systemd-boot is usually the calmer choice.

7) Do I need Secure Boot?

You need a threat model, not a checkbox. Secure Boot can be worth it, but it adds complexity: signing kernels or using signed boot artifacts. Get a clean non-Secure Boot install first, then add Secure Boot once you can boot and recover reliably.

8) Why did my UEFI boot entry disappear after reboot?

Some firmware “cleans up” entries it doesn’t like. systemd-boot’s fallback file in \EFI\BOOT\BOOTX64.EFI helps. Also ensure your ESP is healthy and that you’re not resetting firmware settings.

9) Should I use Btrfs snapshots on a laptop?

If you will actually use them before upgrades and you understand what you’re snapshotting (root vs home), yes. If you won’t adopt the habit, ext4 is simpler and will treat you better.

Next steps that actually pay off

You have a booting Arch system with Wi‑Fi and a desktop. Now do the operational hygiene that prevents future pain:

1. Confirm updates work: run pacman -Syu and verify no signature/time/network issues.
2. Record your partition layout: save lsblk -f output somewhere you can access if the system won’t boot.
3. Test recovery: keep the ISO USB around. Make sure you can mount root and ESP from the ISO and chroot in.
4. Decide on snapshots or backups: if Btrfs, define a snapshot routine; if ext4, define a backup routine. “Later” is not a plan.
5. Keep firmware and kernel current: especially on laptops. Hardware enablement is a moving target.

Arch isn’t inherently painful. Unverified assumptions are. Treat the install like a change you might have to debug at 2 a.m., and you’ll sleep more.