SDK Manager fails to create Jetpack 6 OS image

[sleff]

I’m getting the following error when trying to create Jetpack 6.0 (Rev 1) Linux for Jetson AGX Orin Modules:

03:18:26 INFO: File System and OS - target_image: Start L4T BSP package installation
03:18:26 INFO: File System and OS - target_image: QEMU binary is not available, looking for QEMU from host system
03:18:26 INFO: File System and OS - target_image: Found /usr/bin/qemu-aarch64-static
03:18:26 INFO: File System and OS - target_image: Installing QEMU binary in rootfs
03:18:26 INFO: File System and OS - target_image: /home/nvidia/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/rootfs /home/nvidia/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra
03:18:26 INFO: File System and OS - target_image: Installing BSP Debian packages in /home/nvidia/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/rootfs
03:18:26 INFO: File System and OS - target_image: chroot: failed to run command 'dpkg': Exec format error
03:18:26 ERROR: File System and OS - target_image: [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FILE_SYSTEM_AND_OS_COMP..sh; [error]: chroot: failed to run command 'dpkg': Exec format error
03:18:26 INFO: File System and OS - target_image: [ Package Install Finished with Error ]
03:18:26 INFO: File System and OS - target_image: [host] [ 5.90 GB used. Disk Avail on Partition overlay: 845.71 GB ]
03:18:26 INFO: File System and OS - target_image: [ NV_L4T_FILE_SYSTEM_AND_OS_COMP Install took 59s ]
03:18:26 ERROR: File System and OS - target_image: command terminated with error
03:18:26 SUMMARY: File System and OS - target_image: First Error: Installation failed.

Details

I’m running sdkmanager inside a Docker container based on Ubuntu 22.04. The host PC is running Ubuntu 24.04.

My problem is very similar to this thread, which indicates that using Docker container from host PC running Ubuntu 23.10 works flawlessly, but Fedora 39 failed.

SDK Manager fails to create Jetpack 6 image

It would be interesting to hear back on any flavor of Linux distribution you try with when it fails or succeeds. I used to work only on Fedora, and command line tends to work on a lot of distros, but JetPack 6 adds some new flexibility. It’s going to be interesting to see what people get to work with that.

So to continue the previous thread, I can report that Ubuntu 24.04 does not work.

I have been running sdkmanager inside Docker containers for Jetson and DRIVE SDK versions that require Ubuntu 18.04, 20.04, and 22.04 from host PCs up to 22.04 without any problem.

It would be great to find a fix for this, since Ubuntu 24.04 is a natural progression for many users.

[DaveYYY]

Does this trick help?

Orin nano installation fails; chroot: failed to run command ‘dpkg’: Exec format error

Hi, I had the same horror while using WSL2. First of all; NVidia should support WSL2 because they created a dedicated info page on it and I believe the latest sdkmanager was build to support WSL2. I tried to debug what was going on by manually running all the scripts and found out that chroot was not working correctly; thus issues with qemu. On my WSL I installed the qemu-system full emulation binaries packages. However, they did not pop up in binfmt_misc (as should be when running ls /proc/s…

[sleff]

That link did not help.

However, I think I have found the solution, to the problem that is very similar to the other thread I linked to in my original post. The original solution from @linuxdev is partially correct, and partially misleading.

The original error is this line:

03:18:26 INFO: File System and OS - target_image: chroot: failed to run command 'dpkg': Exec format error

This means that the command ‘dpkg’ is an aarch64 linux binary, and the system is trying to run it as x64_64. So it is related to qemu.

SDKManager will apt-get install qemu-user-static, which contains qemu-aarch64-static binary. However, on Ubuntu 24.04 host, it doesn’t configure binfmts.

Inside docker container, update-binfmts --display shows that qemu-aarch64 is disabled:

qemu-aarch64 (disabled):
     package = qemu-user-static
        type = magic
      offset = 0
       magic = \x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00
        mask = \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
 interpreter = /usr/libexec/qemu-binfmt/aarch64-binfmt-P
    detector = 

So, we enable qemu-aarch64 as follows:

 sudo update-binfmts --enable qemu-aarch64

Now, update-binfmts --display shows that qemu-aarch64 is enabled.

Now the File System and OS will use qemu-aarch64-static binary to run the dpkg aarch64 and other commands.

The original solution from @linuxdev incorrectly states to install qemu-user-static on the host machine, and reported segmentation faults on host machines with certain flavours of Linux distributions. There seems to be some incompatible combinations of having qemu installed on both the docker host Linux distribution and container.

If you have an incompatible qemu installed on the docker host, you will get this warning:

$ sudo update-binfmts --enable qemu-aarch64
update-binfmts: warning: qemu-aarch64 already enabled in kernel.

Simply, do NOT install qemu-user-static on the host machine, and it will work. The update-binfmts command will produce no output, and no warning, which is good.

Summary:

sudo apt update
sudo apt install qemu-user-static
update-binfmts --display
sudo update-binfmts --enable qemu-aarch64
sdkmanager 

I think SDKManager could be improved/fixed by checking update-binfmts, and enabling qemu-aarch64 for the user. Additionally, it should catch the warning if qemu-aarch64 is already enabled in the host, and provide a friendly warning that it might be incompatible with the container qemu.

[DaveYYY]

Oh, glad you solved it!
I think this is what excatly this guide mentions, but maybe not a lof of people notice it:
https://docs.nvidia.com/sdk-manager/docker-containers/index.html#known-issues