ARM Single Board Computer (SBC) Installation

Fredrik Arneving, Peter Boy, Jan Kuparinen Version F34-F37 Last review: 2022-11-15

Fedora Server is also available for Single Board Computers (SBC) like the well-known Raspberry Pi. Installation works quite different, though. But in the end Fedora Server works on application level exactly as otherwise familiar.

How it works

Single board computers originally had only one data storage medium, an SD card. The device expects a ready-to-use operating system, configured precisely for the respective hardware. This original principle is still maintained today and is the universal method provided by every SBC model.

Therefore, Fedora Server Edition is distributed as a Fedora Server Edition image file. The installation is simply a matter of copying this image file to an attachable storage medium, traditionally an SD card, while at the same time making adjustments to the specific hardware and some software configurations in the process.

Many SBC models today additionally offer other media that can also be the target of this copying process, often eMMC storage. Some can also support extended firmware, usually in the form of SPI modules that allow further selections during boot, e.g. NVMe boards or USB sticks.

Prerequisites

Of course, you need a suitable single board computer model, supported by Fedora and with a network connection, keyboard and display. A simple text console is perfectly sufficient. The initial configuration at first boot is performed at a local text terminal and performs a bare minimum initial configuration. Afterwards you will perform everything using either ssh or more comfortably using Cockpit, a graphical, web-based user interface, which is preinstalled and activated by default. Of course, you can continue to use the text terminal as well.

The critical passage is "supported by Fedora". When choosing a device for Fedora Server, check carefully if it is really actually supported. Unlike the x86 universe, don’t expect everything to work just as smoothly in ARM rsp. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list.

The section Fedora Server on Single Board Computers provides additional information.

A bootable removable disk of suitable size, practically, this is either an SD card or eMMC storage on a removable daughter board. In special cases, when a UEFI capable SPI is available, booting from USB or other media may also be possible.

The absolute minimum capacity is 8 GB, but avoid anything smaller than 16 GB. Unless you intend to operate a database or, e.g., a music library, a capacity of 32 GB should be fine and affordable nowadays.
A Fedora Desktop or Server, which provides the Fedora utility program to transfer the image to the prospective boot medium and to configure the generic Fedora Server image for use with a specific SBC model. Optionally, it can also make some adjustments to the initial configuration. The utility should be usable with any Linux desktop, but not with Windows or MacOS.

And your Fedora box must be able to write to a SD card, either by a dedicated slot or a USB adapter.

Special considerations: Organization of the storage area

Basically, Fedora Server on SBC follows the same storage configuration principles as on 'full-blown' Server Hardware.

It uses UEFI as boot system. This distinguishes Fedora from other distributions. Therefore, it first creates an EFI partition and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG), which provides a logical volume with XFS file system for the operating system and its software. Just as on any other architecture. The size of the root volume is limited, on 'full-blown' hardware about 15 GB depending on the disk size. The rest is left free for other logical volumes that are to hold user data.

The rationale behind this is a separation of system and user data. This does ease system administration, increase security, and decrease error-proneness. Please, read the section "Storage organization" in the installation overview and the supplementary information in the Post installation tasks section.

Fedora Server Edition implements this principle, which originated in professional IT, on SBCs as well. For practical reasons, the deliverable is limited to just under 8 GB in total. This means that the download file is not excessively large and can be installed even on the smallest SD cards currently available. During or after installation, the size is adjusted to the existing hardware.

For sure, disk organization is an issue where hardly 2 system administrations agree on. As a rule of thumb, segmentation is not appropriate for a disk of 16gb or less. At a size of 32gb, it would be worth considering if it is a serious use with data of some relevance. For even larger volumes and serious use, it is definitely something to consider.

Steps to install Fedora Server Edition on a Single Board Computer

Preparations

Set the download directory as default, fetch a Fedora Server aarch64 system disk raw image, here F34, and check the integrity of the download.

[…]# cd ~/Downloads
[…]# wget http://download.fedoraproject.org/pub/fedora/linux/releases/36/Server/aarch64/images/Fedora-Server-36-1.5.aarch64.raw.xz  -O Fedora-Server-36-1.5.aarch64.raw.xz
[…]# wget https://getfedora.org/static/checksums/36/images/Fedora-Server-36-1.5-aarch64-CHECKSUM   -O Fedora-Server-34-1.2-aarch64-CHECKSUM
[…]# sha256sum -c *-CHECKSUM  --ignore-missing

On a Mac (Catalina) use shasum5.28 instead.

On a Fedora Workstation, install arm-image-installer
```
[…]# dnf install  arm-image-installer uboot-images-armv8.noarch
```
On a Mac or Windows Desktop you have to install VirtualBox or any other virtualization software and install Fedora as a guest system, and then thereon likewise arm-installer. If your device is a Raspberry Pi model 3 or 4 you don’t need to make any adjustments and can install Balena Etcher instead to transfer the image to the SD card.

Connect your Micro SD card to your desktop. Identify the device name and unmout the device if it is mounted.

On a Fedora workstation you may use:

[…]# lsblk
NAME              MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                 8:0    0 596,2G  0 disk
├─sda1              8:1    0   600M  0 part /boot/efi
├─sda2              8:2    0     1G  0 part /boot
├─sda3              8:3    0    30G  0 part
│ └─sysvg-root    253:0    0    15G  0 lvm  /
└─sda4              8:4    0 564,6G  0 part
  ├─usrvg-var_log 253:1    0     5G  0 lvm  /var/log
  └─usrvg-libvirt 253:2    0   200G  0 lvm  /var/lib/libvirt
mmcblk0           179:0    0  29,5G  0 disk
└─mmcblk0p1       179:1    0  29,5G  0 part
zram0             252:0    0   7,5G  0 disk [SWAP]

[…]# umount /path/to/mountpoint/above

On a Mac open a terminal und issue:

[…]# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
...
...
/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *31.9 GB    disk2
...
...

[…]# sudo  diskutil unmountDisk  /dev/disk2

Identify the name of the support files for your board

[…]# arm-image-installer --supported
AllWinner Devices:
A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino-Lime A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC A20-OLinuXino_MICRO A20-Olimex-SOM-EVB Ampe_A76 Auxtek-T003 Auxtek-T004 Bananapi
...
TI Devices:
am335x_evm am57xx_evm kc1 omap3_beagle omap5_uevm omap4_panda
Note: For the am33xx BeagleBone devices use 'am335x_evm', BeagleBone AI use 'am57xx_evm'

MVEBU Devices:
clearfog helios4

ST Devices:
stih410-b2260

Other Devices:
arndale chiliboard cl-som-am57x rpi2 rpi3 rpi4 olpc_xo175

In the example above you find "rpi4" as the name of a Raspberry Pi Model 4.

If you don’t find your board, check the boards.d directory directly just in case the list is not up to date.

[…]# ls -al /usr/share/arm-image-installer/boards.d  |  less

As an example., you will find the Radxa board "Rock Pi 4" model a and b as "rock-pi-4-rk3399"

Transfer the raw disk image to the micro SD card
```
[…]# arm-image-installer --image=Fedora-Server-36-1.5.aarch64.raw.xz --target=rpi4 --media=/dev/mmcblk0
```
Just in case you already decided to fill the complete space on disk with the root file system and to dispense with segmentation, you may add the --resizefs parameter which would result in an alternative command line:
```
[…]# arm-image-installer --image=Fedora-Server-36-1.5.aarch64.raw.xz --target=rpi4 --resizefs --media=/dev/mmcblk0
```
In case of an alternative SBC as the Rock Pi 4 mentioned above would use yet another command line:
```
[…]# arm-image-installer --image=Fedora-Server-36-1.5.aarch64.raw.xz --target=rock-pi-4-rk3399 --media=/dev/mmcblk0
```
Consult the ARM Installation Guide for a complete description of the available options.

After the transfer is complete, unmount the SD card again if it was automatically re-mounted, and disconnect it.

Basic Installation

Directly at a terminal of the SBC we will make only the minimal, absolutely necessary configuration. This is the setting of a root password and the determination of the IP address. Everything else is done comfortably on our desktop.

Make sure that the SBC is disconnected from power.
Connect monitor, keyboard and network cable, insert the micro SD card.
Connect the SBC to power and wait. After some time you will be greeted by a very plain configuration screen.
If you have a DHCP server on your LAN the only strictly necessary action is to configure root password. Type "4" and enter a suitable password. If you are on a non-US keyboard you should restrict yourself to traditional ASCII and avoid special characters for now. Otherwise, you might later not be able to enter the root password correctly, because a different keyboard mapping applies. In the next stage, with correct mapping, you can set up the password as complex as you like.
If you don’t have a DHCP server on your LAN type "3" and fill in your hostname and your network details.
Tap "c" to continue and finalize the configuration. After some waiting, the Fedora Server login prompt appears.

Always complete this step and close with 'c'. Otherwise this installation routine can on reboot again and again conflict with the subsequent configuration.
Above the user input, a line with the (temporary) name of the computer and an IP address is displayed. The name is "fedora" by default and the IP address depends on the network. Note both carefully.
You can now disconnect monitor and keyboard. The next steps all happen on the desktop.

Final Configuration

On your desktop open a Browser and enter name and port http://fedora:9090. Sometimes the internal DNS already works. If not, use the IP address you wrote down, e.g. something like http://192.168.158.116:9090. After accepting a warning message due to a missing certificate, voilà, the Cockpit administration interface of your SBC appears.
Login with your root account to continue configuration
First adjust hostname

Click onto "set hostname" and enter a short name (display name) and a fqdn name.
Adjust time and time zone if necessary. Click on system time and select the time zone. Automatic time synchronization should already be enabled.

If a local time server is available in your network, it can be entered here. Many routers offer such a function and relieve the infrastructure.
To be able to access as root via ssh, you have to install your public ssh key for root.

Select "accounts" in the left navigation column and choose the root account. At the bottom select "Add Key". Copy&paste your public key into the input field.

If you chose a simple password during the basic installation, you should replace it with a more complex one at this occasion.
If you are non-US you may want to set your language. In any case, you should choose the keyboard layout correctly. Otherwise, in case of an emergency you may have to use a directly attached monitor and keyboard again, you need a correct mapping to act efficiently.

Select "Terminal" in the left navigation menu. You get a terminal access to your device, already logged in as root.
1. List available languages by "localectl list-locales". Find your locale in the list and note the token, e.g. de_DE.UTF-8. Set the language with "localeectl set-locale LANG=TOKEN", e.g. "localeectl set-locale LANG=de_DE.UTF-8".
2. List available keyboard mappings by "localectl list-keymaps". Find your keymap in the list and note the token, e.g. de-nodeadkeys. Set the keymap with "localectl set-keymap MAP_TOKEN", e.g. "localectl set-keymap de-nodeadkeys".
3. Finally check by "localeectl"
Most likely, the packages of the distributed file image are not up to date. In the menu bar on the left, you will probably see an exclamation mark next to "Software Updates". Select this menu item. A search for updates starts and after some time a list of updates appears. Select "Install all updates" and sit back. It will take a while.

If the cockpit packages are also updated, the connection is interrupted. You must then reconnect.

With everything done reboot the system. In the overview screen select either reboot or shutdown in the upper right corner. You can now use a shutdown to disconnect keyboard and monitor, if desired. You may also put the device in a different, final place. Start the device afterwards.
When the device is up again it is time to test the installation.
1. If your DHCP is correctly configured, you should be able to find your device by name now. Close your browser window and start again. Write the device name and port number in the address field, e.g. http://rockpi.example.com:9090 and Cockpit should come up again (after the usual warning about an insecure connection).
2. You should be able to log in via ssh as root and your key. Try ssh -i .ssh/MYKEY rockpi.example.com and after answering a question to accept the fingerprint you should gain access.
Finally, depending on the use case, you may need to ensure you can always track which person was logged in and when. Use Cockpits account management feature to comfortably create additional users and grant them administrativ permissions ("sudo"). You might want to lock the root account completely (postpone this until storage area configuration is completed).

Configuration of the storage area

As explained at the beginning, there are at least three alternatives to organize the storage area.

Filling all the space left after the base installation with the ROOT file system.

This is the simplest solution and the only sensible one for disks of up to 16gb.
Extend the partition and volume group to the remaining available disk space, extend the logical volume with the ROOT file system to about 12gb and leave the remaining area for logical volumes for dedicated payloads (database, libraries, etc.).

This is the most flexible solution and preserves all options for the system administrator depending on the actual progression of usage. It is especially recommended for disks of 64gb and more, but should also be considered with a size of 32 gb.
You may reinforce the rationale of separating system and user data even further and create a separate partition and volume group for user data. This seems a bit far-fetched for a (small) SBC, but is nevertheless worth considering if a very large volume and correspondingly a large amount of data are present (a rule of thumb: larger 500 GB).

Enlarge partition and volume group to fill the disk space

Any of the alternatives as above start with the same administrative tasks.

Login via ssh or switch to terminal in Cockpit (logged in as root)
Use lsblk to determine the device name of your disk storage, most likely mmcblk1
Invoke cfdisk with that device name:
```
[…]# cfdisk /dev/mmcblk1
```
Select partition 3 (Type 8e Linux LVM) using <Cursor down> and then Resize using <Curser left>
The suggested size fills the complete disk.

In case of alternative 1 or 2 confirm with <Return>.

In case of alternative 3 select a size for system VG, as a rule of thumb at least 10GB, max. 30 GB.

Select "Write", confirm resizing and quit the program.

Resize the volume group

[…]# pvresize  /dev/mmcblk1p3
 Physical volume "/dev/mmcblk1p3" changed
 1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Select "Storage" in Cockpit and inspect the Volume Group fedora_fedora in the upper right corner. The displayed size now shows an amount that indicates a complete fill of the entire disc rsp. as configured.
A click onto the fedora_fedora volume group brings up the logical volume view. In the "Logical volumes" list expand the root LV (/dev/fedora_fedora/root).

For alternative 1. select "Grow" and expand the volume to fill the complete available space.

For alternative 2. select "Grow" and expand the volume to sensible size. 10gb would be good to start with.

For alternative 3. select "Grow" and expand the volume to a size that still leaves room for the unanticipated. An initial size for root between 8 and 12 GB would be good to start with.
Go back to the terminal.
```
[…]# df -h
```
Confirm that the size of the root file system is now of the specified value.
In case of alternative 3 use Cockpits storage to create an additional partition and volume group.

Later, when you install applications and services you will use Cockpit storage to create logiocal volumes and mount them at the appropriate location. As an example you may create a logical volume "postgresdata", create an XFS filesystem and mount it at /var/lib/pgsql before actually installing postgresql.

After all the major modifications to the file system, it is now advisable to reboot before any further work is done.

Troubleshooting

At the first system start the grub2 boot screen is displayed briefly, then the monitor remains dark.

Check if the network interface indicates a connection (the LEDs are on or blinking). In this case, it is likely that the device is fully booted and just the console interface is broken.

Because in this case Cockpit is started and active on the device, use your Fedora desktop and search the network segment, e.g. 192.168.158.0/24 for devices with active port 9090.
```
[…]# dnf install nmap
[…]# nmap -Pn -p9090 192.168.158.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-23 08:18 CEST
Nmap scan report for fritz.box (192.168.158.1)
Host is up (0.00052s latency).

PORT     STATE  SERVICE
9090/tcp closed nn-admin
MAC Address: 34:81:C4:14:21:B4 (AVM GmbH)

Nmap scan report for iMac.fritz.box (192.168.158.111)
Host is up (0.00051s latency).

PORT     STATE  SERVICE
9090/tcp closed nn-admin
MAC Address: 68:5B:35:97:9F:33 (Apple)
...
...
Nmap scan report for raspi3.fritz.box (192.168.158.116)
Host is up (0.00075s latency).

PORT     STATE SERVICE
9090/tcp open  nn-admin
MAC Address: B8:27:EB:5A:EC:84 (Raspberry Pi Foundation)

Nmap scan report for 192.168.158.120
Host is up (0.00068s latency).

PORT     STATE SERVICE
9090/tcp open  nn-admin
MAC Address: 06:BE:DE:31:C6:E2 (Unknown)
...
...
Nmap done: 256 IP addresses (12 hosts up) scanned in 2.38 seconds
```
Look for an entry with open state of port 9090 and no hostname or unknown hostname. Among them you will probably find the device you are looking for. In the example above it is 192.168.158.120.

Enter the address https://192.168.158.120:9090 into your browser. If successful, a cockpit login page opens, which simply outputs "fedora" as the hostname (in the lower part of the login widget). Otherwise, check the other suitable addresses.

Unfortunately you can’t log in right now because you don’t know the password.

You have to rebuild the device operating system on SD card and add a SSH public key to be able to login via SSH and set a root password.

Beforehand you need to create pair of SSH keys if not already exist. It is best to create the key in the .ssh subdirectory of your home dir. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing types abbreviation, e.g. '_rsa' is just a common convention, yet helpful. Execute on the local desktop and adjust appropriately:
```
[…]# cd
[…]# mkdir ~/.ssh
[…]# ssh-keygen -t rsa -b 4096  -C "root@example.com" -f ~/.ssh/<outputkeyfile>
```
As an example you may use the name "id_mysbc_rsa". Although the type rsa is widely used, you may adjust your key type accordingly.

Turn off the SBC, remove the SD card and connect it to your desktop again as in section "Preparations". Transfer the operating system image file again as in step 5 of that section but use an additional option:
```
[…]# cd
[…]# arm-image-installer --image=Fedora-Server-34-1.2.aarch64.raw.xz --target=rock-pi-4-rk3399 --addkey=~/.ssh/id_mysbc_rsa.pub  --media=/dev/mmcblk0
```
When the process has finished, reinstall the CD card in the SBC, and connect to power to start the device again.

Ping the address and as soon as you are connected, use ssh to log in and set a password for root.
```
[…]# ping 192.168.158.120
[…]# ssh -i .ssh/id_mysbc_rsa  root@192.168.158.120
[…]# passwd
```
In your browser open again https://192.168.158.120:9090, login as root using the password as set above, and proceed with section "Final configuration".

Want to help? Learn how to contribute to Fedora Docs ›