Problems building a Raspberry Pi 3 Image/Artifact (Mender 1.3 Beta)

[Felix Geisendoerfer]

Hi,

I'm new to Mender and image building. Thanks for working on this project, it's exactly what I'm looking for!

What I'm trying to do:

- Build my own image/artifact for the Raspberry Pi 3

- Include my own Go binary (hello world http server) into the image/artifact

I'm trying to use Mender the 1.3 Beta (as it seems to be the first release that official supports the Raspberry Pi 3), following the steps outlined here: https://docs.mender.io/1.3/artifacts/building-mender-yocto-image

I'm doing all of this inside of a Ubuntu 16.04 VM (what is the recommended distribution for building mender artifacts?) and running into errors when trying to execute:

$ bitbake-layers add-layer ../meta-mender/meta-mender-raspberrypi/

Note: This step is not part of the 1.3 documentation, but I figured it's the right replacement step to use instead of ../meta-mender/meta-mender-qemu or ../meta-mender/meta-mender-beaglebone .

The full log of what I did and the errors I got can be seen below.

Please let me know what I can try to resolve those errors and build a Raspberry Pi 3 image/artifact.

Cheers

Felix

------------

ubuntu@ubuntu-xenial:~$ git clone -b master git://git.yoctoproject.org/poky

Cloning into 'poky'...

cd poky

remote: Counting objects: 383915, done.

remote: Compressing objects: 100% (92052/92052), done.

remote: Total 383915 (delta 285709), reused 383390 (delta 285184)

Receiving objects: 100% (383915/383915), 137.67 MiB | 4.07 MiB/s, done.

Resolving deltas: 100% (285709/285709), done.

Checking connectivity... done.

ubuntu@ubuntu-xenial:~$ cd poky

ubuntu@ubuntu-xenial:~/poky$ git clone -b master git://github.com/mendersoftware/meta-mender

Cloning into 'meta-mender'...

remote: Counting objects: 5774, done.

remote: Compressing objects: 100% (2/2), done.

remote: Total 5774 (delta 1), reused 0 (delta 0), pack-reused 5772

Receiving objects: 100% (5774/5774), 1.10 MiB | 1.09 MiB/s, done.

Resolving deltas: 100% (3139/3139), done.

Checking connectivity... done.

ubuntu@ubuntu-xenial:~/poky$ source oe-init-build-env

You had no conf/local.conf file. This configuration file has therefore been

created for you with some default values. You may wish to edit it to, for

example, select a different MACHINE (target hardware). See conf/local.conf

for more information as common configuration options are commented.

You had no conf/bblayers.conf file. This configuration file has therefore been

created for you with some default values. To add additional metadata layers

into your configuration please add entries to conf/bblayers.conf.

The Yocto Project has extensive documentation about OE including a reference

manual which can be found at:

    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:

    http://www.openembedded.org/

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:

    core-image-minimal

    core-image-sato

    meta-toolchain

    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

ubuntu@ubuntu-xenial:~/poky/build$ bitbake-layers add-layer ../meta-mender/meta-mender-core

NOTE: Starting bitbake server...

Parsing recipes: 100% |#####################################################################################################################################| Time: 0:00:57

Parsing of 834 .bb files complete (0 cached, 834 parsed). 1298 targets, 43 skipped, 0 masked, 0 errors.

ubuntu@ubuntu-xenial:~/poky/build$ bitbake-layers add-layer ../meta-mender/meta-mender-demo

NOTE: Starting bitbake server...

Parsing recipes: 100% |#####################################################################################################################################| Time: 0:00:39

Parsing of 836 .bb files complete (0 cached, 836 parsed). 1300 targets, 43 skipped, 0 masked, 0 errors.

ubuntu@ubuntu-xenial:~/poky/build$ bitbake-layers add-layer ../meta-mender/meta-mender-raspberrypi/

NOTE: Starting bitbake server...

WARNING: /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb: Exception during build_dependencies for create_shar#######              | ETA:  0:00:04

WARNING: /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb: Error during finalise of /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb

ERROR: ExpansionError during parsing /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb

Traceback (most recent call last):

bb.data_smart.ExpansionError: Failure expanding variable create_shar, expression was # copy in the template shar extractor script

cp /home/ubuntu/poky/meta/files/toolchain-shar-extract.sh /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.sh

rm -f /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/pre_install_command /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/post_install_command

if [ 1 -eq 1 ] ; then

cp /home/ubuntu/poky/meta/files/toolchain-shar-relocate.sh /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/post_install_command

fi

cat << "EOF" >> /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/pre_install_command

EOF

cat << "EOF" >> /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/post_install_command

EOF

sed -i -e '/@SDK_PRE_INSTALL_COMMAND@/r /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/pre_install_command' \

-e '/@SDK_POST_INSTALL_COMMAND@/r /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/temp/post_install_command' \

/home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.sh

# substitute variables

sed -i -e 's#@SDK_ARCH@#x86_64#g' \

-e 's#@SDKPATH@#/opt/poky/2.4+snapshot#g' \

-e 's#@SDKEXTPATH@#~/poky_sdk#g' \

-e 's#@OLDEST_KERNEL@#3.2.0#g' \

-e 's#@REAL_MULTIMACH_TARGET_SYS@#i586-poky-linux#g' \

-e 's#@SDK_TITLE@#${@d.getVar("SDK_TITLE").replace('&', '\&')}#g' \

-e 's#@SDK_VERSION@#2.4+snapshot#g' \

-e '/@SDK_PRE_INSTALL_COMMAND@/d' \

-e '/@SDK_POST_INSTALL_COMMAND@/d' \

-e 's#@SDK_GCC_VER@#${@oe.utils.host_gcc_version(d)}#g' \

/home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.sh

# add execution permission

chmod +x /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.sh

# append the SDK tarball

cat /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.tar.xz >> /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.sh

# delete the old tarball, we don't need it anymore

rm /home/ubuntu/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal-mtdutils/1.0-r0/x86_64-deploy-core-image-minimal-mtdutils-populate-sdk/poky-glibc-x86_64-core-image-minimal-mtdutils-i586-toolchain-2.4+snapshot.tar.xz

 which triggered exception OSError: [Errno 12] Cannot allocate memory

WARNING: /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb: Exception during build_dependencies for create_shar

WARNING: /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb: Error during finalise of /home/ubuntu/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb

Summary: There were 4 WARNING messages shown.

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

ERROR: Parse failure with the specified layer added

[Gregorio Di Stefano]

Hi Felix,

You are using the master branch of poky and meta-mender. Please use the "pyro" branch across all layers.

Thanks,

Greg

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.

[Felix Geisendörfer]

Hi Greg,

thanks for this very quick reply on a Sunday (!)>

> On 19. Nov 2017, at 15:09, 'Gregorio Di Stefano' via Mender List mender.io <men...@lists.mender.io> wrote:
>
> You are using the master branch of poky and meta-mender. Please use the "pyro" branch across all layers.

Ok, that seems to help. But unfortunately I get stuck at the next step (bitbake core-image-base).

All details are below.

Cheers
Felix

-----


ubuntu@ubuntu-xenial:~/poky/build$ bitbake core-image-base
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

MACHINE=raspberrypi is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

ubuntu@ubuntu-xenial:~/poky/build$ cat conf/local.conf
# The name of the disk image and Artifact that will be built.
# This is what the device will report that it is running, and different updates must have different names
# because Mender will skip installation of an Artifact if it is already installed.
MENDER_ARTIFACT_NAME = "release-1"

INHERIT += "mender-full"

# A MACHINE integrated with Mender.
# vexpress-qemu or beaglebone can be used for testing.
MACHINE = "raspberrypi"

# The version of Mender to build. This needs to match an existing recipe in the meta-mender repository.
#
# Given your Yocto Project version, see which versions of Mender you can currently build here:
# https://docs.mender.io/architecture/compatibility#mender-client-and-yocto-project-version
#
# Given a Mender client version, see the corresponding version of the mender-artifact utility:
# https://docs.mender.io/architecture/compatibility#mender-client-and-artifact-format
#
# Note that by default this will select the latest released version of the tools.
# If you need an earlier version, please uncomment the following and set to the
# required version.
#
# PREFERRED_VERSION_pn-mender = "1.1.%"
# PREFERRED_VERSION_pn-mender-artifact = "2.0.%"
# PREFERRED_VERSION_pn-mender-artifact-native = "2.0.%"

# Build for Hosted Mender
# To get your tenant token, log in to https://hosted.mender.io,
# click your email at the top right and then "My organization".
# Remember to remove the meta-mender-demo layer (if you have added it).
# We recommend Mender 1.2.1 and Yocto Project's pyro or later for Hosted Mender.
#
# MENDER_SERVER_URL = "https://hosted.mender.io"
# MENDER_TENANT_TOKEN = "<YOUR-HOSTED-MENDER-TENANT-TOKEN>"

DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""

IMAGE_FSTYPES = "ext4"

KERNEL_IMAGETYPE = "uImage"

MENDER_PARTITION_ALIGNMENT_KB = "4096"
MENDER_BOOT_PART_SIZE_MB = "40"

# raspberrypi files aligned with mender layout requirements
IMAGE_BOOT_FILES_append = " boot.scr u-boot.bin;${SDIMG_KERNELIMAGE}"
IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
IMAGE_FSTYPES_remove += " rpi-sdimg"

#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at local.conf.extended
# which contains other examples of configuration which can be placed in this file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for
# demonstration purposes:
#
#MACHINE ?= "beaglebone"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86"

#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream
# source control systems. This is just mentioned here as an example, its not
# useful to most new users.
# DISTRO ?= "poky-bleeding"

#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
# - 'package_deb' for debian style deb files
# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
# - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to rpm:
PACKAGE_CLASSES ?= "package_rpm"

#
# SDK target architecture
#
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "eclipse-debug" - add Eclipse remote debugging support
# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
# "debug-tweaks" - make an image suitable for development
# e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
# - 'buildstats' collect build statistics
# - 'image-mklibs' to reduce shared library files size for an image
# - 'image-prelink' in order to prelink the filesystem image
# - 'image-swab' to perform host system intrusion detection
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"

#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. To
# enable this uncomment this line. See classes/testimage(-auto).bbclass for
# further details.
#TEST_IMAGE = "1"
#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necesary to monitor /tmp, if there is no space left the build will fail
# with very exotic errors.
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"


#
# Qemu configuration
#
# By default qemu will build with a builtin VNC server where graphical output can be
# seen. The two lines below enable the SDL backend too. By default libsdl-native will
# be built, if you want to use your host's libSDL instead of the minimal libsdl built
# by libsdl-native then uncomment the ASSUME_PROVIDED line below.
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl-native"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"

[Felix Geisendörfer]

Hi,

I think I figured out the problem myself. I was missing the steps below.

Hopefully I can continue on my own from this point!

Once I get this running, would you be interested in pull requests to document the RPI artifact building steps?

Cheers
Felix

ubuntu@ubuntu-xenial:~/poky$ git clone -b pyro git://git.yoctoproject.org/meta-raspberrypi
Cloning into 'meta-raspberrypi'...
remote: Counting objects: 4456, done.
remote: Compressing objects: 100% (1967/1967), done.
remote: Total 4456 (delta 2272), reused 4341 (delta 2193)
Receiving objects: 100% (4456/4456), 1.11 MiB | 344.00 KiB/s, done.
Resolving deltas: 100% (2272/2272), done.
Checking connectivity... done.
ubuntu@ubuntu-xenial:~/poky/build$ bitbake-layers add-layer ../meta-raspberrypi/
ubuntu@ubuntu-xenial:~/poky/build$ bitbake core-image-base

[Gregorio Di Stefano]

Hi again Felix,

You need to add the orignal rpi and open-embedded layers:

https://github.com/agherzan/meta-raspberrypi

https://github.com/openembedded/meta-openembedded/tree/pyro

Thanks,

Greg

[Drew Moseley]

Hi Felix,

To add to Greg's comment, we would love documentation PRs.  Please feel free to submit anything you find.

Drew

To unsubscribe from this group and stop receiving emails from it, send an email to mender+un...@lists.mender.io.

[Eystein Måløy Stenberg]

Felix,

Thanks for the feedback!

I created a docs PR for improving Raspberry Pi here:
https://github.com/mendersoftware/mender-docs/pull/324

Can you please review and add any suggestions there?

--

Eystein

[Felix Geisendörfer]

Hi Eystein,

> On 20. Nov 2017, at 21:37, 'Eystein Måløy Stenberg' via Mender List mender.io <men...@lists.mender.io> wrote:
>
> I created a docs PR for improving Raspberry Pi here: https://github.com/mendersoftware/mender-docs/pull/324
>
> Can you please review and add any suggestions there?

Awesome, thank you so much.

I was able to successfully build my first image, but haven't been able to test it on an actual RPI yet.

I just left an initial comment and will provide more feedback as my testing progresses this week.

Cheers
Felix