Xavier Boot Failure

I tried to flash and boot my xavier. In the flash, it is flashed successfully. When the host try to boot the device, the xavier shows :"/bin/sh cannot access tty, control job stopped" Does anyone know how to fix this problem?

The network at first, I connect my host machine (ubuntu 18 not VM) to device with USB cable.
After the reboot problem, I cannot detect the usb port as well.
So the host machine shows “Connection to time out.”

Then stuck and failed.

If anyone knows how to deal with issue, I am more than grateful!


I’d first make sure your host had enough disk space. What do you see from:

df -H -T /where/ever/you/flashed/from

The flash steps require recovery mode and do not care about network addresses on the Xavier itself. JetPack can optionally add packages…either without flash or preceded by flash. If flash occurs, then Xavier reboots prior to package additions; if flash does not occur, then the Xavier should not be put in recovery mode.

JetPack offers several ways to connect. One of the details is if the host PC will act as a router, or if you have a dedicated router appliance. One option which is new for Xavier (and which I have never tried) is to use the network gadget over USB to be the network device. Look closely at the steps for selecting how you wish to connect to the Xavier prior to any flash or package install steps. The address corresponds to the USB gadget network mode.

What was your specific setup?

Hi @linuxdev,

Thanks for the reply.
I use ubuntu18 as the host machine. JetPack-L4T-4.1.1
I have checked the “df -H -T /where/ever/you/flashed/from” The space is enough for the job.
I use the USB cable come with the Developer Kit to link the host and the Xavier.

This is the information when booting the Xavier.

This is the information on the host machine

Thanks again.

The host is Ubuntu, but I want to verify that the partition the flash software ran on is ext4 and not something else. If that is correct, then I’d say something went wrong that a log might give information on. You can hover your mouse over the quote icon in the upper right of one of your existing posts and a paper clip icon will show up…you can attach files via that paper clip.

If you have a JetPack flash log please attach that. If not, then the driver package will already be in place due to running JetPack (JetPack is a front end to the driver package and it is the driver package which creates the “Linux_for_Tegra/” subdirectory), and I can tell you how to log while flashing on command line without using JetPack. In your case the host not finding the IP is because the Xavier never rebooted correctly after the flash (something went wrong during flash).

Hi @linuxdev, thanks for the reply.
I have checked the partition the flash software ran on is ext4.
For the current test, I only got two log files. I will attach the files.
target_setup_progress_galen.log (22 Bytes)
flash_os_galen.log (2.26 MB)

So the good news is that flash ran as expected and looks 100% correct. You can rule out a flash failure as the cause. This also tests a good part of the Jetson, e.g., you know the eMMC is working.

When we go back to this:

"/bin/sh cannot access tty, control job stopped"

…it now implies we are probably looking at a problem in the “rootfs/” subdirectory to the “Linux_for_Tegra/” driver package content (in the case of JetPack it downloads those packages for you).

Most of the differences which might occur at this stage are related to how the software in the “rootfs/” subdirectory is unpacked, and whether the application of the NVIDIA binaries is done with or without “sudo”. JetPack takes care of this and knows to ask for passwords, but must be initially run only by non-sudo.

Can I verify if this was flashed via JetPack, or if instead it was flashed on command line? This will lead to finding out where it went wrong.

One test you can do prior to knowing this is to see if the permissions of the “sudo” binary are correct. From your flash location, if you cd from the “Linux_for_Tegra/” directory into “rootfs/usr/bin/”, what do you get via:

ls -l sudo