Flashing orin AGX 64 Gbytes from WSL always gets stuck at the OS image creation with the SDK manager

[fdarvas]

I am following the instructions to flash an Orin AGX with SDK manager from WSL2.

https://docs.nvidia.com/sdk-manager/2.0.0/wsl-systems/index.html

I have the USB connected to the Orin and it is visible from WSL - I have changed read/write permissions on the serial device, so it can be accessed by user - I am using a mounted disk on windows to download and create the image.

lsusb shows the device:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

and it exists as /dev/ttyACM0 in the WSL2 system.

The process gets stuck in the “Creating OS image” phase, which proceeds relatively quickly to 65%, but then gets increasingly slower and finally stops at 99% and finally errors out.
Despite setting the ouput to debug, there is no other error message than basically saying “File System and OS - Error” - so its unclear what is actually causing the issue.

[DaveYYY]

@fdarvas

Bus 001 Device 003: ID 0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

7020 means the device is not detected to be in force recovery mode.
Anyway, we don’t really recommend using WSL2 for flashing.

[fdarvas]

There is a whole webpage ( Windows Subsystem for Linux (WSL) — sdk-manager 2.0.0 documentation ) dedicated to this, so it should work?

In any case, the sdkmanager gets stuck before it even tries to flash anything -even though it has created the jetson linux image on the host device for about 5 times now, it still repeats this step everytime, slows down to a crawl at around 90% and then fails.

It is unclear why this fails? There is enough space in this folder and WSL can access it - it actually contains the files for the OS.

[DaveYYY]

Don’t put the BSP in a Windows partition.
It brings a lot of permission issues.

[fdarvas]

No, this wasnt the issue.

The solution for my problem was provided here:

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

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) architectur…

particularly this:

sudo update-binfmts --import qemu-aarch64
sudo update-binfmts --import qemu-arm
sudo update-binfmts --import qemu-armeb

seemed to resolve the issue.

Maybe someone should update the instructions for running this with WSL.

This made it work for me on WSL2

[fdarvas]

after successful flashing the device , it now fails at the installation of the Container runtime with Docker integration.

NVIDIA Container Runtime with Docker integration (Beta) - target: Executing: /lib/systemd/systemd-sysv-install enable docker.

This is curious, as this is running on the flashed device, so I would expect this to just work.

[DaveYYY]

WSL2 only supports flashing the OS itself, but not other SDK components.

[fdarvas]

It looks like the SDK is installed via network? WSL should have no impact there at all?

[DaveYYY]

You can just do

sudo apt update
sudo apt install nvidia-jetpack

on the device.