Let’s first have a look at the layout of the Manjaro image. We’ll use this a template for crafting our own image.

The first line partition is /boot, containing the Linux kernel, initramfs, and device trees. It starts at sector 62500, meaning that the bootloader resides in the sectors below 62500.

The next step is to insert our fresh micro SD card and open it in fdisk. I’ll leave 62500 empty sectors at the start like in the reference image, then a relatively small /boot partition in VFAT format.

It’s common to use VFAT for the boot partition as it’s a relatively simple filesystem. The boot partition contains the Linux kernel image and related files which need to be accessed directly by the bootloader. A typical bootloader lacks built-in drivers for more complicated filesystems.

The rest of the free space will be used for a standard Linux partition to serve as our provisional root filesystem. This is how it looks in fdisk:

Now we steal the boot sectors from the Manjaro image, copying them directly onto the memory card using dd. The sector size is 512 bytes and the first sector contains the partition table we just set up, it should not be overwritten.

We can verify by looking at a hexdump of the card that it seems to be correctly set up:

The first blob is the partition table, then at offset 0x8000 the bootloader starts with the magic number described in the boot documentation. All is well.

Now let’s format the partitions and mount them at some temporary mount points.

The "generic" Arch Linux image is a simple tarball of how the complete filesystem should look. We extract the /boot part to the boot partition and the rest to the root partition.

An ARM bootloader has three main jobs: Initialise DRAM, load the main operating system components (kernel image, kernel command line, initramfs, and devicetree) into DRAM, and then jump into the kernel.

I guessed that Manjaro’s bootloader will automatically read the first partition on the SD card to find out what to do. At this point we don’t know exactly how to configure the boot loader beyond that. Let’s mount the unmodified /boot partition of Manjaro’s image and poke around a bit.

There is a file called extlinux/extlinux.conf which looks promising:

Much of this is fine as is, but the root= parameter of the kernel command line is problematic. Let’s find the PARTUUID of our newly created boot partition:

Armed with this information we change extlinux/extlinux.conf into:

Finally, sync the changes to persistent storage and then unmount the partitions and insert the micro SD-card into our RockPro64 board.

To see what’s going on, I connect the serial adapter I purchased from Pine following the description given on the Pine forums. GNU screen can be used to monitor the serial port.

Now, turn on the power!

The output ends with:

Incidentally, the password for user "alarm" is "alarm" and the password for "root" is "root".

The kernel mounts the root filesystem automatically, because it’s passed on the kernel command line. Other filesystems like /boot, we have to configure in /etc/fstab. We also have the option to specify particular options for the root filesystem.

Let’s look at the filesystems we have available:

Given this we edit /etc/fstab into the following:

Now we can verify that /boot turns up as expected.

The Arch Linux image is configured to automatically connect to the internet. We can verify that this works:

We need to initialise Pacman’s keyring for first use. Then we can start a full system upgrade:

As part of this, a new Linux kernel will probably be installed and a new initramfs created (if this doesn’t happen, you can force it with pacman -S linux-aarch64). To test that the new kernel boots correctly, we reboot the system now.

So far we have been working with all filesystems installed on the SD card. We’ll now move the root filesystem onto our much larger and faster NVMe SSD, keeping only /boot on the SD card.

Connect the SSD adapter card and check that it’s correctly detected by Linux:

There are multiple ways to partition and format a disk for server use. A traditional option would be to use LVM virtual partitions and Ext4 filesystems. Because this project is done "the hard way" we’ll go for something more exotic: Partitionless Btrfs filesystem. Btrfs is a newer filesystem which has its own partition-like features built-in, so it doesn’t need partitions in the traditional sense.

First, install the Btrfs tooling:

Format the SSD:

Note that we are formatting the whole block device, not a partition.

I’ll use rsync to copy the root filesystem onto the SSD. The -x option to rsync tells it to stay on a single filesystem, so it won’t copy the contents of /dev, /sys, etc.

The lost+found directory is a quirk of Ext filesystems and isn’t needed on Btrfs.

Now we need to adjust the kernel boot command line and /etc/fstab to use our newly created filesystem as root.

We edit /etc/fstab into:

These IDs are again found using the blkid command. The file /boot/extlinux/extlinux.conf becomes:

Now we can reboot into the new configuration and verify that everything works.

My RockPro64 has 4 GB of DRAM. This will be enough for normal operation, but it may fill up during nightly backup operations and similar work. For this reason, I want to add some swap space to the system.

Because we don’t have partitions on our SSD, we can’t have a traditional swap partition. We need to go with a swap file. Setting up swap files is a bit messy on Btrfs, due to some of the optimisations that Btrfs uses. I followed a guide I found on Askubuntu.

The first step is to create a new subvolume for the swap file. Subvolumes is a Btrfs concept which is similar to a partition. Storage space is shared between all suvolumes, so we don’t have to decide a partition size up-front (a huge plus). Also, the subvolumes have a fixed location relative to the main volume, so they don’t need to be mounted explicitly. They are automatically mounted at the right relative location when the main volume is mounted.

To make the swapfile permanent, we also need to add it to /etc/fstab:

Now reboot into the new configuration and verify that the swapfile is set up correctly using free -h.

Btrfs offers an exciting possibility: volume snapshots. It’s possible to quickly and atomically create a complete frozen snapshot of a volume. This means that we can safely perform raw backup of a running database, for instance.

My backup strategy will be to snapshot the whole root filesystem, then use Restic to back it up to Backblaze B2. Restic is a very fast deduplicating backup tool which has dedicated backends for various cloud storage vendors.

After following Restic’s quickstart guide for B2. I set up a systemd timer to run my backup script as the root user, every night at midnight. The script simply creates a snapshot of the root volume, backs it up, then deletes it. There is also an exclude list of directories which should not be backed up.

The rest of the installation process is not specific to ARM or the RockPro64, so I won’t describe it in detail. You can follow any standard installation guide, for instance the Arch Linux installation guide.