Installing Arch Linux, part 3: desktop, drivers, and the AUR

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.

At the end of part 2 you rebooted and logged in to a black text console. That is a complete Arch system — it just has no network, no graphics drivers, no sound, and no desktop yet. This post fills in all four, in the order you need them: get online, install drivers, install a desktop, and finally wire up the AUR so you can install almost anything.

ℹ️ Where you are: the booted system. Everything in this part runs on your installed Arch system after reboot, logged in as your own user at the text console (the prompt looks like user@hostname ~ $) — not the live ISO, and not root in a chroot. Because you are a normal user now, commands that change the system are prefixed with sudo (which you enabled for your user in part 2); the per-user audio commands further down deliberately omit it.

As always, every command mirrors the current Arch Wiki; if the screen disagrees with this post, trust the wiki.

Get online with NetworkManager

The live ISO had networking handled for you; your installed system does not, which is why the first job is connectivity. In part 2 you installed the networkmanager package — one of several network managers, and the right default for a laptop or desktop. Now enable and start its service:

sudo systemctl enable --now NetworkManager

systemctl enable --now does two things at once: enable makes the service start automatically on every future boot, and --now also starts it right now. NetworkManager runs as a background service — a daemon — managing your network connections; if the word is unfamiliar, where the word "daemon" comes from explains both the term and the systemd model managing it.

With the service running, connect. For Wi-Fi the friendliest tool is the text UI:

nmtui

Arrow to "Activate a connection", pick your network, type the password. For a quick command-line alternative, nmcli does the same:

nmcli device wifi connect "YourSSID" password "yourpassword"

Wired Ethernet usually connects automatically once the service is up. Verify with ping archlinux.org. Once you have a connection, refresh the package database and apply any pending updates:

sudo pacman -Syu

GPU drivers: the three cases

Linux already includes basic open-source graphics support in the kernel, so you can boot and see a console without doing anything. But for a smooth desktop, hardware acceleration, and 3D you want the proper user-space drivers. Which packages you install depends entirely on whose GPU you have. If you have used another OS, finding the GPU is the same idea you already know — Windows: Device Manager; macOS: About This Mac; here on Linux you ask the PCI bus directly. Check with lspci -k | grep -A 2 -E "(VGA|3D)" if you are not sure. The authoritative page is Graphics processing unit; for the reasoning behind each choice, see Linux GPU drivers explained.

Once lspci tells you the vendor, this is the path to the right packages:

flowchart TD
    A["lspci<br/>which vendor?"] -->|"Intel"| B["mesa<br/>vulkan-intel"]
    A -->|"AMD"| C["mesa<br/>vulkan-radeon"]
    A -->|"NVIDIA"| D{"Turing<br/>or newer?"}
    D -->|"yes"| E["nvidia-open<br/>nvidia-utils"]
    D -->|"no"| F["legacy nvidia<br/>or nouveau"]

Vendor decides the branch; only NVIDIA has a second question, and it turns on the GPU generation.

💡 Tip The defaults are simple to memorise: Intel and AMD both want mesa (plus the matching vulkan-* package), and that open stack is the recommended choice for them — gaming included. NVIDIA Turing or newer wants nvidia-open. Only older NVIDIA cards need a different answer.

Intel graphics

Almost all Intel graphics (integrated in the CPU) are covered by Mesa's open-source drivers. Install:

sudo pacman -S mesa vulkan-intel

mesa provides the OpenGL driver; vulkan-intel is Mesa's Vulkan driver (ANV) for the modern API games use. That is genuinely all most Intel systems need — see Intel graphics.

AMD graphics

AMD's open-source stack is excellent and, like Intel, lives in Mesa. Install:

sudo pacman -S mesa vulkan-radeon

vulkan-radeon is Mesa's AMD Vulkan driver (RADV). There is a proprietary AMD driver too, but for the vast majority of users — gaming included — the open Mesa drivers are the recommended default. See AMDGPU.

NVIDIA graphics

NVIDIA is the one with real choices. There are two families of driver:

• nouveau — the fully open-source, in-kernel driver. It works out of the box with no extra packages and is fine for a desktop, but performance on newer cards lags well behind NVIDIA's own driver.
• NVIDIA's official driver — much faster, and as of 2025 Arch ships it built around NVIDIA's open kernel modules by default. The main package is now nvidia-open, with nvidia-open-dkms as the DKMS variant that rebuilds for any kernel.

The important compatibility detail: NVIDIA's open kernel modules are supported on Turing and newer GPUs — that is the GeForce 16/20 series (2018) and everything after. For those cards, install:

sudo pacman -S nvidia-open nvidia-utils

(nvidia-utils provides the user-space libraries including Vulkan support.) If you run the standard linux kernel, the non-DKMS nvidia-open is the simplest choice; if you run a different or custom kernel, use nvidia-open-dkms so the module rebuilds automatically.

⚠️ Warning — For pre-Turing cards (Maxwell, Pascal — GTX 9xx/10xx) the open kernel modules are not supported; use the legacy nvidia package or stay on nouveau. Do not assume nvidia-open is right for an older card — check the per-architecture table on the NVIDIA wiki page against your exact card before installing.

Whatever your GPU, if you want to run Vulkan games you also want the loader installed (mesa/nvidia-utils already pull most of it in):

sudo pacman -S vulkan-icd-loader

Audio with PipeWire

💡 Tip PipeWire is the modern default for audio on Arch. It replaced the older PulseAudio and JACK servers and handles the jobs of both, so you do not need to choose between them or install either one — reach for PipeWire and move on.

Modern Arch uses PipeWire for audio — it replaced the older PulseAudio and JACK servers and handles both. Install the stack:

sudo pacman -S pipewire pipewire-pulse wireplumber

• pipewire is the multimedia server itself.
• pipewire-pulse is the drop-in replacement for the PulseAudio server, so apps expecting PulseAudio just work.
• wireplumber is the session manager — the component that decides routing, applies policy, and remembers your volume per device. It is the recommended manager.

Wired together, the three packages form a small graph: your apps speak to the compatibility shim, the shim feeds the real server, and the session manager steers it from the side:

flowchart LR
    A["your apps<br/>browser, games"] --> B["pipewire-pulse<br/><i>PulseAudio shim</i>"]
    B --> C["pipewire<br/>the server"]
    D["wireplumber<br/><i>session manager</i>"] --> C
    C --> E["speakers,<br/>headphones"]

Apps think they are talking to PulseAudio; the shim hands off to PipeWire, with WirePlumber deciding the routing.

PipeWire runs as a per-user service, so unlike NetworkManager you do not enable it system-wide. The wiki's command, run as your normal user (no sudo):

systemctl --user enable --now pipewire pipewire-pulse wireplumber

ℹ️ Note Installing a full desktop like GNOME or KDE often pulls in and starts these audio services for you, so you may find sound already works. Enabling them explicitly does no harm and guarantees sound after the next login.

Install a desktop environment

Now the visible part. A desktop environment bundles a window manager, panels, a file manager, settings, and default apps into a coherent whole. If you are unsure which to pick, what a desktop environment is walks through the trade-offs. Here are the two most popular, both as complete worked examples. Pick one.

Before that, it helps to see how the pieces you have been installing stack up. Each layer sits on the one below it, from the kernel talking to your GPU all the way up to the session you actually use:

flowchart TD
    A["kernel + GPU driver<br/>mesa / nvidia"] --> B["display server<br/>Wayland or X11"]
    B --> C["desktop environment<br/>GNOME or KDE Plasma"]
    C --> D["display manager<br/>GDM or SDDM login"]
    D --> E["your session<br/><i>logged in</i>"]

The graphics stack bottom to top — the GPU driver from the last section is the foundation; the display manager is the login screen you wire up below.

What a display manager is

Before either desktop, one piece of vocabulary. A display manager is the graphical login screen — the thing that appears at boot, asks for your password, and then launches your desktop session. It is a service you enable, separate from the desktop itself. Without one you would log in at the text console and start the desktop by hand; with one you get the familiar graphical login. GNOME's is GDM; KDE's is SDDM. You only need one, matched to your desktop.

Option A: GNOME

GNOME is a clean, opinionated, modern desktop — the default on Fedora and Ubuntu. Install the package group and its display manager:

sudo pacman -S gnome gdm

gnome is a package group pulling in the shell, settings, core apps, and more (pacman will ask you to confirm the set; the defaults are fine). gdm is the GNOME Display Manager. Enable it so it starts at boot:

sudo systemctl enable --now gdm

That should drop you straight into the GNOME login screen. See the GNOME wiki page.

Option B: KDE Plasma

Plasma is highly configurable and Windows-familiar in layout. The current package group is plasma, and its display manager is SDDM:

sudo pacman -S plasma sddm

Optionally add kde-applications for the full KDE app suite, or just the pieces you want (dolphin for the file manager, konsole for the terminal). Enable SDDM:

sudo systemctl enable --now sddm

See the KDE wiki page. After enabling a display manager, reboot once (sudo reboot) to confirm the whole chain — bootloader, login screen, desktop — comes up cleanly on its own.

The AUR and an AUR helper

What the AUR is

The official Arch repositories are large but not infinite. The Arch User Repository (AUR) fills the gap: it is a community-driven collection of build recipes — files called PKGBUILD that describe how to fetch, compile, and package software not in the official repos. This is where you find proprietary apps, niche tools, bleeding-edge versions, and Git builds.

Two things to understand. First, the AUR does not ship binaries; it ships instructions your machine runs to build the package locally. Second, it is not curated or audited. Anyone can upload a PKGBUILD.

⚠️ Warning Read the PKGBUILD before you install anything from the AUR. The security model is "read it yourself before you build it" — for anything you do not recognise, open the PKGBUILD and check what it downloads and runs. This is the one place on Arch where blind trust can bite you.

Installing yay

You can build AUR packages by hand with makepkg, but a helper automates the fetch-build-install-update loop. The popular one is yay. Because yay itself lives in the AUR, you bootstrap it by hand once. You already have base-devel and git from part 2. The wiki's manual build is three separate steps — run them in order, as your normal user, never with sudo:

Build and install the package with makepkg -si — -s installs the build dependencies, -i installs the finished package. It asks for your password only at the final install step:

makepkg -si

Change into the directory it created:

cd yay

Clone the AUR repository for yay (this downloads the PKGBUILD and supporting files):

git clone https://aur.archlinux.org/yay.git

Those three steps — clone, enter, build — are exactly what yay automates for every AUR package afterwards:

flowchart LR
    A["git clone<br/>fetch PKGBUILD"] --> B["read the PKGBUILD<br/><i>not curated</i>"]
    B --> C["makepkg -si<br/>build locally"]
    C --> D["pacman<br/>install the package"]

The AUR ships a recipe, not a binary — you read it, build it locally, and the result lands in pacman's database like any other package.

After this, installing or searching AUR packages is one command:

yay -S some-aur-package

yay syntax mirrors pacman, and yay alone updates both official and AUR packages. It will show you each PKGBUILD and ask before building — read them. The full list of helpers and the security warning are on the AUR helpers page.

Keeping the system updated

Arch is a rolling release: there are no version numbers to upgrade between, just a continuous stream of updates. Keeping current is the single most important maintenance habit. The command is:

sudo pacman -Syu

-Syu syncs the package database (-y) and upgrades everything (-u) in one transaction. A few rules that keep a rolling system healthy:

• Read the Arch news before big updates. On the rare occasion an update needs manual intervention (a config migration, a key change), it is announced there first. Skipping this is the most common way people break their system. Tools like the AUR's informant can even block an update until you have read pending news.
• Never do partial upgrades. Do not run pacman -Sy somepackage to install one thing without the full -u. That syncs the database but upgrades only one package, leaving it linked against libraries the rest of your system has not caught up to — a recipe for breakage. Always -Syu together, or just -S (no -y) when your database is already current. The System maintenance page is explicit that partial upgrades are unsupported.
• Update regularly, not rarely. Small frequent updates are easier to reason about than one giant catch-up after months away.

A short close

That is a complete Arch system: online, accelerated, audible, graphical, and connected to the AUR. The path here — drivers chosen for your actual hardware, a desktop you picked rather than inherited, a package system you understand — is the whole reason to install Arch by hand instead of clicking through a wizard. You now know where every piece lives and how to fix it.

This closes the Arch install companion. If you skipped ahead, the foundations are in the Getting started with Linux series — from what Linux actually is through choosing a distribution — and the case for this whole path is in why Arch Linux. And if you came out the other side curious about the standards and protocols underneath it all, POSIX, the standard nobody reads and SSH, the protocol nothing displaced are good next stops. Welcome to Arch.