Sdkmanager fails with chroot: failed to run command 'dpkg': Exec format error

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

greetings,

i’m trying to update my tx2. i’m running sdkmanager --query interactive, not the gui version. the relevant lines from the log are these:

info: ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_TX2_TARGETS/Linux_for_Tegra/rootfs ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_TX2_TARGETS/Linux_for_Tegra
info: Installing BSP Debian packages in ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_TX2_TARGETS/Linux_for_Tegra/rootfs
error: chroot: failed to run command 'dpkg': Exec format error

i tracked this down to this script ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_TX2_TARGETS/Linux_for_Tegra/nv_tegra/nv-apply-debs.sh where it runs this:

echo "Installing BSP Debian packages in ${L4T_ROOTFS_DIR}"
if [ "${#pre_deb_list[@]}" -ne 0 ]; then
   LC_ALL=C PYTHONHASHSEED=0 chroot . dpkg -i --path-include="/usr/share/doc/*" "${pre_deb_list[@]}"
fi
LC_ALL=C PYTHONHASHSEED=0 chroot . dpkg -i --path-include="/usr/share/doc/*" "${deb_list[@]}"

i checked ${L4T_ROOTFS_DIR}, and indeed file usr/bin/dpkg says:

usr/bin/dpkg: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0,.....

which of course will fail on an amd64 system. what’s going on here?

3

d’oh, seems binfmt support is missing in my setup

4

you may also check Command-Line Install :: NVIDIA SDK Manager Documentation for reference

5

“Exec format error” means you are running the command on the wrong architecture. Are you running this on a Jetson? If so, can’t be done.

You’d need to run this on a standard Ubuntu host PC (x86_64/amd64) for most of flash, but the twist in the story is that on the PC it might be running a subset of its commands in QEMU for aarch64/arm64. For example, the package seems to be aarch64, so running directly on the host PC without QEMU would also result in exec format error. You could be correct about missing a package, but the package, if related to adding an aarch64 package from a PC, would use a tool from within QEMU. Not sure why QEMU would be missing such a tool, but a failure in bringing up QEMU could result in attempting to install the aarch64 package without being in QEMU.

6 
│info: [ NV_L4T_FILE_SYSTEM_AND_OS_T194_COMP Install took 1m45s ]         │
│                                                                         ││error: [error]: : [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FILE_SYST │
│                                                                         ││EM_AND_OS_T194_COMP.sh; [error]: chroot: failed to run command 'dpkg':   │
│                                                                         ││Exec format error

output from trying docker sdkmanager flashing
any ideas?

sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

trying the above
UPD seems the cause was missed binutils package at Host OS
But it still doesn’t resolve the issue
UPD after again installing qemu static seems the issue got passed

1 Like
7

Regardless of the environment being run in (docker, QEMU, native, so on) we know that the actual dpkg command must be designed for that environment. We also know the package itself must be designed for that version of dpkg. During the apply_binaries.sh step, if running natively, then the commands for dpkg must be from the sample rootfs content under QEMU. If we add docker, then docker must run QEMU to run dpkg to install the arm64/aarch64 package. If any of this fails it might revert to trying to run the wrong architecture. Each container must have everything it needs, and I don’t know which one is missing what, and that means identifying each “parent” container as having everything the “child” container requires.