Errors in File system andOS

Hi Henry,

There seems to be host environment issue. To further check, you could try either of the following methods

  1. Flash device on a different host.
  2. Or manually flash device according to L4T | NVIDIA Developer and https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/quick_start.html#

What do you see from “uname -m -p -v” on the host PC? The exec format error is very strong evidence of using the software from one architecture on the other.

That’s definitely an ordinary host PC. I can’t guarantee it, but I am thinking that the “exec format error” (which is a very important error) was an attempt to run arm64 on x86_64, the reverse of what I thought it was originally. However, the only way this would happen is if something were wrong with the host PC’s QEMU.

During a flash the Jetson is in recovery mode originally, and the flash does not use packages…everything is just binary data at that stage. Then, as the flash completes, the Jetson will reboot. The error I am thinking of is how the host PC prepares the Jetson’s rootfs image to flash…the flash is just binary data, but preparation of the rootfs uses QEMU. This is the only time the host PC uses any arm64 software.

Basically the rootfs is generated “mostly” from the content of the host PC’s “Linux_for_Tegra/rootfs/”. That content is originally created by unpacking a generic Ubuntu distribution with no NVIDIA files. Then the drivers and other software specific to the Jetson are added to customize for the Xavier. It is during the customizing that the host PC uses the arm64 version of dpkg via QEMU. The only thing I can think of is that for some reason QEMU has not run and the dpkg of arm64 is somehow being used without QEMU. Don’t know for sure, but is there anything unusual about your host PC’s JetPack/SDKM install? On your host PC what do you see from:Incidentally,
dpkg -l | grep -i qemu

I’d also have to agree with what @EdwardZhou mentions, that something is strange on the host PC. The above concentrates on QEMU, but it could be almost anything and testing from another host PC, or else completely removing JetPack/SDKM and reinstalling it, would be the next step.

First of all, thank you for your help. Now I have used other computers to finish the machine, and I have been groping for that host for a month. Many people have helped me, but they could not solve it. I have to put that aside because of the progress of the project.