I’m new to all this so please bear with me.
I’m trying to flash a Jetson TX2 device with 4.4.1.
The last few days I’ve tried probably all combinations, booting from usb drive on plain Ubuntu 18 LTS, etc. After many failed trials I found this:
https://docs.nvidia.com/sdk-manager/docker-containers/index.html
which to my undestanding is the ULTIMATE way to get a controlled environment in which sdkmanager can be run, without the risk of any interference from the host, missing dependencies, misconfiguration, errors in the procedure, etc.
Well, it FAILS.
At the begining I was constantly blaming myself, it has to be this, or that, endlessly, but when I found this I thought I won the lottery, a self contained environment where NVIDIA engineers have the last word in everything, no more host or environment miseries, well, again, not the case.
As far as I know, there’s no chance of failure under docker if everything is properly defined, I wonder then how this could be happening. The whole idea is to execute those few steps and be ready to go.
As seen in the pic the error is when it tries to exec
'dpkg': Exec format error
that smells to me as an attempt to run a binary that is meant to ARM in X86 or viceversa, but again, isn’t that the magic inside the docker image should fix all that? For instance qemu or whatever should be used to flash a device?
Environment and procedure:
Environment to BUILD the container ONLY: Ubuntu 18 LTS VirtualBox VM
Note: I know that VMs don’t get well with flashing BUT at this stage I’m only trying to build the container (basically download everything and then commit the container and NOT actually flashing even though):
Procedure:
$ docker load -i sdkmanager-1.4.0.7363_docker.tar.gz
$ docker tag sdkmanager:1.4.0.7363 sdkmanager:latest
$ docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb/ --name JetPack_TX2_Devkit sdkmanager --cli install --logintype devzone --product Jetson --target P3310-1000 --targetos Linux --version 4.4.1 --select 'Jetson OS' --deselect 'Jetson SDK Components' --license accept --staylogin true --datacollection enable
Results:
One thing that is maybe relevant is that the log says that QEMU bin was not present (isn’t it supposed to be provided in the dockerfile as one of many dependencies?). It finally tries and installs it from the host (Ubuntu 18 LTS), see details:
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
So, I’m puzzled here. I’m not sure what to do to be honest, this official docker image was my silver bullet after so many failures.
What am I doing wrong?
Thanks in advance!!
