Mike’s Web Site & Blog

No Subtitle Exists

Install Arch Linux

This is how I install Arch Linux. Since it is unlikely that Google or DuckDuckGo got you here, this is also probably how I want you to install Arch Linux. Regardless of how you got here, if you do it this way, you’ll most likely be happy.

Part 1: Acquire Resources

Before you can install Arch Linux, you’ll need to download the official Arch Linux installer (which can be found on their Web site). In fact, nearly any live CD/DVD will work, but using the official one makes it a lot easier.

The official installer can be written to a DVD, or it can be placed on a USB flash media. Either way, it is a read-only environment (all writing happens on a RAM disk) which can be used to install or rescue installations of Arch or other distributions, such as Fedora.

Part 2: Configure the System Firmware

It is extremely important that this not be skipped (unless the target system has no firmware, but then that is an extremely unusual case which leaves you on your own…).

At the very least, you must verify that the system configuration is correct. Since (at the time of this writing) it is 2018, this most likely means that you want UEFI enabled and the CSM disabled. The options for this differ based on the firmware which is actually installed in the system, so detailed instructions are not provided here.

If you are installing into a virtual machine, you should enable UEFI and, in systems like QEMU, use a modern mainboard simulation. UEFI support exists for QEMU, VirtualBox, and other whole-system VMs.

Part 3: Boot the Installer Media

This is a live CD which is used to carry out the installation. Once it is booted, you’ll be presented with a command-line prompt from which you can perform the actual installation.

If you’re installing onto a UEFI system, ensure that the live environment was booted into UEFI mode. To do this, look at whether the file /sys/firmware/efi exists; if so, the current Linux kernel was booted on a UEFI system, using the UEFI firmware and not the CSM (e.g., legacy BIOS).

Part 4: Prepare for Installation

If the environment you are in did not automatically give you a root shell, you must first become root using whatever environment-specific instructions are provided.

You’ll want to do something like this:

wipefs -a /dev/DISK?* /dev/DISK

This will erase all “magic IDs” for filesystems on the disk (which must be replaced with a name like sda), and then clear the partition table areas of the disk. This leaves the disk “virtually” empty: there are no partitions, and there are no filesystems. Forensically, it is still quite intact. It is simply empty by convention at this point, and enough that it will not confuse even most naïve systems.

See wipefs(8) for additional information.

cfdisk /dev/DISK

If you ran the wipefs(8) command first, this command will ask you what type of partition table to create. Select gpt, which is the type used by UEFI systems. cfdisk(8) is an easier-to-use version of the fdisk(8) program.

Create the following partitions:

  • An EFI System Partition (ESP), 512 MiB.
  • A swap partition, 4 GiB is typically fine for most users.
  • A data partition, which uses the rest of the available space.

Format the partitions:

mkfs.vfat -F 32 /dev/DISK1
mkswap /dev/DISK2
mkfs.btrfs /dev/DISK3

Setup the subvolumes on the data partition:

mount /dev/DISK3 /mnt
btrfs subvolume create /mnt/root
btrfs subvolume create /mnt/home
umount /mnt

And now, mount the filesystems in the right places for install-time:

mount /dev/DISK3 -o subvol=root /mnt
mkdir /mnt/boot && mount /dev/DISK1 /mnt/boot
mkdir /mnt/home && mount /dev/DISK3 -o subvol=home /mnt/home
swapon /dev/DISK2
genfstab /mnt >> /mnt/etc/fstab

The system is now prepared for the installation process.

See mount(8), umount(8), swapon(8), btrfs-subvolume(8), mkfs.fat(8), and mkfs.btrfs(8) for additional information.

Part 5: Install the System

This is actually pretty easy:

pacstrap /mnt base

This takes care of installing the base system, which is more-or-less the barebones essentials. The result is an extremely small system that (for the purposes of most people) is basically useless. It is just a bare POSIX-like system at that point. It’s not even bootable yet.

In order to continue installing the system, we want to do something known as a change root operation, which is also easy enough to do:

arch-chroot /mnt

This takes care of the mundane tasks of mounting the /proc, /sys, etc. filesystems and making the install target our “new” root directory. This is a useful thing to do since most programs which modify global system state make the assumption that they are being executed on that root filesystem.

At this point, the shell prompt has changed, and we are inside the barebones environment. Now, we need to install “whatever we want”. As an example, for a KDE desktop environment, you might want to:

pacman -S plasma-meta kde-applications-meta sddm
systemctl enable sddm

… which installs a basic KDE/Plasma environment, as well as the display manager, and then enables the display manager. This causes the display manager to be started when the system is booted.

The systemctl(1) command is part of systemd(1), which is also important to learn about, but not perhaps right this moment.

You can do the same for GNOME:

pacman -S gnome
systemctl enable gdm

Which is more-or-less equivalent.

Part 6: Configure the Installed System

At this point, you need to do some basic setup before the system is ready for use. This includes:

  • Configuring the “locale”, which tells the system what language you speak and which character set to use. See locale(1), locale(5), and locale(7) for more information.
  • Configuring the time zone, so that the system can provide a meaningful notion of time to you, its user.
  • Installing and configuring the boot loader; systemd-boot (which provides the bootctl(1) command) is the most simple one, and is recommended for use on new installations on UEFI systems.
  • Installing and configuring any background services/software that you want to have running on the system.
  • Installing and configuring any application software that you want to have available to run on your system (for example, Mozilla Firefox).

It’s possible to make an installed system custom-tailored for virtually any task, including running your own custom and/or proprietary software in order to create an appliance-type system. The vast majority of this setup can be done in the chroot environment, but for some things which might require a GUI to complete, you’ll need to reboot into the installed system to complete the setup.

As long as all of the software you need is available in the core/community/extra repositories, you can finish pretty quickly. If you need to add custom software, or software from the Arch User Repository (AUR), then you’ll need to perform the extra steps of installing software from those sources.

NOTE: If the system will not have access to the proprietary repository post-deployment, the repository should be removed from the system after installing whatever software is required from that repository. This prevents the package manager from complaining about being unable to reach the repository every time a system update is performed. However, it also means that another method is required for pushing software updates to the deployed system.

Part 7: Third-Party Repositories

To enable a third-party repository, it simply needs to be added to the package manager’s configuration.

Here is an example repository of binary packages (it doesn’t actually exist):

Server = https://sr.example.org/arch/$repo/os/$arch

This would allow a repository configured in the same way as the offical Arch repository to be used as a source of binary packages. After making the change to add a repository to the configuration, a full system upgrade needs to be done to pull in the metadata and any available updated packages:

pacman -Syu

Part 8: AUR

While the Arch Linux binary package repository contains an awful lot of software, it doesn’t contain everything. If you want the branded, upstream Google Chrome, or to install Visual Studio Code, you’ll need pull those programs from the Arch User Repository (AUR). While these packages may be available in third-party repositories provided by users of Arch Linux, it is usually better to build packages directly from the AUR.

You only need to install one program from the AUR manually: aurget. This is also a simple process, run the following:

cd /tmp
wget https://aur.archlinux.org/cgit/aur.git/snapshot/aurget.tar.gz
tar xf aurget.tar.gz
cd aurget
makepkg -si

Once aurget is installed, you can simply ask it to install packages from the AUR, in a manner very similar to the system standard package manager, pacman:

[mbt@borgripper Blog]$ aurget -Ss zork
aur/dungeon-gdt-glk 3.2-1 
    Dungeon is the original Zork text adventure.
aur/zork1 1-11 
    Zork I adventure game (for Infocom's z-code interpreter)
aur/zork2 1-11 
    Zork II adventure game (for Infocom's z-code interpreter)
aur/zork3 1-11 
    Zork III adventure game (for Infocom's z-code interpreter)
aur/zork 0-3 
    MDL Zork!
[mbt@borgripper Blog]$ aurget -S --deps --noedit zork
:: Resolving dependencies...
:: Searching AUR...

Targets (7): osl-0.9.1-1 gcc49-4.9.4-2 isl-0.18-3 cloog-0.18.5-1 gcc43-4.3.6-8 mdli-0.2-2 zork-0-3 

Proceed with installation? [Y/n] y

[ ... output of build and installation omitted ... ]

NOTE: You do not want to run aurget as root. It will use sudo(8) to acquire root privileges to install the created package, assuming that the package file was successfully built. You might also want to edit the sudoers(5) file, so as to allow aurget to call pacman without requiring your password.


Thank you for stopping by!

If you liked this article you can give a tip or become a patron. It helps pay my bills and keep me writing.