BTRFS Arch Install – 2026

Introduction

Installing Arch Linux with Btrfs differs from an ext4 installation when preparing the disk. In this article I’ll create a Btrfs filesystem and its subvolumes, mount them, and install Arch step by step from the command line—without using Archinstall.

I’ve covered Arch installations before. My last walkthrough used ext4, and it was more than a year ago. Since the Arch installation guide changes over time, it’s worth revisiting, and one should always verify against the guide whenever following any installation tutorial.

This time, I’ll use Btrfs, or the B-tree file system, instead of ext4. I’ve had extensive experience with Btrfs over the past year and decided to try it on Arch.

This article also lays the groundwork for a future video: a pure Wayland installation using labwc. Labwc is a window-stacking compositor for Wayland, inspired by the classic X11 window manager, Openbox.

I’ll be installing Arch in a virtual machine, so a few details differ from a bare-metal installation. For example, I won’t install processor microcode in the guest. On a physical system, you’d generally install the package appropriate for your CPU vendor.

The walkthrough is divided into sections; timestamps are in the description:

Prepare
Live Environment
Drive Partitioning
File System
Base System
fstab
Change Root
Boot Loader
Login

Prepare

Preparation begins well before installation. The first step is to download the Arch Linux installation ISO and verify it.

Download: On the Arch Linux download page, choose a mirror that’s geographically close to you. I’m using a mirror in the Philippines. From the mirror’s file list, download the ISO. Arch ISO files are named with a date. Since I am downloading the ISO in October of 2026, the ISO file name will be as follows;

archlinux-2026.10.01-x86_64.iso

Next, verify the ISO. This can be a little complicated, especially if you don’t use Arch regularly, because signature verification will require signing keys that aren’t in your key-ring. I ‘m not covering key management here, as that’s part of another video series. The Arch download page includes verification instructions for Linux distributions.

Resources: While I’m installing Arch in a virtual machine (VM), the same general considerations apply to physical hardware. Since this is a test installation and proof of concept, in a later article I’ll be using labwc with Wayland, which are said to be lightweight. So in this case, I am not concerned about graphics performance. I will allocate to the VM the following;

4 GB of RAM
40 GB of storage,
4 CPU cores
UEFI Non Secure Boot enabled

Arch can run with fewer resources than I am assigning here. But since I will be testing a Wayland only installation, I’m giving it a comfortable margin above base requirements. I’m also using Virt-Manager to manage the VM, with QEMU and KVM, which does provide some virtualization and hardware acceleration.

Build the VM: From Vert-Manager, I select the new VM icon at the left of the icon bar. This starts the New VM wizard.

I select Local install media for the install method, then browse to the Arch ISO I downloaded. The wizard automatically detects it as Arch Linux.
I assign 4 GB of memory and 4 CPU cores to the VM
Then set the disk image size to 40 GB.
I select Customize configuration before install. This opens an overview Window where VM settings can be adjusted before starting the installation.
I also give the VM a name I will remember, so I can easily pick it out of a list.

In the Overview section, Virt-Manager defaults to the older BIOS firmware. I want to change the firmware to the more modern UEFI.

For my specific setup, I keep having issues with Secure Boot preventing the installation on my system. I have traced it to the default Q35 chip set. Every variation of Q35 I have tried starts with secure boot enabled, and changing that setting through the UEFI firmware menu can be awkward. So I switch from Q35 to i440FX. All the i440FX options I have tested start with Secure Boot disabled.

Some readers might think I’m against Secure Boot. I’m not, in fact I think it was a good idea. But, like many good ideas, it was turned into a bad product through corporate malfeasance.

There are other options available, but none will directly affect this installation, so I leave them as they are. Once I’ve saved my changes, I select Begin Installation in the upper-left corner of the window. This launches the Arch live environment.

Live Environment

Arch boots to a live environment, which is basically a text console. Faced with a blinking cursor, many people abort the process. Most people don’t abandon Arch because it is difficult, rather it looks difficult and they never try. Regardless there are a few things I need to do here before getting to the meat of the install.

First I want to increase the display font size, for which I use the command;

setfont ter-128b

Arch Live environment stores console fonts at /usr/share/kbd/consolefonts, if ter-128b is not available or you want to investigate alternate console fonts.

Arch defaults to a US keyboard layout. If you use a different layout, find its name with localctl list-keymaps, and load it. For example, to use the German keymap:

localectl list-keymaps
loadkeys de

Next, I’ll check that the live environment was booted in UEFI mode:

cat /sys/firmware/efi/fw_platform_size

The output should be 64, indicating a 64-bit EFI environment. If the file doesn’t exist, the system may not have been booted in UEFI mode.

I’ll also check the clock. No time sync interferes with package signature checks, so I want to make sure it’s synchronized before installing software:

timedatectl

Finally, I’ll check the network connection. I want to confirm that the system has an IP address:

ip a

I also want to test name resolution and connectivity with:

ping ping.archlinux.org

If the ping doesn’t get a reply, that doesn’t always mean the connection is down, some networks block ping traffic. But if the network isn’t working, some troubleshooting will be required before moving on.

Drive Partitioning

There are several ways to partition a drive. I’ll use cfdisk, which provides a menu-driven interface. The Arch installation guide uses fdisk in its examples, but cfdisk is also a valid option, supporting GPT partition tables, and is a little more user friendly.

First, I’ll list the available drives and identify the VM’s installation disk:

lsblk

Be sure to select the correct drive. Partitioning and formatting will erase data, so don’t proceed on a drive that contains anything you want to keep.

In my VM, the drive is labeled vda, so I will be using that. Other systems will have other drive naming conventions, like sda or nvme0n1. So substitute what is on your system.

I’ll create two partitions: a 512 MiB EFI System Partition, and one partition using the remaining space for Btrfs. I will not need a swap partition for this test. Your use case will vary from mine. If you need it, add it.

cfdisk /dev/vda

When partitioning, you need to set both a partition and its type. In cfdisk, I’ll use a GPT partition table, create the 512 MiB EFI System Partition, and assign it the EFI System type. Then I’ll use the remaining space for a Linux filesystem type partition. I’ll review the partition list before writing the changes to disk.

After partitioning the drive it is time to add file systems. I use lsblk to again see what drives and partitions are available. Again in my test VM they are /dev/vda1 and /dev/vda2. Yours may be different, so adjust accordingly.

lsblk

First, I’ll format the EFI partition as FAT32:

mkfs.fat -F 32 /dev/vda1

Then I’ll create the Btrfs filesystem on the larger partition:

mkfs.btrfs /dev/vda2

File System

This is a two stage process. First, I need to mount the btrfs partition so I can create sub volumes. Then I need to unmount it, and mount the sub volumes. I will be using two subvolumes (root and home) in this example

First, I’ll temporarily mount the Btrfs partition at /mnt:

mount /dev/vda2 /mnt

Now I’ll create the two subvolumes:

btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home

I’ll unmount the filesystem, then mount the @ subvolume at /mnt:

umount /mnt
mount -o subvol=@ /dev/vda2 /mnt

Next, I’ll create a mount point for /home and mount the @home subvolume there:

mkdir -p /mnt/home
mount -o subvol=@home /dev/vda2 /mnt/home

Now I’ll mount the EFI System Partition. I’m using /efi as its mount point, so I’ll create that directory inside the new root filesystem and mount the EFI partition there:

mkdir -p /mnt/efi
mount /dev/<partition> /mnt/efi

The efi System Partition (ESP) can be mounted at different locations; I’m using /efi for this installation. I’ll use that same mount point when configuring the boot-loader. The Arch Wiki notes that /efi is modern alternative to the older /boot/efi mount point.

Finally, I’ll check that everything is mounted where I expect:

df -h

Then-h option stands for Human readable. This displays size as KB, MB, or GB instead of just bytes.

Base System

Generally speaking, to install a basic, but not so useful system, we want three packages;

linux: The actual kernel
base: System utilities/configuration
Linux-Firmware: Meta package for common firmware

For a better user experience, and to actually use the system, at least two additional packages need to be loaded. A basic text editor and a network manager.

If you have not used command line text editors I recommend starting with nano. Later, with experience you can try others like vim.

Since I am not planning to do a lot of network configuration by hand, I want something like networkmanager installed.

Since this is a btrfs installation, I want some additional tools to manage the file system, specifically the btrfs-progs package.

In this Arch install I will be using the Grub bootloader, and since the storage drive is EFI, and there is a btrfs partiton, I need the following packages installed; grub, efibootmgr, and grub-btrfs.

For some additional utility I want to be able to look at man pages, elevate permissions of normal users when needed, and remotely access the system. So I also want to install the man-db, sudo, and openssh packages.

To do all this I need to use pacstrap, and push everything to /mnt. The -K option initializes the key-ring, which I will also need.

pacstrap -K /mnt base linux linux-firmware btrfs-progs grub efibootmgr grub-btrfs nano networkmanager openssh man-db sudo

Technically I could just add the text editor and network manager, then download other packages as I need them. But I prefer to grab them all up front.

FSTAB

Once the base system is installed, I need to generate a fstab file. The fstab file is what automatically mounts storage when the VM starts. The Arch Live Environment provides a command that automates creating the fstab file.

Also remember that our system is currently residing at /mnt and not at the root of the file system. And that the /etc directory for this system is currently at /mnt/etc.

The -U option uses the Universally Unique Identifier (or UUID) to identify storage devices. And the “>>” redirects the output to where our fstab file needs to be located, /mnt/etc/fstab.

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

Change Root

My new system has all the initial packages it needs. Now I need to enter the new system and configure it so it will actually boot when I restart. Remember I am in the Arch Installer Live environment. When I reboot that environment goes away and I boot from the existing drive, which was mounted at /mnt before, but will now be the root of the file system.

Unfortunately this drive is not setup to boot, so will fail to load. The chroot command allows us to temporally enter the new environment without rebooting, and make the necessary changes that will allow it to load on reboot. The Arch Install environment provides a specialized version of this command specifically for the new system we are building.

arch-chroot /mnt

Timezone and clock: I first set up a link to time zone information that will show up at /etc/localtime, after the reboot.

ln -sf /usr/share/zoneinfo/Asia/Manila /etc/localtime

After that I need to sync my local clock to the hardware clock.

hwclock --systohc

Language and Local: I want to also setup my default languages and locale. I need to edit the /etc/locale.gen file, and un-comment the language and locaiton I want to use. For me this is en_PH.UTF-8 UTF-8. Then I want to run the locale-gen program to set up various locale parameters.

nano /etc/locale.gen
locale-gen

Next I want to set the /etc/locale.conf file to contain LANG=en_PH.UTF-8, which is in line with my previous choice.

nano /etc/locale.conf
        LANG=en_PH.UTF-8

Network Configuration: The IP address will be handled automatically by the networkmanager program. However I still need to set the hostname. I will be using archer for my host name on this VM. Feel free to chose your own host name. One file needs to be created, and one needs to be modified.

nano /etc/hostname
	archer

nano /etc/hosts
        127.0.0.1 localhost
        ::1 localhost
        127.0.1.1 archer

Users and passwords: Next I need to set a root password and create a non privileged user. When creating the non privileged user, I need to add them to the sudo (wheel) group (allows for elevated permissions when needed). The -m creates the user home folder, and -G assigns a user to additional groups.

passwd

useradd -mG wheel user
passwd user

Next I need to activate the wheel group using visudo. Note some distros refer to this as the sudo group, but Arch traditionally uses the wheel group. Both options are available to set.

Since nano is our text editor we need to specify that to access visudo. The file we are actually editing is /etc/sudoers. This file can be edited by hand, but visudo provides some safety checks to try and keep me from messing it up. To activate wheel, we need to remvoe the “#” from the front of its line. Also we want the line requiring a password. To edit the file use;

EDITOR=nano visudo

Boot Loader

In order to boot into the new system, I need to configure the GRand Unified Bootloader (or GRUB).

The target parameter specifies a 64 bit Efi system.
The efi-directory points to the efi partition
And the bootloader is GRUB

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

After installing the boot loader, I need to configure it. The grub configuration file needs to reside at /boot/grub/grub.cfg.

I use the command grub-mkconfig, and the -o option points to the output file.

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

Reboot

Before rebooting the system, I need to set up a few application’s to start automatically. Specifically the networkmanager and the ssh server.

systemctl enable NetworkManager
systemctl enable sshd

Before reboot, I need to exit the change root environment, back to the Arch Live Install environment, which is as simple as typing exit.

exit

I also need to un-mount all the storage drives I created. Since they are all mounted to either /mnt or folders within /mnt, I can use the -R or Recursive option to un-mount everything at once.

umount -R /mnt

Finally I have arrived, I can issue the reboot command, and hopefully boot into my brand new Arch system.

reboot

Login

Assuming the system comes up, I initially log in as root. There are a couple of things I need to do, and one thing I forgot from earlier.

First I need to turn on time sync, or we might run into problems downloading and installing packages.

timedatectl set-ntp true

Next, I forgot to install the terminus console fonts, which I like to use for larger text in the terminal. However I also want to check if sudo is working so I log out as root and log in as a regular user, and install the package.

sudo pacman -S terminus-font

Now that I am here, and logged in as a regualr user, I can go ahead an poke around a bit, and see what’s what. I also want to try and log in via SSH from the host system. There are some limitations in the Vert-Manager Console (copy paste comes to mind) that will not be present with an SSH client.

Conclusion

I have reached the end of my base Arch installation. The system is up and running. So the objective has been meet.

While functional, the base system is not really usable for anything in its current state. As I mentioned in the beginning, I want to expand the base system by installing wayland and labwc with no X11 dependencies, giving it a light weight graphical environment.

I have not worked directly with wayland, and I am curious how far I can push things before needing to install xwaylnd, and maybe X11. It should be an interesting learning experience.

Retired Techie

Getting Older, not Necessarily Wiser