I have the problem, that i can create my image properly on my machine. I created a git-repo where i pushed the files. And on my machine that repo builds a proper image with the same size as the original.
However if i clone it to another machine, the resulting image is smaller, and doesnt seem to have the same functionality (Libraries are missing)
I added some shared libraries into the changes1 filesystem, that i cannot copy.
Is there a way i can transfer the shared libraries?
If i use ldconfig -n -v /usr/lib then i get the error that points me to the fact that the libraries are for ARM where the laptop has AMD processor.
any help, hint or pointer is appreciated.
I really need to recreate the same image also on other machines, as the current machine will not be available anymore in a while.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
It sounds like you’re encountering issues with building a TorizonCore image on a different machine, resulting in a smaller image with missing libraries. This can often be due to differences in the build environment or missing dependencies on the new machine. Here are some steps to help you resolve this:
Verify File Paths and Permissions: Ensure that the paths to the shared libraries in your changes1/ directory are correct and that the files have the appropriate permissions to be read and included during the build process.
Consistent Build Environment: Differences in the build environment can lead to inconsistencies. Consider using a containerized environment to build your image, which can help ensure that all dependencies and tools are consistent across different machines.
Cross-Compilation: Since you’re dealing with ARM libraries on an AMD processor, ensure that your build process is set up for cross-compilation. This might involve using tools like QEMU to emulate the ARM architecture on your AMD machine.
Check Dependencies: Make sure that all dependencies required by your shared libraries are also included in the changes1/ directory or are available in the base image.
Use TorizonCore Builder Commands: Utilize the TorizonCore Builder commands to verify and debug the inclusion of files. The tcbuild.yaml file should be carefully checked to ensure all paths and configurations are correct.
By following these steps, you should be able to replicate the image build process on different machines successfully. If issues persist, reviewing the build logs for any errors or warnings might provide further insights.
Best regards, Toradex AI Assistant.
Please, also check if these links can help you solve your problem:
As additional information:
i am compiling everything on WSL2 on my machine.
I also tried to wsl --export Ubuntu ./Ubuntu_image.tar
and then on another machine wsl --import Ubuntu ~/AppData/Local/Ubuntu_Image_folder ./Ubuntu_image.tar --version 2
however the resulting image was even smaller. I have not yet tested it, but am assuming it might have similar problems.
Thank you for contacting us.
I have a few questions concerning your previously stated issue, so we can better understand what you are dealing with.
How are you deploying your image?
How exactly are you checking the sizes of your images?
What sizes are the images / how large is the difference?
What specific tcb version is being used on either machine?
Is torizon core builder being sourced in the right directory on the machine creating a faulty image?
Is there a difference between the SHA256sum of the correct build and the faulty one in the following sections?:
the input image images/torizon-core-docker-apalis-imx8-Tezi_5.7.0+build.17.tar
the changes1
the kernel_Mod
the location of the device-trees: which commit is checked out on both sides? Are any modifications being done? (git status / git diff )?
the B.png
As a more general question I want to ask you for the specific reason for adding shared libraries to rootfs in your case in order for us to understand why having the libraries in the containers themselves does not suffice.
We are building it using torizoncore-builder build and deploying on the apalis using easy_installer
the sizes are just the values from the file explorer.
Difference is somewhere between 12-7Mb
i updated everytime to the newest version, so version 3 i guess
i pressed y on prompt and both machines were connected to the web
There definitly are differences, which makes sense, as the links in shared libraries are usually not copied or committed.
As to your other question, this might be the answer to my question.
What do you mean?
I need libraries to add functionality for the WLAN, and mobile chip:
I think I might have a hunch as to what the culprit to the issue is. My suspicion is that when copying the files, potential symbolic links are not copied as such. It could be as direct directories and/or files, or even completely neglected.
Just to be absolutely certain about the sizes: Have you checked via properties for the exact size. I am asking just to be certain that the file explorer is not messing things up for us. I do obviously not expect this, but since this issue is strange I want to be certain. Please also share the exact sizes of your final images.
To get the tcb version you can enter torizoncore-builder --version
To find out if this is indeed the case I want to ask you to please do the following steps and share them with us:
finding differences in sizes inside your tcb file:
1.1 Share the SHA256 of the image on both sides/machines
1.2 archive changes1 via tar cf name.tar directory, followed by creating the SHA256 with sha256sum ./name.tar Do this on both machines and share/compare the SHA256 result.
1.3 Do step 1.2 for kernel_Mod as well.
1.4 Do step 1.2 for B.png as well.
1.5 check the hash of all the devicetrees with git --no-pager log -1 --online and compare them
checking the use of links in all altered and generated directories.
2.1 use ls -la inside the changes1 directory on both machines. This will show if either of them is using links (whilst the other is potentially not).
2.2 Are the libraries inside the changes1 directory only used by your application itself?
With these steps we will get some more insight into the differences and we should be able to see if my suspicions are indeed true.
