Hi,
I’m trying to build TorizonCore from a crops container.
mkimage_uboot fails because it cannot load libssl.so.1.1.
Is this a known issue? Any workaround?
NOTE: recipe imx-boot-0.2-r0: task do_compile: Started
ERROR: imx-boot-0.2-r0 do_compile: Execution of '/workdir/torizon/build-torizon/tmp-torizon/work/verdin_imx8mm-tdx-linux/imx-boot/0.2-r0/temp/run.do_compile.10637' failed with exit code 2:
Compiling mkimage_imx8
PLAT=imx8mm HDMI=no
Compiling mkimage_imx8
gcc -O2 -Wall -std=c99 -I /workdir/torizon/build-torizon/tmp-torizon/work/verdin_imx8mm-tdx-linux/imx-boot/0.2-r0/recipe-sysroot-native/usr/include -L /workdir/torizon/build-torizon/tmp-torizon/work/verdin_imx8mm-tdx-linux/imx-boot/0.2-r0/recipe-sysroot-native/usr/lib mkimage_imx8.c -o mkimage_imx8 -lz
./../scripts/pad_image.sh bl31.bin
bl31.bin is padded to 45424
./../scripts/pad_image.sh u-boot-nodtb.bin fsl-imx8mm-verdin.dtb
u-boot-nodtb.bin + fsl-imx8mm-verdin.dtb are padded to 660976
DEK_BLOB_LOAD_ADDR=0x40400000 TEE_LOAD_ADDR=0xbe000000 ATF_LOAD_ADDR=0x00920000 ./mkimage_fit_atf.sh fsl-imx8mm-verdin.dtb > u-boot.its
bl31.bin size:
45424
u-boot-nodtb.bin size:
620120
fsl-imx8mm-verdin.dtb size:
40856
./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb
./mkimage_uboot: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
soc.mak:116: recipe for target 'u-boot.itb' failed
make[1]: *** [u-boot.itb] Error 127
Makefile:19: recipe for target 'flash_evk_emmc_fastboot' failed
make: *** [flash_evk_emmc_fastboot] Error 2
WARNING: exit code 2 from a shell command.
Greetings @klausci,
Yes it seems for the Verdin build requires a newer version of libssl. The container ships with 1.0.0 libssl I believe. Unfortunately, it appears you’ll have to rebuild this container since the default user in this build-container doesn’t have the root permissions to use apt-get. I’ll see about make this easier in the future.
For now you’ll need to copy the container source files from here: GitHub - toradex/torizon-image-build-env: A container image providing an environment to build Torizon
Then in the Dockerfile file you’ll want to add this line: RUN apt-get update && apt-get upgrade openssl libssl-dev -y. It’d be best if you added it right after the USER root line. Like so:
diff --git a/Dockerfile b/Dockerfile
index 75ae512..ae79ebd 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -2,6 +2,7 @@ FROM crops/poky
USER root
+RUN apt-get update && apt-get upgrade openssl libssl-dev -y
# Repo for setup
# JDK for OSTree push
# Vim for convenience
Finally you can build this new container image with: docker build -t (whatever name you want) .
Now this new container image should have libssl.so.1.1.
Please let me know if you have any further difficulties. The Verdin platform is rather new so we haven’t tested it as well on all of our tools like this build container. Any feedback like this is greatly appreciated.
By the way, out of curiosity for what purpose are you trying to build the Torizon yocto image for Verdin here?
Best Regards,
Jeremias
Hi Jeremias,
I rebuild the container as proposed, but when I run it it failed immediately. I didn’t dig deeper. Do you have an idea?
The reason why I’m trying to rebuild torizon is that I want to test OTA updates (via OTA connect). I want to add and remove packages to see if they get deployed on the target.
docker run --rm -it --name=crops -v yocto-workdir:/workdir klausci/crops-toradex --workdir=/workdir --cmd="MACHINE=verdin-imx8mm TARGET=torizon-core-docker startup-tdx-torizon.sh"
Unable to find image 'klausci/crops-toradex:latest' locally
latest: Pulling from klausci/crops-toradex
23884877105a: Already exists
bc38caa0f5b9: Already exists
2910811b6c42: Already exists
36505266dcc6: Already exists
1dcbdf4db0c9: Already exists
c4ace2273299: Already exists
a4fd2de725c3: Already exists
a63ef146c036: Already exists
2e22f90cdefe: Already exists
a2c0849a1f3c: Already exists
e38a8e3e3997: Already exists
5a3aedbc4954: Already exists
974ccc7fba78: Already exists
61f8dc220c12: Pull complete
99758054b9fd: Pull complete
dea3749da922: Pull complete
b8dd6a15602a: Pull complete
d0abdebf4565: Pull complete
Digest: sha256:51594bb9433e51aa08ff56ca872c9de59eb19de0661b9ef8b2494d1064ef0247
Status: Downloaded newer image for klausci/crops-toradex:latest
/usr/bin/poky-launch.sh: line 19: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
It seems the that base crops container image that we base our crops container off of has updated their setup scripts since the last time we built our container.
We’ll have to do some retesting/syncing of the containers on our side.
In the meantime, a colleague shared another workaround with me. Instead of re-building the container you can continue to use our original default build container.
While the default container is running open another terminal to the and run: docker exec -it --user root {container id} bash
This should give you a terminal in the build container itself that has root access allowing you to do the apt-get upgrade process manually. Do note that this change will not be persistent and needs to be done on every new instance of this container. But this is a simple workaround until we can properly fix this.
Sorry for the inconvenience.
Best Regards,
Jeremias
Hi Jeremias,
There seems a problem in your Dockerfile (which appears also if I don’t apply the libssl change).
I made the following changes in Dockerfile and now I can build again. Seems that the autoremove/purge deletes something we need (e.g. python3 seems not to be completely installed). Is it possible that your Dockerfile doesn’t work with the latest crops/poky container?
But good point is: I can now compile mkimage_uboot.
FROM crops/poky
USER root
# Update libssl otherwise ./mkimage_uboot fails
RUN apt-get update && apt-get upgrade openssl libssl-dev -y
# Repo for setup
# JDK for OSTree push
# Vim for convenience
RUN apt-get update && apt-get install --no-install-recommends --no-install-suggests -y repo default-jre
#RUN apt-get update && apt-get install --no-install-recommends --no-install-suggests -y \
# repo \
# default-jre \
# vim-tiny \
# && apt-get autoremove -y \
# && apt-get purge -y --auto-remove \
## && rm -rf /var/lib/apt/lists/*
# Script to automate env setup
COPY startup-tdx-torizon.sh startup-tdx-poky.sh /usr/bin/
RUN chmod 755 \
/usr/bin/startup-tdx-torizon.sh \
/usr/bin/startup-tdx-poky.sh
# JSON file for Toradex Easy Installer server over HTTP
COPY image_list.json /etc/
USER usersetup
Yes I was able to confirm after my own testing that our crops container image has fallen out of sync and with the base crops/poky container image. This will require some internal investigation in order for us to update and continually maintain this, so this issue doesn’t happen again.
For the meantime did you see the comment above? Could you try the docker exec method on our default crops container and try to update libssl that way?
Best Regards,
Jeremias
Hi Jeremias,
sorry, I missed the comment above which describes the workaround for your container. But I stick to my own container, as it works now. Thanks for your help
Glad to hear that, and thank you for your feedback we’re in the process to make sure the crops build container stays continually updated and better maintained across all our modules.
