Os-release using DISTRO information instead of IMAGE

I am using yocto kirkstone via the Torizon reference image to create an image for my apalis-imx8qm. I am setting some image related information inside of my image recipe, then trying to grab those variables via an os-release.bbappend. After baking, it seems the os-release file is being built prior to the image setting the variables and resulting in the DISTRO information being populated into the os-release file instead of the desired image information. This is my assumption because a custom variable like IMAGE_VERSION is showing as never populated in the resulting os-release file.

Any clue how/why this is happening and how I can fix it ?

layer.conf edits are simple enough:

ACCEPT_FSL_EULA = "1"
DISTRO = "tdx-xwayland-rt"
LICENSE_FLAGS_ACCEPTED="commercial"
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES ?= "package-management"

My image recipe is as follows:
/oe-core/layers/meta-mylayer/recipes-images/images/test-image.bb

# File: test-image.bb

DESCRIPTION = "Custom image based on core-image with PPS and USB tools"
LICENSE = "MIT"

# Define the image name
IMAGE_NAME = "test-image"
SUMMARY = "Test image including tools for PPS and USB"
IMAGE_VERSION = "0.1"

inherit core-image

IMAGE_INSTALL:append = " \
    pps-tools \
    usbutils \
    os-release \
"

IMAGE_FEATURES:append = " \
     debug-tweaks \
     ssh-server-openssh \
"

/oe-core/layers/meta-mylayer/recipes-core/os-release/os-release.bbappend:

# File: os-release.bbappend

# Prevent the creation of sstate cache for this recipe
SSTATE_SKIP_CREATION = "1"

# Set items
NAME="${IMAGE_NAME}"
VERSION="${IMAGE_VERSION}"

# Specify the exact fields desired, no others
OS_RELEASE_FIELDS = " NAME VERSION PRETTY_NAME SUMMARY "

The resulting os-release file looks like this:

NAME="os-release-rt-apalis-imx8-20241013173017"
VERSION="${IMAGE_VERSION}"
PRETTY_NAME="TDX Wayland with XWayland RT ${IMAGE_VERSION}"
SUMMARY="Operating system identification"

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


The issue you’re encountering is likely due to the order in which the variables are being set and used during the build process. The os-release file is being generated before your custom image variables like IMAGE_VERSION are set, which is why they are not appearing in the final os-release file.

Here are a few suggestions to address this issue:

  1. Ensure Variable Expansion: Make sure that the variables are being expanded correctly. You can try using := instead of = for immediate variable expansion in your os-release.bbappend file. This forces the variable to be expanded at the time of assignment.

    NAME:="${IMAGE_NAME}"
    VERSION:="${IMAGE_VERSION}"
    
  2. Check the Order of Execution: The os-release file might be getting generated before your image recipe is fully processed. You can try to ensure that your os-release.bbappend is processed after your image recipe by using dependencies or by adjusting the order of operations.

  3. Use BitBake Debugging: Use BitBake’s debugging tools to check the order of operations and see when the os-release file is being generated. You can use bitbake -e <recipe> to inspect the environment and see the values of variables at different stages.

  4. Custom Task: If the above methods do not work, consider creating a custom task in your image recipe that modifies the os-release file after it has been initially created. This task can be set to run after the do_rootfs task.

  5. Check for Conflicts: Ensure there are no other layers or recipes that might be overriding your settings for os-release.

By ensuring the correct order of operations and variable expansion, you should be able to get your custom variables into the os-release file.

Please, also check if these links can help you solve your problem:

Apalix IMX8QM/Ixora V1.2 random reset.

Greetings @chipbrommer,

Just to understand, your issue is that IMAGE_VERSION is not being populated in the final os-release file correct?

From what you’ve shown me, I wouldn’t expect it to be populated either. So you set IMAGE_VERSION in your test-image.bb recipe. You then set VERSION="${IMAGE_VERSION}" in a bbappend. How would the bbappend have access to the value of IMAGE_VERSION set in a completely different bb file?

Unless it’s a special variable in the Yocto build system then the scope of the variable is local to the file you set it in. If you want a custom variable to have a more global scope then you want to define it in something like your local.conf or machine.conf or the distro.conf. Variables defined in these higher level configuration files would then be globally available to all bb/bbappend files.

Best Regards,
Jeremias

Just checking-in, are you still having any issues related to this topic?

Best Regards,
Jeremias

Hi @chipbrommer,

Were you able to resolve this issue?

I apologize for the lack of reply.
This makes perfect sense and I understand where I am in error.

I will try some alternative methods to achieve my goal. I’d like to not need to keep the variables defined in a higher level file so that I can have different versions captured in the os-release recipe for different images.

Well if you don’t want to set a new variable with a global/extended scope. Then your options are either to set the value directly in os-release.bbappend. That way the variable scope wouldn’t be an issue. Though now your defining your version in os-release which you may not want.

The other option is to make use of existing variables in Yocto that already have an extended scope. For example. In the original os-release.bb recipe VERSION is set to ${DISTRO_VERSION}: os-release.bb « os-release « recipes-core « meta - poky - Poky Build Tool and Metadata

Therefore if you set DISTRO_VERSION which has an expanded scope already, then you don’t need to even append os-release. In fact this is what we do in our meta-layers at Toradex: tdx-base.inc « include « distro « conf - meta-toradex-distro.git - Toradex distribution layer

This is how we get our /etc/os-release file to look like this:

ID=torizon
NAME="TorizonCore"
VERSION="6.8.0-devel-20240927+build.668 (kirkstone)"
VERSION_ID=6.8.0-devel-20240927-build.668
...

Just some ideas, for you to consider.

Best Regards,
Jeremias