Initial startup boot process getting stuck and taking over 24 hours



This is a NEW nano, not related to my previous posts. This is a replacement for my last one.

Just wanted to check and make sure, my nano has been going through the setup process for over 24 hours. Is this normal?

The only thing I’ve done so far is add the nano image to the sd card and plug it in. That’s it.

I made sure to document my process this time.

Video one

Start - 2mins Opening the box

3:28 adding the jetson nano image to the sd card

9:16 Plugging the nano in

21:08 Show prompt with “no limit)” displayed

21:21 Show same prompt but now displayed as “no li it”, missing the “m” and “)”

This is the first instance of Nano getting stuck

Rest of video 1 is just me deciding what to do now that it’s stuck.

Video Two 1:20

First time pressing space bar to unstuck my nano

Video Three

More pressing spacebar to unstuck my nano

Video Four

Update at over 24 hours of setup

Since the initial incident of getting stuck, every hour or so it will get stuck and I will press the spacebar and it will continue to do what it does. Each time the log will get manipulated usually it will go from “no limit)” to “no li it” dropping the “m” and the right parentheses “)”

Here is the latest log:

Is 24 hours too long? And what should I do when we decide it’s been too long, just unplug it and plug it back in?

Thank you

I did not watch all of this. Some comments:

  • The Mac should work fine for using Etcher and creating the SD card.
  • Unless it runs Linux, then the Mac probably is not going to succeed when running JetPack/SDK Manager. A VM will possibly work, but they are problematic.
  • Looking at your last screenshot, everything succeeded up to the point of “first boot user account setup”. It simply is not triggering letting you log in. You would have reached this point much sooner than 24 hours (maybe 20 minutes?), and this is where it fails: It needs to show a login user setup screen. The GUI should have triggered for this.
  • SD card is only part of the install. In this case I don’t think the other part matters, but it might. More on that later.

Alternatively, the serial console should allow first boot setup. Or even just rebooting might trigger going to account setup. Serial console is interactive, and uses your host PC for display (and a Mac works for that, but I don’t know the details of what serial device or program to use), and so it works even when GUI and much of the system fails. Anyone doing any development at all on any Jetson is going to want a serial console UART cable, and they are inexpensive, so that is your next step if simply rebooting it doesn’t result in the prompt going to first boot setup. The UART cable to get is for 3.3V (TTL level), and setting is 115200 8N1. More on that here:

The history on first account setup is that California set up laws preventing shipping many devices with a default user name and password. First boot setup is so that the user sets that up. If it fails, there is a second method which is very reliable. However, that involves the install step I mentioned above which is really the other half of installing.

Most embedded devices, including Jetsons, don’t have an actual BIOS (which would use power and cost more and make it larger). Instead, that content is performed with software, and is part of flash. The SD card is just the operating system partition. Bootloader and the equivalent of BIOS is actually in QSPI memory which is on the module itself. To update QSPI memory one would flash using JetPack/SDK Manager and an Ubuntu 18.04 host PC (amd64/x86_64).

If you were to run JetPack/SDKM (which is a GUI front end to install/flash software), then this would update the QSPI memory. On a non-SD card model there is eMMC, and this would also be how you would flash eMMC on a non-SD card model. There is a utility on the flash software capable of setting up the login name and password. The flash software home location would be at:

Within that is “tools/”. This updates login setup directly to the o/s content before a flash. First boot would already be complete prior to ever booting for the first time. It operates on the content at “Linux_for_Tegra/rootfs/”. If you mount your SD card there, then it will make that update directly to the SD card and you can probably skip flashing the QSPI on the Jetson. You’d plug the SD card in to the host, mount it there, run “sudo ./”, unmount the SD to avoid corruption, and then remove it. Plug it in to the Nano, and boot. It should “just work”.

If not, then you do need to flash the QSPI using JetPack/SDKM. If it gets to that point, then you probably do need a native Ubuntu 18.04 install (probably the Mac works if it is native; many people dual boot).

Just ask if you need more information, but do mention if you have Linux running on the Mac. JetPack/SDKM has limitations on what host flavors of Linux it will run on, but command line typically works on a wider range of hosts, and the script you are interested in just uses command line (actually, flash is less dependent upon flavor of Linux, it is the GUI which is most dependent).

FYI, you SD card will have some particular L4T release (which is Ubuntu plus NVIDIA drivers). This is tied to a particular JetPack/SDKM release, so picking one picks the other. On your Mac can find the L4T release with the first line of the SD card file “/etc/nv_tegra_release”. You can then go here to get to the correct software to use with that release:

  • (
  • You would use the “driver package” and “sample rootfs”. This is the actual flash software without the GUI. You’d unpack the driver package without sudo, as a normal user. Within that is the “Linux_for_Tegra/rootfs/” directory, and you’d go there and unpack the sample rootfs with sudo (you want root user permissions). Then you’d go back to “Linux_for_Tegra/”, and run “sudo ./”. This is the full normal command line setup, and it is set to allow flash from then on via command line.
  • Then you’d mount your SD card partition to “rootfs/”, and from “Linux_for_Tegra/”, run “sudo ./tools/” (you might need to cd to “tools/” and run it there, not sure). Then umount the SD card, and boot again on the Jetson. It’ll probably “just work”.

Once there, things are easiest if you have an Ubuntu 18.04 host PC. Then you can just download and install JetPack/SDK Manager, which in turn downloads and unpacks everything for you. If not, then it isn’t much more difficult to manually unpack just the flash content (without the GUI). I’ve used the flash content on Fedora and several versions of Ubuntu which the GUI would not like (these days I just use Ubuntu). But you do need an actual Linux install, MacOS won’t work. Do you have Linux on the Mac?

I’ll add that almost all of the confusion is because things installed correctly, but without the serial console, you did not see the alternative first account setup. You really should have a serial UART cable (3.3V TTL level) if you want to work with the Jetson, it will make life much easier. Also, in most cases, it is advisable to flash the QSPI anyway right at the start (QSPI content handles several L4T release versions, but if mismatched, things don’t boot correctly; looks like yours did boot correctly, you just lack the GUI).

Incidentally, HDMI monitors can be queried via a wire in the cable such that the monitor tells the GPU what the monitor’s specs are. Sometimes HDMI televisions are a bit quirky in that response. The text output would succeed as it did, but if the monitor had quirks and prevented the GUI, then this might be the reason (and a different monitor might work). With the “” script having been run, you will get past first account setup, but if there are quirks with that monitor (television), then you might still have problems. Serial console logs would answer if that is going on (and would allow first account setup without the monitor, so serial console would have two chances to solve this).

Thanks, I unplugged it and plugged it back in and I was able to successfully login for the first time.

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