Issue when booting up nvidia jetson tx2


I upgraded my nvidia jetson tx2 from ubuntu 16.04 to 18.04. When I tried to reboot, the system stops at “Started User Manager for UID 124”. What can I do about this?

Thank you!

Did you upgrade through JetPack/SDK Manager? If you used the Ubuntu mechanism, then you will have to flash again since Ubuntu does not have valid knowledge of booting custom embedded systems.

When I first accessed the desktop GUI it said update from ubuntu 16.04 to ubuntu 18.04. So I clicked accept, I’m guessing this is the ubuntu mechanism you were talking about.I did not use SDK manager/JetPack. What do you mean by flash again?

Hello Dlee8,
Upgrading Ubuntu on Jetson TX2 through UI is not recommended. It is recommended to update your Jetson TX2 device through SDK Manager to get the latest Ubuntu OS and Nvidia Components. Have a look at the below link and Documents in the link to flash your Jetson TX2 board.

The URL for the most recent JetPack/SDK Manager (you may need to go there, log in, and then click the URL again if redirect does not work):

The mechanism you chose is the Ubuntu mechanism and is the reason for the failure. It would be nearly impossible to save this without extreme effort. You could clone if you have something you need to save, but it sounds like you just turned this on fresh. This also means the version you are using was probably very old and you would have ended up flashing anyway.

Flashing is a complete replacement of the operating system with a fresh install. You install the JetPack/SDKM “.deb” on your host Ubuntu PC, and with the Jetson in recovery mode and connected to the host PC via the micro-B USB cable, you run “sdkm”. You can pick at that point to only flash, or you can pick to add software to the host PC, or you can do all of the above (the menus do not make it obvious that you can pick). Be sure to have an HDMI monitor on the Jetson during the flash so you can complete the first boot creation of an account.

I recommend flashing only without adding any software, and then running SDKM a second time later for extra package installs. When adding packages you do not use recovery mode (holding down the recovery button while powering up or cycling power puts the Jetson in recovery mode); instead, packages are added via ssh (and the micro-B USB when normally booted can provide a virtual wired ethernet for this) on a fully booted system.

I tried to flash the image on TX2 also using SDK manager on a Linux host machine. but failed with some error.

So I restarted Jeston TX2. Now it get stuck at the same error:
“Started User Manager for UID 124”
does it mean it’s still in the recovery mode?
how to resolve this?

How to fix the issue when host machine cannot install the image on tx2?

Is the hard drive on the host PC using an ext4 filesystem type? If the type is VFAT or NTFS or anything else, then I would expect the flash content to be invalid. You can check via:

df -H -T /where/ever/it/is/at/Linux_for_Tegra/

The error is from an attempt to boot normally and is unrelated to recovery mode. I suspect the flash worked, but the content being flashed may not be valid.

The file system of the host PC is xfs.

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):

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?


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).

Further discussion moved to this thread: