Jetson TX2 Stuck in Restart after installing Ubuntu 18.04

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi
I have a Jetson TX2 which I got a few years back but only just powered up, when I did it hoped up to install Ubuntu 18.04 which I click yes to. It downloaded and installed it then said restart, which I clicked yes to.
It ran through the various restart commands and is now stuck at Tuning already done, restoring best tap value: 21
How can I fix this?

2

See if that link helps for installing JetPack?

3

Thanks but I can’t get to anything, desktop or command line where I can install anything from.

Do you know of a way I can just wipe everything and start again?

4

TX2 Force Recovery Mode

Starting with the device powered off:

  1. Press and hold down the Force Recovery button.
  2. Press and hold down the Power button.
  3. Release the Power button, then release the Force Recovery button.
5

Ok so when I do that the green led’s come on but I get nothing on the screen.

6

That would put the Jetson into recovery mode, which is when you can connect the micro-B USB to an Ubuntu 18.04 host PC and run the flash software (the host PC is what performs the flash). FYI, if you “upgraded” from Ubuntu 16.04 (very old) to 18.04 via the Ubuntu mechanism, and not via the JetPack/SDK Manager tool, then it would have caused the failure since the Ubuntu mechanism from those older days have no understanding of a Jetson’s boot requirements.

Some useful URLs:

7

So is it recoverable?
Can I use the mico usb connector with a usb drive, as I don’t have another pc running ubuntu?
Or the sd card on the Jetson?

8

Excuse my total lack of knowledge around Ubuntu and jetpack. How would I do this can do it from a virtual machine on my Mac book?

9

As far as I know you need another PC.

10

A system which fails to boot would need to be cloned. You would use the clone to have access to files/directories via loopback mount of the raw clone image. You would still have to flash the unit (and erase it), but you’d have a reference of your old files.

Although VMs are not officially supported, if you can get an Ubuntu 18.04 VM working on the Mac, and if you can force the recovery mode USB device to always pass through to the VM regardless of how often it disconnects and reconnects, then you can probably use that VM. Beware though that you will probably need your VM to have a lot of spare disk space before you start, perhaps 40 or 50GB. You’ll also need to be prepared for this to take a long time.

It is correct that you need a PC running Ubuntu 18.04 for this to work since the driver for the custom USB device (a recovery mode Jetson is a custom USB device) runs on a PC.

When you install SDK Manager on the host PC and run it, there should be a directory named like this:
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/

Any command line use would be from the “Linux_for_Tegra/” directory. A typical clone (assuming the Jetson is in recovery mode and the micro-B USB cable is connected) would be:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

This would produce “my_backup.img” (a sparse file), and “my _backup.img.raw” (a raw file). I throw away the smaller sparse file as it is basically useful only for flashing. The larger raw file can be loopback mounted, examined, edited, copied, or used for flashing. If you want to know more about cloning or using a raw clone file just ask.

11

Ok thank you that’s really helpful. I’ll see if can get that working.

12

Thanks again for the help, I have Ubuntu 18.04 up and running on an old Macbook Air. and have downloaded jetpack sdk manager, then downloaded and installed the jetpack version for the jetson tx 2.
So if I now want to restore my Jetson tx2, i do the following.

  1. connect my laptop to the Jetson via the micro usb port
  2. use terminal on the laptop to navigate to the Linux_for_Tegra/ folder
  3. Power up the Jetson in recovery mode
  4. run sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1 on the laptop.

That sound about right?

13

I would slightly change this command:

…I would suggest making sure the non-rootfs content is synced to the rootfs content:

  1. Make sure your JetPack/SDKM release is an exact match to the one which originally flashed your cloned rootfs.
  2. Copy my_backup.img.raw (or just “my_backup.img” if you didn’t edit) to:
    Linux_for_Tegra/rootfs/system.img
  3. sudo ./flash.sh -r jetson-tx2 mmcblk0p1
    (note that if your cloned image is not the default size you might need to use the “-S size” option to get partitions to fit together properly)

The time added by flashing everything instead of just the rootfs is trivial…by far the only significant time is for flashing the rootfs. Each rootfs has strong dependencies to the non-rootfs partitions (during boot), and if the other content is not a match, then boot will probably fail.

14

Thank you.
As I have not used the Jetson tx2 for any work there are no files I need to save, will this change the process at all?

15

Thanks to your help I have managed to flash the Jetson Tx2 from the sdk manager on my laptop. I know boots up fine with ubuntu.
However when the sdk manager tried to install all the sdk components such as CUDA, it failed to find the usb connection which it had used to flash the Jetson moments before.
So I thoughts that OK I can download the sky manager on the Jetson, however that doesn’t want to install.
Any suggestions?

16

During flash the Jetson is in recovery mode and becomes a custom USB device understood only by the driver package. Only the base o/s is installed in that flash. When flash completes the Jetson reboots and becomes a fully booted Ubuntu instead of recovery mode. This is when those optional packages (such as CUDA) are installed, and this requires ssh login to work.

A freshly flashed system has no user name/pass, and upon first boot it is expected that the user will complete the first boot setup instructions (which are known to fail to be seen sometimes). It is the user name/pass just created which is used for the install of those components over ssh. No name/pass implies no ssh login and failed component install. Lack of access to the network would have a similar failure.

Did you complete the first boot setup with a locally attached keyboard/mouse, or serial console? If so, then you will be able to log in locally to the Jetson, or even ssh from that Jetson to the “localhost” and verify ssh works (localhost implies the machine is logging in to itself, but that is a valid test for whether ssh credentials work).

If you can log in with ssh locally, but not from a remote computer, this implies a network configuration issue. While logged in to your Ubuntu host PC you should be able to:
ping 192.168.55.1

That ping address is provided by the micro-B USB of a fully booted Jetson. A fully booted Jetson provides a virtual wired ethernet over USB (compared to a recovery mode Jetson which is just a custom device and not a normal computer). If you can ping 192.168.55.1, but cannot log in via either a login directly on the Jetson or otherwise, then it implies network is correct, but account setup is wrong.

On your host PC, do you see anything from this command?
ifconfig | grep -i '192.168.55

When you have both network and login for ssh set up it should be ok to install CUDA.

Note: It isn’t always obvious, but you can run SDKM at any time and uncheck flash and uncheck host PC content and just check adding of packages. You don’t use recovery mode if you are just adding packages, and you can do this at any time, not just during a flash.

17

Ok so completed the set up procedure and set a username and password for the Jetson, but I can’t ping the Jetson from my laptop so I guess there is an issue there.
Could it be some sort of security that is set up automatically?

18

if the usb is not working can I do it via wifi?

19

You can use WiFi or wired from the ethernet jack. WiFi does take some manual setup in most cases, but if you have this up and running, then at the location where it by default names address “192.168.55.1” you can substitute your other network device.

Before you do I suggest this test: Fully boot the Jetson without the micro-B USB cable. In your host PC run the command “dmesg --follow” so it continuously tells you new log entries. Then connect the micro-B USB cable. See what it says as a result. If it doesn’t show enabled from there or “ifconfig” after the cable is plugged in you could (if you want to see if this was just a setup issue) run “sudo nm-connection-editor” (“sudo apt-get install network-manager-gnome”) and find that MAC address (the log will show it) and enable. My bet is that your host PC simply did not enable this by default. Other methods might be more convenient right now, but in the future you will probably be interested in flashing again.