We’re facing an issue with the new BSP7 on the Colibri IMX8X: When attempting to start the menuconfig in the yocto shell for the kernel (bitbake -c menuconfig virtual/kernel) the ncurses-window opens quickly but then just quits immediately, without an error message.
When I start the devshell (bitbake -c devshell virtual/kernel) I am able to run the menuconfig. However, diffconfig (bitbake -c menuconfig virtual/kernel) doesn’t work this way, generating the .cfg must be done manually.
I think this might be an upstream bug of the downstream linux-toradex recipes, because for u-boot for example it works. It also works on the IMX6ULL (for both linux+u-boot), which uses the upstream kernel.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, the issue with the BSP7 on the Colibri IMX8X where the menuconfig command fails to function properly in the Yocto shell is acknowledged. The ncurses window opens briefly and then quits without displaying any error messages. A temporary workaround is to run the menuconfig command from the devshell using bitbake -c devshell virtual/kernel, which allows it to function correctly. However, this does not resolve the issue with the diffconfig command, which requires manual generation of the .cfg file.
The potential cause of this issue is suspected to be an upstream bug in the downstream linux-toradex recipes, as similar functionality works correctly for U-Boot and on the IMX6ULL platform, which uses the upstream kernel. This suggests a possible regression or compatibility issue introduced in the BSP7 implementation for the Colibri IMX8X.
Further investigation or a patch may be required to resolve this issue. If additional information or assistance is needed, it is recommended to reach out for further support.
Please, also check if these links can help you solve your problem:
Hi, one possible reason for this failure is that the terminal window might not be large enough. Try running the command in a maximized window. Also, how is the variable OE_TERMINAL set? If it’s set to tmux or tmux-new-window, then tmux and its dependencies must be installed.
Thanks for your hints. I tried to run it again with a full-screen terminal, same result. But as I mentioned above, the “normal” menuconfig works fine when run inside the devshell.
I’m not sure how to output the OE_TERMINAL variable, but here’s the full output of the command bitbake -c menuconfig virtual/kernel -v -D, if that helps:
We use Linux Mint 21, the system is not headless (access via RDP and using the XFCE Terminal). I think kas uses a container with debian 12 for the build.
But I’m not sure if my change is picked up correctly (I’m not familiar with docker, I just use the kas-container build/shell ... command), I think I need to force it to redownload/install(?) the docker image somehow with the new settings.
Unfortunately, I am not too familiar with KAS.
However, in general, when working with Docker containers, you would follow the following workflow (simplified):
Edit the Dockerfile
Build the container
Run the container
Therefore, if you can somehow rebuild the container with the new Dockerfile, and run the new container, this would be the way to go here.
It could also be possible to add the package in a running container, by installing it manually.
However, I don’t know if the KAS environment has some limitations on this.
I think I found out how to run+modify a container image directly (docker run -dt ghcr.io/siemens/kas/kas:4.5 && docker ps && docker exec -it <id> sudo apt install xfce4-terminal), but unfortunately xfce4-terminal is not available for installation. Probably because “bookworm-slim” doesn’t conatain some packages?
I’m however not sure this is the issue, because as I mentioned, when run from inside the yocto kernel devshell, the menuconfig works. It also works directly when run for virtual/bootloader.
In this case, I think it is more likely that the container simply does not have the apt package list.
It is good practice to remove it after installing packages on Dockerfiles.
To solve it, you can just run sudo apt update before the sudo apt install ....
However, running the container with docker run -dt ghcr.io/siemens/kas/kas:4.5 will not grant the necessary access to the local filesystem.
I would recommend that you look into what tools KAS gives you to customize the build container.
I have not looked into this topic any further yet, because it has not a high priority for us (we use the workaround descriped above). I might repost here later in case I’m able to resolve the problem.
Hello,
I’ve got the same issue with a almalinux container and the same log output posted before.
Installing xfce4-terminal in the container changes nothing and I don’t really understand why it would. Did you start the container in a way that allow gui apps to start ? If yes how?
Yes, I used distrobox in my testing with a Debian 12 container.
Maybe it is worth trying it as it sets up what is needed for graphical applications to start.
