Adding a board for the ARM image installer

According to the documentation:

from Architectures/ARM/Installation - Fedora Project Wiki


Used to deploy disk images for ARMv7hl as well as a limited set of Aarch64 SBCs. Execute the following script as a user with sudo privileges. It will copy the selected disk image and write the appropriate U-Boot for the target hardware platform. Optionally you can also enable and disable SE Linux and remove the root password requirement (allowing log in without completing initial setup). To add a board not listed, simply create a bash scriptlet with the commands needed to copy U-Boot to media and add to the ‘boards.d’ (/usr/share/arm-image-installer/boards.d) directory.

Do I add the script to the boards.d directory of the install-image or the current system from where the arm-image-installer is executing from?

That seems self explanatory. Did you investigate the content of that directory on the host system where you would be running the arm-image-installer app?

It seems quite obvious that the arm-image-installer would need to access and run the scriptlet you create for that board.

I think it’s ambiguous between the hosting system, the staging system and the supplied images.

What if my hosting system isn’t the same board. Which is what occurs when there is no image for a specific board.

So what I going to do is get another supported ARM board. Install Fedora from the standard images to that and use that as a host.

I wonder if I can just use the usual Intel image as a host or does it have to be ARM based?

I’ll try a Fedora VM and see if that directory exists. If so I should be good!

Not true.
/usr/share/arm-image-installer/boards.d on my system contains the default files and contains 172 scriptlets including several for bananapi, orangepi, rpi, and many other SBC boards.

It is not required that the system being used to load the image onto the sd card even be the same arch as the sbc, only that the proper script be available to properly configure u-boot for that sbc. I use my desktop (fedora 36 on an x86_64 system) and run arm-image-installer to load several different arm images onto sd cards for an rpi. I have done rasbian, raspi, fedora IoT, Ubuntu 20.04 & 22.04, debian, and others all successfully and booted on the rpi4 at first try.

The images I use are always the .raw.xz image for the proper arm arch. Most images I deal with have the aarch64 or arm64 image as 64 bit and the armhfp or armhf as 32 bit.

for the info on how to use arm-image-installer use sudo arm-image-installer and man arm-image-installer and it will show the options. For the list of supported sbc boards use sudo arm-image-installer --supported (which will also show any custom boards with the scripts you have created and loaded into that board.d directory)

Ok because looking in the arm-image-installer script. It appears to require the uboot board copy script in the provided fedora image and not on the host system running the arm-image-installer.

if [ "$(grep /tmp/root /proc/mounts)" = "" ]; then
	if [ "$LVM_NAME" != "" ]; then
		mount "/dev/$LVM_NAME/root" /tmp/root > /dev/null 2>&1
        	mount "$ROOTPART" /tmp/root
if [ "$IOT_IMAGE" = "1" ]; then
	# dd doesnt support wildcards, echo to expand
elif [ "$BTRFS" = "1" ]; then

# determine uboot and write to disk
if [ "$TARGET" != "" ]; then
	if echo "$TARGET" | grep -q 'rpi[234]' || [ "$TARGET" = "olpc_xo175" ]; then
	elif [ -d "${PREFIX}/usr/share/uboot/${TARGET}" ]; then
		echo "= No U-Boot files found for $TARGET."
	echo "= No U-boot will be written."

So after dd’ing the image to the device it mounts the partitions on the device at /tmp/root boot and firm.

It then assigns /tmp/root to $PREFIX is used to locate the board specific uboot script.

So catch 22. It must already be there before running the installer!

I could modify the script to look for the script on the host instead but I suspect I’m missing something or haven’t done something required yet.

here is some of the output of the script using sh -x :

++ echo Fedora-Workstation-37_Beta-1.5.aarch64.raw.xz
++ grep IoT
+ '[' '' '!=' '' ']'
+ '[' '' '!=' '' ']'
+ '[' '' = 1 ']'
+ '[' 1 = 1 ']'
+ PREFIX=/tmp/root/root/
+ '[' odroidn2 '!=' '' ']'
+ echo odroidn2
+ grep -q 'rpi[234]'
+ '[' odroidn2 = olpc_xo175 ']'
+ '[' -d /tmp/root/root//usr/share/uboot/odroidn2 ']'
+ echo '= No U-Boot files found for odroidn2.'
= No U-Boot files found for odroidn2.

Otherwise I have to modify the downloaded fedora image and add my odroidn2 uboot copy script to it before I start arm-image-installer!

Any ideas.

So the way I got around this is by running the script twice.

The first time I provide the fedora-image:

sudo arm-image-installer --image=Fedora-Workstation-37_Beta-1.5.aarch64.raw.xz --target=odroidn2 --media=/dev/sdb

This fails but leaves the newly burnt image accessible and mountable. So at this point I add the required odroid uboot to that device.

mkdir /mountpoint/root/usr/share/uboot/odroidn2
cp ~/Odroid-N2/u-boot.bin /mountpoint/root/usr/share/uboot/odroidn2

Then I reissue the installer command without an image which skips the burn process.

sudo arm-image-installer --target=odroidn2 --media=/dev/sdb

Then it installs the uboot.

So the script resides on the host but the arm-image-installer script expects to find the uboot directory on the image. Even though my script was written to use the u-boot on the host.
So it just needs to see the directory (it can be empty in my case).

So now to test my new image!!!

1 Like

Glad that you figured it out.


I’m trying to install F37 IoT on odroid-c4 but it won’t boot so I’ve tried your solution but no luck.
How did you compile your u-boot.bin?