BSP7: yocto menuconfig doesn't work properly

Hello,

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.

If you need more Information, let me know.

Thanks and regards,
Simon

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

Did you like my answer?

:+1: :-1:


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:

Linux-toradex task fails while compiling using Yocto project.

Seems ok for me (upstream):


And also downstream:


Hello @Fide

It seems you’re using a different version of the BSP, we’re on 7.1.0 devel:

Build Configuration:
BB_VERSION           = "2.9.1"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-tdx-linux"
MACHINE              = "nox-imx8x"
DISTRO               = "nox-devel"
DISTRO_VERSION       = "7.1.0-devel-20241028062734+noxbuild.1"
TUNE_FEATURES        = "aarch64 armv8a crypto"
TARGET_FPU           = ""
meta-freescale       = "scarthgap:0627128b341cfb2bef7a0832ce8cac0ce1127f13"
meta-freescale-3rdparty = "scarthgap:6c063450d464eb2f380443c7d9af1b94ce9b9d75"
meta-freescale-distro = "scarthgap:b9d6a5d9931922558046d230c1f5f4ef6ee72345"
meta-nox             = "scarthgap:0ab91638132756d2b491016ad5fed1ec3310bc59"
meta-filesystems     
meta-gnome           
meta-multimedia      
meta-networking      
meta-oe              
meta-python          = "scarthgap:72018ca1b1a471226917e8246e8bbf9a374ccf97"
meta-swupdate        = "scarthgap:3421a7063a58e4e027130326ab3acccbe3230b30"
meta-toradex-bsp-common = "scarthgap-7.x.y:989ee9326a049d7312f01d6ad09df77cbdbf63f0"
meta-toradex-distro  = "scarthgap-7.x.y:fe1cfe3fbe8c4a0ddc5cfb8ef8b24ff7567ff57f"
meta-toradex-nxp     = "scarthgap-7.x.y:589f0ca4d44945f2b3dc2243a3490479b4aa8ae2"
meta-poky            = "scarthgap:9b6836117e35258aac4f7b1e7c7d10a420fe9370"
meta                 = "scarthgap:5ea3ba00532265165e0d30f6d2eed568f5b5867f"

Further, we use “kas” as our build-frontend for yocto. But imo this should not influcence the behaviour of the menuconfig command.

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.

Hello @kaam1

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:

(too long to paste here)

Hello @SimonG,

I just tested this and it is working in the latest nightly BSP release.
Therefore, it should be something related to your setup.

From your logs, it seems that Yocto is failing to start a valid terminal emulator:

DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "custom"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: No custom terminal (OE_TERMINAL_CUSTOMCMD) set
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "tmux-running"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "tmux-new-window"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "xfce"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "terminology"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "mate"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "konsole"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "gnome"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "xterm"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "urxvt"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "rxvt"
DEBUG: linux-toradex-6.6.23+git-r0 do_menuconfig: Attempting to spawn terminal "tmux"

What distribution are you using?
Is the system headless?

Best Regards,
Bruno

Hello @bruno.tx

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.

Hello @SimonG,

I was able to reproduce the problem by attempting to access menuconfig in a Debian 12 container.

Installing the following package on the container solved the problem:

sudo apt install -y xfce4-terminal

Can you try this in your build container?

Best Regards,
Bruno

Hello @bruno.tx

Thanks for your pointer.

I think I found the right place where to add the dependency: kas/Dockerfile at master · siemens/kas · GitHub (added xfce4-terminal on my local file)

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.

Hello @SimonG,

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.

Best Regards,
Bruno

Hello @bruno.tx

Thanks for your response.

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.

Regards,
Simon

Hello @SimonG,

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.

Best Regards,
Bruno

Hello @SimonG,

Were you able to get this issue resolved, or do you need further support with this?

Best Regards,
Bruno

Hello @bruno.tx

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.

Regards,
Simon

1 Like

Hello @SimonG,

Noted, thanks for the update.

Best Regards,
Bruno

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?

Hello @michael.thenault,

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.

Best Regards,
Bruno

1 Like