ARM single-board computers typically have only __one data storage medium__, an SD card, with no BIOS or equivalent firmware to initialize the hardware at boot time and make it accessible. The operating system has to provide this function, too. The u-boot bootloader is one of several options for providing this function. Therefore, the installation method for SBC devices works quite differently compared to other platforms.
// Please, comment in the Warning below when you start
// to modify this text!
//[WARNING]
//====
//**You are in the Fedora Server documentation staging area!**
//
//These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt! You would probably prefer to study the link:++https://docs.fedoraproject.org/en-US/fedora-server/++[published documentation].
Even though many SBC devices now also feature eMMC modules or m.2 NVMe interfaces, the boot process remains very simple. The minimal firmware continues to boot from the SD card, and possibly supplementally from eMMC or an SPI flash module. The device expects a ready-to-use operating system, configured precisely for the respective hardware, including low-level hardware initialization.
A widely used software that provides this functionality is the bootloader __u-boot__. It is basically a collection of low-level, model-specific device drivers.
Instead of creating a separate distribution file for each model, Fedora Server Edition is distributed as an __unified basic image file__. The installation program _arm-image-installer_, transfers this image file to the designated storage medium and then adds model-specific u-boot bootloader files.
Even though the installation works quite differently, Fedora Server ultimately functions just like usual at the application level.
* 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 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, e.g. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list or Matrix room.
The utility should basically be usable with any Linux desktop, but not with Windows or MacOS. You have to install VirtualBox or any other virtualization software that is able to provide direct access to the physical USB port or SD card slot, and install Fedora as a guest system.
//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.
* A *pluggable disk* of suitable size, practically, this is either an SD card or eMMC storage on a removable daughter board. The absolute minimum capacity is 8 GB, but a capacity of 32 GB should be fine and affordable nowadays.
Basically, Fedora Server on SBC follows the same storage configuration principles as on 'full-blown' Server Hardware. Please, read the section "Storage organization" in the xref:installation/index.adoc#_storage_organization[installation overview] and the supplementary information in the xref:installation/postinstallation-tasks.adoc#_consolidate_storage_configuration[Post installation tasks] section. Fedora Server Edition implements this principle, which originated in professional IT, __on SBCs__ as well.
Fedora uses UEFI as the boot system, but on SBCs it still uses a DOS/MBR partition table. Therefore, it first creates a FAT partition for EFI and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG) as described in the forementioned guide.
For practical reasons, the downloaded deliverable is limited to just under 8 GB in total. During or after installation, the size is adjusted to the existing hardware.
Many SBC models today offer additionally alternative storage media, especially eMMC memory, either pluggable or soldered. Nevertheless, the installation procedure remains basically the same.
If using a pluggable memory, connect it to the desktop with an adapter; it becomes the target for the image transfer instead of the SD card. For soldered memory, first use the SD card for installation, then copy the image to the internal eMMC memory in a second step.
Some models provide a special flash module (SPI) to store a custom bootloader. For these cases, the u-boot bootloader offers a special format that is flashed onto the SPI module. This requires a board-specific tool independent from Fedora. The Fedora Server unified basic image file is transferred to the installation medium unchanged.
These bootloaders quite often support extended options to boot from, e.g. NVMe boards, SATA drives, or USB sticks.
Here we describe the basic steps for creating a customized boot medium (SD card or eMMC module).
4. In the above example the device is obviously _/dev/mmcblk0_ and its partition (mmcblk0p1) is not mounted anywhere. If it were, you would have to unmount the device.
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_:
Consult the https://fedoraproject.org/wiki/Architectures/ARM/Installation#Arm_Image_Installer[ARM Installation Guide] for a complete description of the available options.
At the SBC terminal, we perform only the minimum, absolutely necessary configuration, namely the creation of a user including password and administrative privileges. Just in case your network doesn't provide DHCP, you have to configure the IP address as well. Everything else can be more conveniently accomplished via ssh or Cockpit from the desktop.
3. Connect the SBC to power and wait. After some time a lot of messages scroll across the screen. If the network interface doesn't provide DHCP, in includes a NetworkManager error message. You can safely ignore it for now. It finally ends with a simple, text-based input mask for the first boot configuration.
Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to
refresh]:
----
+
The menu is quite simple and a bit old-fashioned, but effective and straightforward. Select the item you want to configure by entering the digit in front of it and then follow the corresponding submenu displayed in the same way. An 'X' in the square bracket indicates that an item is already configured or preconfigured with default values.
4. The most important item is the configuration of an admin user and their password. Type 5 to enter the submenu.
The "[x]" in front of Create user indicates that you entered "1" (to create user) and now the user creation process is active. Accordingly, password authentication is enabled for the new user as well as administrator privileges and membership of the wheel group.
Fill in the full name, the user name and the password. If you are on a non-US keyboard note that no keyboard mapping is active and limit yourself to universal standard ASCII characters and avoid special characters for now. Otherwise, you might later not be able to enter the password correctly, because a different keyboard mapping applies. You can change the password to a more secure value later. In any case ensure that you keep administrator privileges unchanged!
+
If you enter a "c", the user configuration will be closed and you will return to the original main menu.
5. If you do not live in the US/Eastern time zone, it would be wise to set it here as well. It is very simple and straight forward in the menu. Type '2' and select the correct values from the lists. Enter "c" to close it.
+
Usually, leave the ntp server as is.
+
If you are uncomfortable with the entry here, you can also enter this and all the following information later comforatbly with the Web interface.
6. If you don't have a DHCP server on your LAN you may configure network connection in this menu or use the command line in the next stage. Specifically it you use a non-US keyboard it may be tedious and error prone to use this menu.
+
Even with DHCP active, it may be useful to set the hostname here, so that an internal DHCP-based name server receives the correct name immediately. Type "3" and fill in your hostname.
7. Finally, type 'c' to exit the first-boot configuration menu and complete the basic configuration. After some waiting, the Fedora Server login prompt appears.
The hostname here is default, because the box didn't receive a name from DHCP during first boot. Please note the IP address to use next with ssh or Cockpit.
Always complete this step and close with 'c'. Otherwise this installation routine can on reboot again and again conflict with the subsequent configuration.
8. If you have the network connection ready, you can now disconnect monitor and keyboard. The next steps all happen on the desktop.
+
Otherwise configure the network connection now.
a. Login with your administrative account
b. If you are a non-US keyboard user, configure your keyboard mapping. Fist list the available keyboard mappings and note the name of a suitable mapping, e.g. de-nodeadkeys. Then configure it.
Most likely your interfaces are named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Don't forget to adjust the naming to your specific installation!
1. On your desktop open a Browser. If you already set the correct hostname and DNS entry, use that. Otherwise, use the IP address for now. In the example above it is __http://192.168.158.172:9090__. After accepting a warning message due to a missing certificate, voilà, the Cockpit administration interface of your SBC appears.
4. *Adjust time and time zone* if necessary and not already done. Click on system time and select the time zone. Automatic time synchronization should already be enabled.
5. 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.
a. 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 "__sudo localeectl set-locale LANG=TOKEN__", e.g. "__sudo localeectl set-locale LANG=de_DE.UTF-8__".
b. 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 "__sudo localectl set-keymap MAP_TOKEN__", e.g. "__sudo localectl set-keymap de-nodeadkeys__".
6. To be able to access your account via ssh, you should install your public ssh key.
+
Select "accounts" in the left navigation column and choose your 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.
7. 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.
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.
a. 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://rockpro.example.com:9090 and Cockpit should come up again (after the usual warning about an insecure connection).
b. You should be able to log in via **ssh and your key**. Try _ssh -i .ssh/MYKEY rockpi.example.com_ and after answering a question to accept the fingerprint you should gain access.
9. 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").
2. 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.
3. 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).
7. Select "Storage" in Cockpit and inspect the Volume Group _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.
8. A click onto the fedora volume group brings up the logical volume view. In the "Logical volumes" list expand the root LV (/dev/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.
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.
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.
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.172.
Enter the address _https://192.168.158.172: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.
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:
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:
