Jetson AGX Orin developer kit stuck in initial setup after reflash


I’m having an issue with initial setup not completing.

I flashed the orin I have access to with Jetpack 5.0.2 via the SDK manager running on a desktop tower booted into ubuntu 20.04.5 via a full ubuntu install on a USB3 drive.

It makes it through the flashing process but gets stuck in initial setup. I go through the steps but after the last step it just hangs for ever with a spinney cursor. If I reboot it it just goes back to the start of initial setup.

I’m installing to the internal eMMC storage.
Something about a test key flashes up briefly during boot, picture attached.
There there appear to be a few errors in some of the logs exported from the SDK manager. I’ve attached those logs as well as a minicom log from the debug port minicom running on the host.

Any help would be much appreciated.
Thanks in advance,

minicom1815.cap (148.5 KB)
sdkm-2023-03-08-17-43-33.log (653.3 KB)

Hi rowan.gates,

Are you using the devkit from NVIDIA or custom board for AGX Orin?

22:01:34.828 - info: NV_L4T_FLASH_ORIN_WITH_OS_IMAGE_COMP@JETSON_AGX_ORIN_TARGETS: *** The target t186ref has been flashed successfully. ***

From your SDKM log, it seems flash successfully.

[   41.104620] Please complete system configuration setup on desktop to proceed...

From your serial log, it seems you are in the oem-config (System configuration) step. You should finish the configuration(name, password ,timezone…etc) for your board.

Do you mean that your host PC is from a USB3 drive of Ubuntu 20.04.5?

Hi Kevin,
Thanks for the quick response.

Are you using the devkit from NVIDIA or custom board for AGX Orin?

It is indeed an NVIDIA dev kit.

You should finish the configuration(name, password ,timezone…etc) for your board.

That’s the problem. When I go through that process after the last continue it just gets stuck with a blank desktop and a spinning cursor. I’ve tried leaving it for several hours and it just stays in that state. Rebooting puts it back at the start of the configuration step

Do you mean that your host PC is from a USB3 drive of Ubuntu 20.04.5?

Yes, is was the easiest option to create with the hardware I had immediately available.

Hi rowan,

I am a fellow jetson agx orin user having the same problem. nvidia jetson support sucks BIG TIME and nobody cares. They even dare to call something they are having a factory reset, which at the end is a SIMILAR to factory reset and they don’t even CARE.

had they cared for support for their product, they would have transfer this to github/gitlub and let end user complete the job, which they left unfinished

I’m having exactly same problem here after upgrade with apt-get dist-upgrade.
Then when reboot showings this problem.

Does anyone know how to solve the problem?

Have you tried to flash the board with flash script (

You could download the BSP package from Jetson Linux R35.1.
Or just use the BSP package from downloaded directory of SDK Manager.

Then, you could refer Skipping oem-config to skip system configuration.
If your board still could not boot up into desktop, please provide the serial console log for further check.

I have not tried that yet.
I’ll give it a shot and update this with the result.

I’ve tried using the package and filesystem mentioned but I’m having issued getting it to the point where the imaging process could be done. I get issues with invalid file names during extraction and the skipping oem config steps fail as it can’t find a license it’s expecting.

I’m going to try using an image acquired by the SDK manager next. I’ll add another reply when I know the results of that. Maybe I’m doing something wrong in the process.

Behaviour is consistent with the archive acquired via sdkmanager.

This is what I’m getting following the initial steps for image creation on Quick Start — Jetson Linux<br/>Developer Guide 34.1 documentation
quickstart errors (330.5 KB)

And this is the error I get trying to run the script mentioned in skipping oem-config.
create defualt user error (737 Bytes)

It has occurred to me that it could be a drive issue. Going to reformat it to make sure it’s EXT4 and attempt again tomorrow.

I’ve now had success with the sdkmanager imaging targetting both 5.1.1 and 5.1. I believe the issue was the format of the storage device being used for the download and image creation. I can’t remember what I originally had it set to but when I accidentally formatted it as NTFS it failed a lot earlier. EXT4 was the format which succeeded for me.

The other possibility would be a couple of updates which occurred to SDK manager but given the issues I was having with the script side of things that seems unlikely.
It may be worth having the SDK manager verify the format of the partition of the image creation directory as a means of failing early with meaningful feedback.

Yes, the disk should be formatted as EXT4 first.
Thanks for your trial and sharing.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.