Flasing TX2 using SDK manager on Ubuntu 18.04 x86 host get error

vic420 · February 19, 2020, 1:45pm

Hello

I have host machine with SDK manager installed:

x86 Ubuntu 18.04

The TX2 is in recovery mode and connected to the host machine via the micro USB cable from the development kit.
There is an external SSD drive on TX2.

When tried to select flashing the Jetson OS on TX2 and JetPack 4.3 is selected, I got below error:

14:42:34 INFO : File System and OS : /home/benny/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/nv_tegra/nv-apply-debs.sh
14:42:34 INFO : File System and OS : Root file system directory is /home/benny/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/rootfs
14:42:34 INFO : File System and OS : Copying public debian packages to rootfs
14:42:35 INFO : File System and OS : Start L4T BSP package installation
14:42:35 INFO : File System and OS : QEMU binary is not available, looking for QEMU from host system
14:42:35 INFO : File System and OS : Found /usr/bin/qemu-aarch64-static
14:42:35 INFO : File System and OS : Installing QEMU binary in rootfs
14:42:35 INFO : File System and OS : Installing Jetson OTA server key in rootfs
14:42:35 INFO : File System and OS : ~/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/rootfs ~/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra
14:42:35 INFO : File System and OS : Registering Jetson OTA server key
14:42:35 ERROR : File System and OS : chroot: failed to run command ‘mount’: Exec format error
14:42:35 INFO : File System and OS : exit status 126
14:42:35 INFO : File System and OS : [ Package Install Finished with Error ]
14:42:35 INFO : File System and OS : [ 8.00 KB used. Disk Avail: 34.37 GB ]
14:42:35 INFO : File System and OS : [ NV_L4T_FILE_SYSTEM_AND_OS_T186_COMP Install took 2m28s ]
14:42:35 ERROR : File System and OS : Run commands failed at step Install: command /tmp/tmp_NV_L4T_FILE_SYSTEM_AND_OS_T186_COMP.sh finished with error
14:42:35 INFO : File System and OS :
14:42:35 ERROR : File System and OS : command terminated with error
14:42:36 ERROR : File System and OS : install ‘File System and OS’ failure, command < cd ‘/home/benny/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310’ ; ‘/opt/nvidia/sdkmanager/resources/app/output/installUtils/adapter’ -a=‘install’ -c='eyJpZCI6Ik5WX0w0VF9GSUxFX1NZU1RFTV9BTkRfT…

any help?

dpdani · February 19, 2020, 2:22pm

Experiencing the same issue here, with the exact same error output.

Have tried to figure out where the error comes from, but with no luck so far.

linuxdev · February 19, 2020, 5:24pm

I see a QEMU note. Is the host PC a regular system, or is there some sort of emulation/VM involved?

vic420 · February 20, 2020, 8:41am

The host PC is a regular system. there are no VM involved. Host PC file system is xfs it this information matters.

This host PC can successfully cross compile jetson Xavier using Night eclipse edition.

But met error when flashing TX2.

So I don’t think it’s the host PC’s problem.

What are the exact requirements for a host machine to run SDK manager successfully? ( Why nvidia is so limited to a specific OS)

linuxdev · February 20, 2020, 2:57pm

XFS should work since this has no issue with Linux file permissions.

Sometimes a dependency shows up as an issue, so you might try this and then check again for flash:

sudo apt update
sudo apt --fix-broken install
sudo apt-get install libgconf-2-4 libcanberra-gtk-module
sudo apt-get install python

Because of these log lines:

14:42:35 INFO : File System and OS : QEMU binary is not available, looking for QEMU from host system
14:42:35 INFO : File System and OS : Found /usr/bin/qemu-aarch64-static
14:42:35 INFO : File System and OS : Installing QEMU binary in rootfs

…I am thinking that this is related to setting up the sample rootfs via QEMU, and that your host PC may have some sort of temporary route failure to correctly adding a QEMU dependency. Are you behind any sort of firewall or proxy?

In theory QEMU would act as a kind of adapter between architectures, but if you are unable to get the correct QEMU setup, then this would occur:

14:42:35 ERROR : File System and OS : chroot: failed to run command 'mount': Exec format error

(this is an attempt to run one architecture on another architecture which isn’t compatible, and dealing with this is the purpose of QEMU)

vic420 · February 21, 2020, 12:30pm

Hi

Thanks for your help. I have tried to execute the commands:

xxx$ sudo apt-get install libgconf-2-4 libcanberra-gtk-module
[sudo] password for xxx: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libcanberra-gtk-module is already the newest version (0.30-6ubuntu1).
libcanberra-gtk-module set to manually installed.
libgconf-2-4 is already the newest version (3.2.6-5ubuntu1).
libgconf-2-4 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
xxxx$ sudo apt-get install python
Reading package lists... Done
Building dependency tree       
Reading state information... Done
python is already the newest version (2.7.16-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Looks like all packages are ok.

Both host PC and Jetson TX2 are connected to the same local network. no proxy or firewall is involved in this case.

vic420 · February 21, 2020, 12:31pm

I moved your comments to other thread here:

If possible we should continue this on the original thread, but I’ll reply here since not all of the information is in the other thread (it is difficult to track across multiple threads):
https://devtalk.nvidia.com/default/topic/1071827/jetson-tx2/flasing-tx2-using-sdk-manager-on-ubuntu-18-04-x86-host-get-error/

XFS should be ok. The reason why VFAT and NTFS fail is that they do not preserve Linux file system permissions/IDs. Even so, this confuses me, but I have an idea on this:
Started User Manager for UID 124
Every user has a numeric ID. Normally a log will refer to the name for that ID instead of the numeric ID. A similar scheme exists for group ID (which non-Linux filesystems cannot work with), and often (but not in this case) seeing numeric user or group ID implies the filesystem type is incorrect (it is hard to match a numeric ID to a named ID if the numeric ID is just a default for a missing ID). At least on R32.1 this ID belongs to user “dhcpd” (system IDs typically do not change unless there is a major version release change, and even then system IDs are often unchanged across releases).

Do you still have this file available on the host PC?
Linux_for_Tegra/bootloader/system.img.raw
If so, what is the exact byte size of this file? If this file exists, can you loopback mount this and see content?
cd /where/ever/it/is/Linux_for_Tegra/bootloader/
# This is to validate if the image size is correct, should be an even multiple of 1024 twice (MiB) or three times (GiB):
ls -l system.img.raw
# Next see if the image is mountable, and if so, find the specific user belonging to ID 124:
sudo mount -o loop system.img.raw /mnt
# Save a copy of this file for use without loopback mounting:
cp /mnt/etc/passwd ../passwd.txt
sudo umount /mnt
cd ..
# Find the specific user for ID 124 (probably "dhcpd"):
grep 'x[:]124[:] passwd.txt
The above mainly checks if the image is correctly generated. This image is what should be on eMMC, and if user ID 124 exists correctly on the image, then there is a strong chance that the image was corrupt during its copy to the Jetson (the Jetson would be missing the “/etc/passwd” file despite the intended image having this file).

vic420 · February 21, 2020, 12:38pm

I noticed file system.img.raw is not present under bootload folder.
any way to fix this?

one more question, the TX2 uses a differnet password than the default. does it make any differences?

vic420 · February 21, 2020, 12:57pm

Did try to flash the Jetson Xavier too, but got the same error.

I will do a fresh installation of ubuntu 18.04 one the host PC.
Feels like the issue was somehow on the existing OS on the host.

linuxdev · February 21, 2020, 6:42pm

FYI, there is no default user name/pass anymore (older releases had default name/pass). You must set this in the first boot after the flash, so best practice is to attach an HDMI monitor and a keyboard during the flash.

You will want to run a manual command line flash and then examine system.img.raw again if you still get the UID 124 error. Setting up for manual command line flash may already be complete since you ran SDK Manager, so check if there is content in the “Linux_for_Tegra/rootfs/” subdirectory. This should contain an entire operating system, and it must be on a native Linux filesystem type (you can use ext4 or XFS there, but VFAT and NTFS would fail). If this is present, then put the Jetson in recovery mode with the micro-B USB connected, and run this command:

sudo ./flash.sh jetson-tx2 mmcblk0p1

…though I recommend logging instead, where the following logs without big progress bar content in the log:

sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt

(file “log.txt” can be attached to one of your forum posts)

Once you flash the “bootloader/system.img.raw” should exist. If not, then something went wrong. The file should have an exact byte size divisible twice by 1024 (MiB) or three times by 1024 (GiB). Knowing if this size is correct would help determine if an image is truncated.

You should probably check your free hard disk space before beginning to see that you have lots of spare space:

df -H -T /where/ever/it/is/Linux_for_tegra/

A log of the command line flash would help if this still boots incorrectly.

Note that the “Linux_for_Tegra/” content is also called the “driver package”, and is there because JetPack/SDKM downloaded and installed this. The “rootfs/” content is another package, the “sample root filesystem”.

Ignore What Follows If You Already Have Content In “rootfs/”…

It doesn’t hurt to repeat this step, but really you only need what follows to be set up once.

If the “Linux_for_Tegra/rootfs/” folder does not have an entire operating system in it, and is perhaps just a README file, then you may need to populate this manually. JetPack4.3 corresponds to L4T R32.3.1 (JetPack is a front end for the other tools). If your SDKM already downloaded the sample rootfs it will be at:

~/Downloads/nvidia/sdkm_downloads/Tegra_Linux_Sample-Root-Filesystem_R32.3.1_aarch64.tbz2

If you do not have “rootfs/” content and do not have “Tegra_Linux_Sample-Root-Filesystem_R32.3.1_aarch64.tbz2”, then go to the L4T URL here (you will probably have to go there, then log in, and go there a second time since redirect does not work):
https://developer.nvidia.com/embedded/linux-tegra
…from there you can download the “Sample Root Filesystem”.

To set up the rootfs manually:

cd /where/ever/it/is/Linux_for_Tegra/rootfs/
sudo tar xvfj /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R32.3.1_aarch64.tbz2
cd ..
sudo ./apply_binaries.sh

(now you can run flash.sh as instructed above and look for the “bootloader/system.img.raw” file size)

vic420 · February 22, 2020, 7:03pm

Thank you very much for your help.

I have reinstalled fresh Ubuntu 18.04 on host PC and tried to flash both Jetson TX2 and Xavier, no errors!

Most likely the host PC system is the issue here.
So some tips for others who meet this issue are:

alwasy use Ubuntu 18.04 for host PC, if not, try to refresh.
make sure both target jetson hardware and host PC are in the same network, without firewall or proxy
make sure correct USB-type-C port on Xavier is used for debugging.( Xavier has two USB-type-C ports and I have noticed that only one should be used for flashing) - need to read the manual more carefully.