Remove or change the password from a Jetson Nano

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

I received a Jetson Nano with a developer kit (B01) and a micro SD card from a previous research project that I want to continue, but unfortunately I didn’t receive the needed password. My question is if there is a way to remove or change the password, so I am able to continue my research with the previous project setup. I am aware that this question was already asked, but the answers were not sufficient for me. I am familiar with Raspberry Pis but not with the Jetson Nano, so I would really appreciate your help.

What I tried:

  1. Since I don’t want to lose the data, I first created a backup of the micro SD card using Win32 Disk Imager, like I would on a Raspberry Pi. Based on the backup and a second micro SD card, I made successfully a copy that I can work on without the risk of losing data.

  2. I tried login in with the two defaults: user: nvidia password: nvidia and user: ubuntu password: ubuntu, but it was unsuccessful. The Ubuntu login screen shows a custom username, so my guess is that the defaults were changed or completely deleted.

  3. Since the Jetson Nano shows a Ubuntu login screen, my initial idea was to remove the password with this guide. Unfortunately, this guide seems not applicable for the Jetson Nano because I didn’t know that it doesn’t use Grub.

What i am working on:

  • I am unsure if there is data on the emmc of the Jetson Nano. Since I don’t want to lose the data, I would like to create a backup of the emmc content.

  • The Jetson is not booting without the micro SD card so my guess is that it boots from it and not from the emmc.

  • Since the guide is not applicable my next idea is to mount the micro SD card on another system and to modify the files regarding the password like passwd by hand.

  • I saw this video about the serial debug console. My guess is that the serial debug console is not password protected. Maybe i could use serial debug console to change or remove the password?

2

FYI, it has been a long time since there was a default name/password. Some time back California law changed, and this instead turned into a first boot account setup.

If you were to try to work with any flash software, then you’d want to work with the same release of L4T which the SD card was designed to match. On a host PC you can use “head -n 1 /etc/nv_tegra_release” to see that release. JetPack/SDK Manager is a front end to flash software, and L4T is what actually gets flashed. L4T, in turn, is just Ubuntu plus NVIDIA drivers. Both the flash software and the image going on the rootfs (in this case SD card) matter even on an SD card model since embedded systems don’t have a BIOS (flash is not just the rootfs and bootloader, it is also the equivalent of flashing the BIOS, but done in software without a hardware BIOS). For an SD card model there is embedded QSPI memory for the non-rootfs content (which is what is flashed) as well as the rootfs (in this case on SD card, which can be worked with separately). To find which software to use when matching that release go to the L4T shown in this URL:
https://developer.nvidia.com/linux-tegra

You will need an Ubuntu 18.04 host PC if you want to use the flash software. VMs are not officially supported and tend to fail if USB is not set up correctly, but can work. In your case it might not matter if all you want to do is set up for flashing a rootfs (which is really just copy to the SD card, you don’t need the Nano connected for that, nor would the Nano be flashed). If the L4T release does not change, then there is no need to flash anything on the Nano.

There isn’t any “cracking” a password, all you can do is install or flash a new image which has not yet completed first boot setup. However, installing that software produces this directory, which is where most command line work would be performed from (you’d use the JetPack/SDK Manager release matching the L4T release…more on JetPack below):
~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/

The L4T page will lead you to the JetPack/SDKM page, but you can use a more recent JetPack/SDKM, and start it like this to make available earlier releases from the newer JetPack/SDKM:
sdkmanager --archivedversions
(JetPack versions available here)

If you have installed the flash software, then JetPack/SDKM will have installed and prepared “Linux_for_Tegra/rootfs/”. You can see if there is content in “Linux_for_Tegra/rootfs/”. When a default image is generated for the rootfs it is almost an exact copy of that content. It is an entire operating system install.

There is a tool located at “Linux_for_Tegra/tools/”. That tools is for people who want to do the equivalent of running first boot account setup prior to ever flashing. If that tool has been used, then the default image will have the chosen details from its very first boot, including login name and password. You can, from “Linux_for_Tegra/”, do this for setting that up:

cd tools
sudo ./l4t_create_default_user.sh
# Follow the instructions. "rootfs/" will be set up accordingly.

There are several choices from here. I’ll suggest:

  • You could create an image based on this, and use it to generate an SD card image.
  • You would then copy (using sudo) files related to login name and password of “rootfs/etc/” over the same files on the SD card image.
  • Files in “/etc” (“rootfs/etc/” on the host PC) which would be relevant (I don’t know if they are all required, but it is best to copy all of them):
    • group
    • group-
    • gshadow
    • gshadow-
    • passwd
    • passwd-
    • shadow
    • shadow-

You won’t find any information on actually cracking a password. All you can get are variations on backing up the original and flashing with a new user setup with physical access. All of the above is a combination of advice on backing up and flashing.

Do note that in JetPack/SDKM you can uncheck items you won’t use. Uncheck everything other than Jetson install. You can also check to install but not perform the flash to get the content.

1 Like
3

“If you were to try to work with any flash software, then you’d want to work with the same release of L4T which the SD card was designed to match. On a host PC you can use “head -n 1* */etc/nv_tegra_release ” to see that release.”

Is there maybe another way to find out the specific L4T/SDK Manager version? Unfortunately, I don’t have access to the host PC that was used and the L4T/SDK Manager version was not documented.
The project was set up by someone else somewhere around July 2020 to July 2021, so I can currently only narrow it down to a 32.X.X version. Would the major version number maybe suffice in that case?

"For an SD card model there is embedded QSPI memory for the non-rootfs content (which is what is flashed) as well as the rootfs (in this case on SD card, which can be worked with separately).
…
There isn’t any “cracking” a password, all you can do is install or flash a new image which has not yet completed first boot setup.
…
You could create an image based on this, and use it to generate an SD card image.
You would then copy (using sudo ) files related to login name and password of “rootfs/etc/ ” over the same files on the SD card image."

I am unsure if i understood this correctly:

On an SD card model, typically the rootfs data is stored on the SD-Card and the non-rootfs data is stored on the onboard memory. The rootfs contains foremost the files that are necessary for booting the system and the operating system. The non-rootfs contains foremost the remaining files that are created by the user.

So what you are suggesting is to use the SDK Manager and the l4t_create_default_user.sh tool to recreate the password related files with a new password on a host system with Ubuntu. Afterwards, I mount the SD card of the Jetson Nano and replace the files on the SD Card with the new recreated files.

Thank you for your great help!

4

If this is an SD card model, then why not just mount the SD card on some other host PC, and look at the etc/nv_tegra_release file on the SD card to see the release? Or consider starting from scratch on a new SD card, while keeping the old one as a reference?

This is correct:

This is the opposite of true:

The SD card with the rootfs (“APP” partition label) contains the operating system and the user’s content. The QSPI memory on the module itself contains “standard” boot content and content equivalent to the BIOS. You can afford to lose everything in QSPI so long as what gets written is a correct version for what the SD card will contain. The SD card is your data, the QSPI embedded memory is essentially firmware and bootloader.

I suggest that if you prepare to flash from an Ubuntu 18.04 PC, then it will create the content which would be used for flash of both SD card and QSPI. You only care about the rootfs (SD card user content and o/s side) content. If the created “Linux_for_Tegra/rootfs/” content has been created correctly (which can be done either manually or via JetPack/SDK Manager GUI front end), and then you run the “Linux_for_Tegra/tools/l4t_create_default_user.sh” (using “sudo”), then that “Linux_for_Tegra/rootfs/” will be updated to already include first boot setup prior to ever flashing. This implies that the PC’s “Linux_for_Tegra/rootfs/etc/” directory contains the exact files you’d need to replace the original SD card’s content with for putting your user with known password into place. If more than one user were created on the original Nano’s SD card, then you wouldn’t get those users, but you would get the original user replaced by your user. This would be a substitute for flashing a new SD card (preferably you would have an SD card duplicated for backup and alter only the backup…easy to do with dd).

1 Like
5

Thank you for the clarification! I understand the Jetson Nano a bit better now :-).

I got myself an Ubuntu 18.04 system, and it mounted the SD card straight away.
Furthermore, I was pleasantly surprised that I was able to access the whole data on the SD card.
Under Windows, one can only access the boot partition of the SD card.

If this is an SD card model, then why not just mount the SD card on some other host PC, and look at the etc/nv_tegra_release file on the SD card to see the release?

The suggestion worked well. I found out that it was the 32.4.4 L4T release.

Thank you again for the great help!

6

Tip: You can use a newer release of sdkmanager and pick R32.4.4 if you start sdkmanager like this:
sdkmanager --archivedversions

You can uncheck various options that might not look initially like they can be unchecked. You can tell it you want R32.4.4, but that you won’t actually flash. This will install the content in:
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/

(plus the “Linux_for_Tegra/tools/” subdirectory I mentioned earlier for “sudo ./l4t_create_default_user.sh” can be run manually by you, and “Linux_for_Tegra/rootfs/” will be set up with your user and password from then on)

7

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