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.
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.
BOOTPART="${MEDIA}2"
ROOTPART="${MEDIA}3"
PARTNUM=3
.
.
.
if [ "$(grep /tmp/root /proc/mounts)" = "" ]; then
if [ "$LVM_NAME" != "" ]; then
mount "/dev/$LVM_NAME/root" /tmp/root > /dev/null 2>&1
else
mount "$ROOTPART" /tmp/root
fi
fi
.
.
.
if [ "$IOT_IMAGE" = "1" ]; then
# dd doesnt support wildcards, echo to expand
PREFIX=$(echo $OSTREE_PREFIX)
elif [ "$BTRFS" = "1" ]; then
PREFIX="/tmp/root/root/"
else
PREFIX=/tmp/root
fi
# determine uboot and write to disk
if [ "$TARGET" != "" ]; then
if echo "$TARGET" | grep -q 'rpi[234]' || [ "$TARGET" = "olpc_xo175" ]; then
. "${BOARDDIR}/${TARGET}"
elif [ -d "${PREFIX}/usr/share/uboot/${TARGET}" ]; then
. "${BOARDDIR}/${TARGET}"
else
echo "= No U-Boot files found for $TARGET."
fi
else
echo "= No U-boot will be written."
TARGET="board"
fi
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 :
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).