This guide goes through the steps of installing Fedora Server on a RockPro64 with the boot and EFI partitions on an eMMC module and rootfs on a SATA or NVMe SSD.

This guide describes installing a vanilla Fedora Server image, but it could also be used for moving an already existing Fedora rootfs to an SSD. If there is already a Fedora installation on the eMMC module, then you can start at step 3.

Requirements

• RockPro64
• Pine64 eMMC module (of at least 16GB)
• microSD card (of at least 16GB) with Armbian flashed to it, though any RockPro64-compatible Linux distro should work as long as it’s not Fedora with LVM2.
• SATA or NVMe SSD (of any size reasonable for your use-case)
• One of the following:
  • Pine64 PCI-e X4 to M.2/NGFF NVMe SSD interface card
  • Pine64 PCI-e to Dual SATA III interface card
• All of the above components are ready for use; i.e., the eMMC module is installed, the SATA or NVMe PCI-e interface card is installed with the SSD attached, microSD card has a usable Linux distro.

Plug your Armbian microSD card into the slot on your RockPro64, and boot it up. This will be used as a maintenance/rescue disk.

1. Downloading and verifying the Fedora image

On the booted Armbian, download a fresh Fedora aarch64 raw image from the Fedora website (I’m using Fedora Server in this example):

wget https://download.fedoraproject.org/pub/fedora/linux/releases/37/Server/aarch64/images/Fedora-Server-37-1.7.aarch64.raw.xz

Download Fedora’s GPG keys and checksum files for the raw image you’re using:

curl -O https://getfedora.org/static/fedora.gpg
wget https://getfedora.org/static/checksums/37/images/Fedora-Server-37-1.7-aarch64-CHECKSUM

Verify the CHECKSUM file is valid:

Note: On Armbian or other Linux distros, you may need to install the package that provides the gpgv command. On Armbian, this package is called gpgv.

gpgv --keyring ./fedora.gpg *-CHECKSUM

The CHECKSUM file should have a good signature from one of the Fedora keys.

Check that the downloaded image’s checksum matches:

sha256sum -c *-CHECKSUM

If the output says OK, then it’s ready to use.

2. Flashing the Fedora aarch64 image to the eMMC module

If you have an eMMC-to-USB adapter, the adapter allows you to flash Fedora aarch64 onto the eMMC module from your main PC via a USB port. You can run the arm-image-installer from your main PC and then place the eMMC module onto your RockPro64 before step 3.

Run lsblk to ensure the eMMC module and SSD are detected.

Clone the Fedora arm-image-installer git repository:

git clone https://pagure.io/arm-image-installer.git
cd arm-image-installer

Create a directory for the arm-image-installer and copy the files from the git repository:

sudo mkdir /usr/share/arm-image-installer
sudo cp -rf boards.d socs.d /usr/share/arm-image-installer/
sudo cp -fv arm-image-installer rpi-uboot-update spi-flashing-disk update-uboot /usr/bin/

With the arm-image-installer files in place, it’s time to flash the Fedora aarch64 raw image to the eMMC module.

We’ll assume the microSD card we’re booted from is /dev/mmcblk0 and the eMMC module is /dev/mmcblk1:

sudo arm-image-installer \
  --image=Fedora-Server-37-1.7-aarch64.raw.xz \
  --target=rockpro64-rk3399 \
  --media=/dev/mmcblk1 \
  --norootpass \
  --resizefs \
  --showboot \
  --relabel

You can also pass the --addkey flag to add your SSH public key to the root user’s authorized_keys file on the flashed image.

When the arm-image-installer finishes, your eMMC module should have Fedora with the following filesystem layout: - /boot mounted on /dev/mmcblk1p2 - /boot/efi mounted on /dev/mmcblk1p1 - / as an LVM2 member on /dev/mmcblk1p3

The LVM2 member will consist of a physical volume on /dev/mmcblk1p3. This physical volume will consist of a volume group named fedora. The volume group will consist of a logical volume named root, formatted as an XFS partition. You can check this will the following commands:

sudo pvs

  PV              VG     Fmt  Attr PSize    PFree
  /dev/mmcblk1p3  fedora lvm2 a--  <15.73g    0

sudo lvs

  LV   VG     Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root fedora -wi-ao---- <15.73g

Now we’re ready to move the rootfs on the logical volume to the SSD.

3. Move the rootfs on the logical volume to the SSD

Since I have a SATA SSD, mine will be named /dev/sda. If you have an NVMe SSD, the name will be something like /dev/nvme0n1.

Ensure the volume group is active:

sudo vgchange -ay

  1 logical volume(s) in volume group "fedora" now active

Use fdisk on the SSD to create a GPT label and parition:

sudo fdisk /dev/sda

At the fdisk prompt: - enter g to create a GPT label - enter n to create a new partition - enter w to write the changes to the SSD.

Create a physical volume on the newly created SSD partition:

pvcreate /dev/sda1

Extend the fedora volume group to the new physical volume:

vgextend fedora /dev/sda1

Move the allocated physical extents from the old physical volume to the new one.

Note that you don’t need to specify the destination physical volume, as pvmove will use the “normal” allocation policy for the fedora volume group. According to the Red Hat documentation, the “normal” allocation policy does not place parallel stripes on the same physical volume, and since there is only one other physical volume on /dev/sda1, pvmove infers the destination is /dev/sda1

pvmove /dev/mmcblk1p3

This command will take a while, depending on how much data is being moved.

When the pvmove command completes, remove the old volume group:

vgreduce fedora /dev/mmcblk1p3

4. Mount the logical volume rootfs, chroot, and update GRUB

The logical volume should now be /dev/fedora/root or /dev/mapper/fedora--root.

Mount the logical volume rootfs and the proc, sys, and dev filesystems:

sudo mount /dev/fedora/root /mnt
sudo mount -t proc proc /mnt/proc
sudo mount --rbind /sys /mnt/sys
sudo mount --rbind /dev /mnt/dev

Mount the boot and EFI partitions:

sudo mount /dev/mmcblk1p2 /mnt/boot
sudo mount /dev/mmcblk1p1 /mnt/boot/efi

Chroot into the new rootfs:

sudo chroot /mnt /bin/bash

Update the GRUB bootloader:

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

Note that the updated GRUB might detect the Linux distro you’re booting from on the microSD card. This can be updated again when you boot into the new rootfs.

Once GRUB finishes updating, exit the chroot:

exit

Unmount the boot, EFI, proc, dev, and sys filesystems:

sudo umount -R /mnt/

We should now be able to boot into the new rootfs on the SSD.

sudo systemctl poweroff

With the RockPro64 powered off, remove the microSD card, then power it back on.

“Here goes…something…” –me

If “something” turns out to be “booted into the new rootfs nicely”, you should be at the Fedora setup menu, or if you already had a Fedora installation, you should be at the tty login prompt. Yay, it works! You’re now using the eMMC module for the boot and EFI partitions and the SSD for the root partition. Enjoy the better disk read and write performance.

Postscript

While booted on the new root partition, you can remove the old physical volume, which should now be on /dev/mmcblk01p3.

sudo pvremove /dev/mmcblk0p3

Now we can resize the logical volume containing the root filesystem to its maximum space in the volume group, and then grow the XFS filesystem:

sudo lvextend -l +100%FREE /dev/fedora/root
sudo xfs_growfs /dev/fedora/root