Hi, I have difficulties trying to prepare an image for my Jetson Orin Nano development kit using the NVidia SDK Manager.
I am running a host ubuntu 20.04 machine set up using WSL 2, and have installed the SDK Manager on there. When trying to create the image, I get the following failure: chroot: failed to run command ‘dpkg’: Exec format error. Also see the sdkm terminal log below. I have seen numerous similar forum posts showing the same error (e.g here) and have tried suggestions made there, but I still did not succeed in getting it to work on my system.
I had WSL Ubuntu 20.04 and SDKmanager setup on a different computer (no longer available to me) last week and that was working without issues, so I now it could work. I cannot find out what is keeping it from working now.
Any help is appreciated.
SDK Manager terminal log:
info: Start L4T BSP package installation
info: QEMU binary is not available, looking for QEMU from host system
info: Found /usr/bin/qemu-aarch64-static
info: Installing QEMU binary in rootfs
info: /home/hj/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/rootfs /home/hj/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
info: Installing BSP Debian packages in /home/hj/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/rootfs
error: chroot: failed to run command 'dpkg': Exec format error
info: [ Package Install Finished with Error ]
info: [host] [ 4.80 GB used. Disk Avail: 734.33 GB ]
info: [ NV_L4T_FILE_SYSTEM_AND_OS_COMP Install took 1m48s ]
info:
error: command terminated with error
info: Installation failed.
WSL2 won’t work anyway if you need to generate an image during flash. You’d still have to add a new kernel supporting loopback.
Do you have access on command line such that you can find “which dpkg”? Most likely (at least on actual Linux) this would be “/usr/bin/dpkg”. Then check this output (adjust for file path): file /usr/bin/dpkg
It should be ELF 64-bit, x86-64. If it is running within QEMU, then it will instead be 64-bit ARM, ARM aarch64. Should the emulator itself fail to exec, and the ARM dpkg runs without the emulator, then I would expect the exec format error.
I do want to emphasize though that WSL2 does not support loopback unless you change the kernel (which might not be trivial). Even when a VM supports everything (e.g., vmware), you will find a lot of USB issues if you have not correctly configured full ownership of the USB device by the VM. Dual boot with an actual Ubuntu (for Orin, Ubuntu 20 is best) would save you a lot of headaches if you plan to develop for an Orin.
Thanks for the replies. Running which dpkg indeed shows /usr/bin/dpkg and file /usr/bin/dpkg indeed shows a 64-bit ELF for x86-64. Unfortunately, re-installing qemu-user-static did not work, but I found out that running sudo update-binfmts --install qemu-aarch64 /usr/bin/qemu-aarch64-static --magic '\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7' --mask '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff' makes qemu-aarch64 appear when showing ls /proc/sys/fs/binfmt_misc/`. Furthermore, it brings me further down the installation (nv-apply-debs.sh). But now, later in the process, I encounter:
Processing triggers for nvidia-l4t-kernel (5.10.120-tegra-35.4.1-20230801124926) ...
Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
/usr/sbin/ldconfig: 16: exec: /sbin/ldconfig.real: Exec format error
/usr/sbin/ldconfig: 16: exec: /sbin/ldconfig.real: Exec format error
dpkg: error processing package libc-bin (--install):
installed libc-bin package post-installation script subprocess returned error exit status 2
Errors were encountered while processing:
libc-bin
This again seems to be an architecture related issue. Could anyone help me with this?
Your ldconfig (the linker, and everything in its environment…basically a complete user space operating system) has to exist and be arm64/aarch64, not desktop PC format. I’m guessing that if you use “file /sbin/ldconfig.real” it’ll say something other than a 64-bit ARM. All of those files for linking and for libraries are known as the “sysroot”, and you need everything that a program might (A) link to, or (B) use to perform linking to be present in native (to the emulated environment) architecture. Tools themselves are cross-arch, and run on a PC, but output and understand 64-bit ARM, so those are not an issue. Emulators do not install everything though because that would imply installing not just one full operating system, but every library and every option possible on every flavor and version of Linux.
If you have a Jetson set up already with everything you need, and you clone the rootfs, then you can loopback mount the raw clone and name this as the sysroot. You’d have exactly everything available that the Jetson has, and in the exact release version as on the Jetson (hint: update before clone, and add any dev packages even if you are not developing directly on the Jetson).
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/sys/fs/binfmt_misc/ ).
I tried the solution from H-Jay but got stuck in his same error. I then found that update-binfmts is designed to import the correct binary formats.
While these ascii formats showed up in my /usr/share/binfmts, such as qemu-aarch64, qemu-arm and qemu-armeb, I used the update-binfmts tool to properly import these formats:
I don’t know if the last two are really needed (I suppose not) but after this action the issue mentioned by H-Jay is solved and chroot works as a charm :)
Hope this helps others too.