I’m not to that step yet - just trying to get fw_printenv working reliably for the integration checklist.
An update here - I can get fw_printenv to work, but I need to manually comment out the second line (the u-boot environment redundant location I think?).
I don’t see either of these cases: “Unfortunately, because of the great variation in U-Boot board code, the automatic patching process does not always succeed or produce a working boot loader, even if the above criteria are met. The symptoms are either that one of the u-boot recipes produce compile errors, or that the board does not boot using the modified bootloader. If this happens, or if you are using an older Yocto Project branch, there will be some manual work required in order to produce a working integration patch.”
I don’t get a compile error, and the board does boot, but I’m starting to wonder if it’s not booting with the modified u-boot. For example, further in the integration checklist is the step of setting it to boot off the alternate partition:
However, when I inspect my u-boot environment variables with fw_printenv, I don’t see any mender_ contents!
Does this mean something already went wrong?
Yes, I think this would be a clear indication that Mender was not integrated properly.
Can you tell me following things:
Which yocto release are you using?
Which layers do you have configured in you bblayers.conf? Please verify that all necessary yocto layers (for your board and mender) are included
Is there anything useful in mender logs? You can check them by running journalctl | grep mender*
Which imx8 board are you using? (What’s the value of your MACHINE variable?)
If the issue was wrong fw_env.config only - there would be a quick (but not pretty) workaround for it: manually adding fw_env.config using a bbappend file. But in your case the issue seems to go deeper.
Some startup stuff, but this looks good to me as I think the issue to fix first is u-boot related:
Aug 23 18:14:14 xxx mender-client-resize-data-part[339]: Disk has already been resized.
Aug 23 18:14:16 xxx systemd[1]: Mender persistent data dir was skipped because of a failed condition check (ConditionPathExists=!/data/mender).
Aug 23 18:16:17 xxx mender[1174]: time=“2024-08-23T18:16:17+02:00” level=info msg=“Loaded configuration file: /var/lib/mender/mender.conf”
Aug 23 18:16:17 xxx mender[1174]: time=“2024-08-23T18:16:17+02:00” level=info msg=“Loaded configuration file: /etc/mender/mender.conf”
Aug 23 18:16:17 xxx mender[1174]: time=“2024-08-23T18:16:17+02:00” level=info msg=“‘UpdateControlMapExpirationTimeSeconds’ is not set in the Mender configuration file. Falling back to the default of 2*UpdatePollIntervalSeconds”
Aug 23 18:16:17 xxx mender[1174]: time=“2024-08-23T18:16:17+02:00” level=info msg=“‘UpdateControlMapBootExpirationTimeSeconds’ is not set in the Mender configuration file. Falling back to the default of 600 seconds”
Aug 23 18:16:19 xxx mender[1174]: time=“2024-08-23T18:16:19+02:00” level=info msg=“Mender running on partition: /dev/mmcblk0p2”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=info msg=“State transition: init [none] → init [none]”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=info msg=“State transition: init [none] → idle [Idle]”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=info msg=“State transition: idle [Idle] → check-wait [Idle]”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=info msg=“State transition: check-wait [Idle] → inventory-update [Sync]”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=info msg=“Output (stderr) from command "/usr/share/mender/inventory/mender-inventory-geo": /usr/share/mender/inventory/mender-inventory-geo: Unable to get IP info from ipinfo.io”
Aug 23 18:16:21 xxx mender[1174]: time=“2024-08-23T18:16:21+02:00” level=warning msg=“Inventory tool /usr/share/mender/inventory/mender-inventory-geo wait failed: exit status 2”
Aug 23 18:16:24 xxx mender[1174]: time=“2024-08-23T18:16:24+02:00” level=info msg=“Device unauthorized; attempting reauthorization”
Do you think I should start tackling the manual u-boot integration based on the fact that there is no mender_ stuff in my u-boot environment? I was hoping to avoid it so it’s more future-proofed against Yocto and Mender updates.
builder@f54f8a31e876:/build$ bitbake -e u-boot-imx | grep --ignore-case “EXTERNALSRC”
# $EXTERNALSRC
# [doc] “If externalsrc.bbclass is inherited, this variable points to the source tree, which is outside of the OpenEmbedded build system.”
# $EXTERNALSRC_BUILD
# [doc] “If externalsrc.bbclass is inherited, this variable points to the directory in which the recipe’s source code is built, which is outside of the OpenEmbedded build system.”
if [ -n “${EXTERNALSRC}” ]; then
bbwarn “Skipping U-Boot auto-configuration when >EXTERNALSRC is set. Would change the source files. If you need the patch, turn off EXTERNALSRC, call ‘bitbake -c save_mender_auto_configured_patch u-boot’ to generate a patch, and then apply that to your work tree and reenable EXTERNALSRC.”
# e.g. using externalsrc; use S as base for our dirs
# debugsources.list may be polluted from the host if we used externalsrc,
# Same check as above for externalsrc
builder@f54f8a31e876:/build$
To be honest I’ve never used kas before - and am not a big fan of it - but I believe your issue will require some deeper digging into Yocto which might not be possible with kas.
Second, I see you have a long list of layers in your bblayers.conf. I’d suggest first making a build with only necessary layers required (mender, bsp and poky related layers). After you set up the most simple build, and get Mender to work on it, I’d suggest adding more stuff to it. This way not only does the build finish faster, but debugging it is easier and it’s more clear what’s going on.
What Mender layers should I be including?
I believe meta-mender-core is sufficient in your case.
Do you think I should start tackling the manual u-boot integration based on the fact that there is no mender_ stuff in my u-boot environment?
That’s exactly what I would do next.
Lastly, I want to point out that the board you’re using has not been tested with Mender before. (source) Because of it, integrating Mender on it could be more difficult than it seems. Sorry I couldn’t be of more help.
The manual u-boot integration steps don’t talk about how to add the mender_* variables - is it expected those are already present in the automatically generated patch? What if they are not, as is my case?
