Jetson TX2 sudo password recovery

Recovery mode will not reset or alter a password. The reason this is used is for reinstalling the operating system (or cloning it).

On Ubuntu the root user is locked without a password, so I’m assuming you mean the admin user’s password when running “sudo” commands.

You can reinstall the entire operating system, and there is essentially no other way. However, what you reinstall can be a clone of what was originally there (it is a good idea to have a clone as a backup anyway if it is valuable). Sadly, this takes a lot of disk space and time since we are dealing with files in the neighborhood of 30GB (more if you consider other temporary files…you’d probably want at least 40GB of free space on the host PC).

If you choose to clone and restore via edited clone (with the password fixed), then instructions may change depending on which L4T release this is (if we know which JetPack/SDK Manager was used previously, then we’ll know the L4T version).

Actually, on Ubuntu x86-64, you can enter single user / recovery mode (root) from Grub without a password and reset any user’s password (or clone /etc/shadow or whatever, you have root). A good reason to encrypt your root filesystem. A bios password won’t protect. Somebody can just change some jumpers, push a button, or yank the battery and wait 10 seconds or so.

On Xavier cloning, editing, and restoring is probably your best bet as @linuxdev suggests. As to actually figuring out what the password was… it’s easier to reset.

Hi

I do not have x86-64 I do have aarch64 And as far I do understand, according to [linuxdev] is not possible to recover my sudo password.

Definitely I would like to recover my sudo password rather than flash the JetsonTX2 again.

Hi,

Yes it is not the root password but the admin user’s password when running “sudo”

After running the command: $cat /etc/lsb-release I get:
# R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018

And I assumed that I do have:

JetPack 3.3 L4T R28.2.1 (TX2/TX2i) Right?

Well I do have 28 GB internal memory,

Since I can not recover the sudo pasword other than re install everything, Can I reinstall or flash the JetsonTX2 respecting the /home/nvidia directory.

I do not want to clone it, because I do not have enough space.

Just wondering why in x86-64 is possible to recover the sudo password and not in Jetson

Thank you

Hi.

After reading the whole topics, I think your question is just how to restore your root password, right?

What you want to do has nothing to do with recovery mode. In jetson, recover mode means to put the device into a mode that is ready to be formatted. Under this mode, no OS is running so you don’t even have to think about root.

What was your error? You use “sudo -s” and entering your password but it keeps being rejected?

Hi,

Yes I want just to recover my sudo password
After I enter:

$ sudo -s
[sudo] password for nvidia:
Sorry, try again.
[sudo] password for nvidia:

Well, If I had x86-64 it would be possible to recover the sudo password. But, as far as I understand it is not possible in Jetson

I could use the sudo password and from one day to another it did not work, I did not change the password at all.

Cheers and thank you :)

Seems there is no method to configure it on device directly.

Unfortunately, I guess you need to flash it.

Do you want to reset the password? Because as @linuxdev suggests, that might be possible by extracting the file system image, modifying it, and then restoring it.

Actually recovering it, by which I understand you to mean turning hashed password into a plain text password, will take a very long time. Here is an article that will give you some background on how to do either:

https://www.cyberciti.biz/faq/understanding-etcshadow-file/

Edit: That will give you background on what file you need to edit. @linuxdev can probably give you better advice on extracting the file system image from the Xavier. I have never personally attempted that feat.

Just a thought which might simplify things for you before I get into the clone/restore information: In these earlier releases there was usually both an “ubuntu” account (default password “ubuntu”), and an “nvidia” account (default password “nvidia”). Even if the “nvidia” account is not working you might try to log in as “ubuntu” (pass “ubuntu”). For people who were sharing their network with other users it has been somewhat common that failing to change the “ubuntu” password allowed malicious logins. The most common example is that college dormitories share one large network with all of the students and do not firewall and it is likely to have someone log in in such a case and delete/modify/“do bad things” if the password is not changed.


Note that PC based systems have a GRUB bootloader, and that embedded systems do not have a BIOS/UEFI, and thus GRUB cannot work with embedded systems. A PC boot can actually run a second recovery instance (either on a CD/DVD or ramdisk upacked from the base install) of the o/s and run chroot against the original operating system files. This means the recovery instance on a PC is a fully functioning (though cut down) Linux operating system with an ability to run as root and change passwords against the other files (including the original o/s’s password files). Embedded systems could possibly add changes to make a rescue system possible (“rescue” is not equal to “recovery mode”), and I’ll add more at the end of this, but in normal use case there is no setup to create that rescue image. What follows starts with normal instructions for working with clones, and you’d likely need a clone even if you go through the effort to build some sort of rescue system.


If your system has something of value on it, then it may be worth your time to clone/edit/reflash. If content is not significantly valuable, then I’d just reflash. Either way I am assuming it is useful for you to have a backup before overwriting it. If you have a proper clone, then you can experiment without fear of losing anything even if an experiment with recovery fails.

When cloning, keep in mind that L4T R28.2.1 corresponds with JetPack 3.3. The JetPack 3.3 URL is here (you may need to go there, log in, and then go to the link a second time):
https://developer.nvidia.com/embedded/jetpack-3_3

JetPack is itself just a front end which downloads the “driver package” and “sample root filesystem”…these latter packages are what actually flashes and produces a particular L4T release (JetPack could be skipped for flash). When you go to flash again, if you use JetPack, and if you want to reuse a clone of R28.2.1, then you would use JetPack 3.3. There are strong dependencies in the “extra packages” (such as CUDA) between the L4T release and the JetPack release, and the part JetPack does which L4T install does not do is to download and install all of those “extras”, e.g., CUDA. There are also boot dependencies, and so if you mix L4T with another JetPack release, then there is a strong chance that something CUDA-related or boot-related would fail. Always match JetPack and L4T releases such that they are compatible if you are restoring from a clone.

If you want to simplify, and just clone/edit/restore, then I’d use command line with the R28.2.1 driver package (which has no need of JetPack…you’d be downloading this yourself instead of asking JetPack to do so). When you restore from a clone which already has CUDA and “extras” on it, then there is no need for JetPack since the content is already there, and for that case the GUI is just an interfering complication. The L4T R28.2.1 page is here:
https://developer.nvidia.com/embedded/linux-tegra-r2821

When you flash with JetPack it just downloads and unpacks the driver package. It is the driver package which produces the “Linux_for_Tegra/” subdirectory, and this is where the “flash.sh” script is located (this would be unpacked as a regular user, not with “sudo”). Regardless of how you do it unpacking the “driver package” (without “sudo”) is the first step. Even if using a clone it does not hurt to have the “sample root filesystem” correctly unpacked as well (using “sudo”).

A normal R28.2.1 command flash would have you prepare as follows:

  1. Download the driver package and sample rootfs:
    https://developer.nvidia.com/embedded/dlc/tx2-driver-package-r2821
    https://developer.nvidia.com/embedded/dlc/sample-root-filesystem-r2821
  2. Unpack the driver package without sudo in some place with a lot of extra hard drive storage capacity (probably need over 40GB before downloads):
    tar xvfj /where/ever/it/is/Tegra186_Linux_R28.2.1_aarch64.tbz2
  3. Unpack the sample rootfs with sudo:
    cd rootfs
    sudo tar xvfj /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R28.2.1_aarch64.tbz2
  4. Apply binaries for drivers:
    cd ..
    sudo ./apply_binaries.sh
    (everything is now set up for a regular flash).

If you are merely cloning and restoring from a clone, then technically you do not need the sample rootfs package. A regular flash would generate an image based on the sample rootfs+apply_binaries.sh drivers along with some minor edits. Your clone implies you don’t really need the “rootfs/” content, but I’m going to suggest you have this anyway since the default password related files are there, and when you go to modify the clone to reset passwords these are a nice source. There are many ways to do the edits, but the defaults may be the simplest way to change things…or at least make a nice reference before talking about other ways to change things.

Note for people reading this using newer releases: The R28.x L4T releases and earlier (JetPack 3.3 and earlier) all set up some default user names and passwords. People working with clones in the R32.x+ L4T releases (JetPack/SDK Manager 4.x+) have to set up passwords differently, and so instructions differ for people using later releases. Related files are the same, but account setup itself differs between earlier (R28.x and before) versus newer (R32.x and newer) releases. The information provided assumes R28.x (or earlier).

At one point there was an edit required on some releases for clone. Try what follows to clone, and if this does not work, then I’ll add the patch to the flash.sh script. If the TX2 is in recovery mode with the micro-B USB cable connected, then this is the clone command:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

This will produce two files: my_backup.img (a “sparse” file, and my_backup.img.raw (a “raw” file). The sparse file will be smaller, but still a couple of GB or more. The sparse file can be deleted to save space. The file you will work with, and the one which is huge, is the raw “my_backup.img.raw”. Both files have the same content, but the sparse file is in a form you won’t be able to use. Hint: Use “df -H /where/ever” to find out how much space is available at a location.

If you were to flash again, and use this clone (essentially doing nothing unless you’ve edited the clone), then here is what you would do:

  1. Save a raw clone somewhere safe.
  2. Copy this raw clone to new name and location:
    Linux_for_Tegra/bootloader/system.img
  3. cd /where/ever/it/is/Linux_for_Tegra/
  4. sudo ./flash.sh -r jetson-tx2 mmcblk0p1

This would take a lot of time to flash since the raw file is much bigger than a sparse file. If you had left out the “-r” option to flash.sh, then your custom system.img would have been overwritten with a newly created sample rootfs image. With the “-r” option the rootfs will come from your clone.

Prior to flashing you can manipulate the clone. I use “/mnt” for a mount point just out of tradition, but you can mount anywhere which is convenient. The following illustrates loopback mounting (note that “sudo -s” keeps you in a root shell and you will be operating as root until you “exit” the root shell…be very careful to not alter password files on the wrong filesystem):

sudo -s
# Copy the "my_backup.img.raw" somewhere safe, don't edit the original unless
# you know your edits are valid. I edit the copy which was renamed "system.img"
# and placed in "Linux_for_Tegra/bootloader/" to avoid risk from editing the original
# clone.
mount -o loop /where/ever/it/is/Linux_for_Tegra/bootloader/system.img /mnt
cd /mnt
# Randomly examine the root of the loopback mounted clone:
ls
# Examine password related files:
cd /mnt/etc
ls *shadow* *passwd* *group*
# Perhaps change or edit something in "/mnt/etc/", then umount:
cd
umount /etc
exit

As it turns out the password related files will all have a version in the “Linux_for_Tegra/rootfs/etc/” directory. Assuming you ran the “sudo ./apply_binaries.sh” step I mentioned earlier, then the “ubuntu” and “nvidia” accounts (and their default passwords) will be present. If you were to copy like this prior to umount, then your image would have all of the default passwords and users back in place:

sudo -s
cd /mnt/etc
cp -a /where/ever/it/is/Linux_for_Tegra/rootfs/etc/*shadow* .
cp -a /where/ever/it/is/Linux_for_Tegra/rootfs/etc/*passwd* .
cp -a /where/ever/it/is/Linux_for_Tegra/rootfs/etc/*group* .
cd
umount /mnt
exit
# Proceed to flash. Content will be the clone with original passwords
# reinstalled.

If you want to store the very large raw image you can compress it, but expect that even a file copy takes a very long time, while compression takes even longer:
bzip2 -9 /where/ever/it/is/my_backup.img.raw

One complication is that if you flashed with a non-default rootfs partition size, then you will need to use the “-S ” option during flash to set the correct partition size. Just ask if that is the case.


Some people operate on an embedded system image using QEMU to emulate running on that architecture (which gets complicated). If you have a way to run a “rescue” system under QEMU which would run like a PC’s rescue image, but for aarch64/arm64, then you could do a chroot into the clone image and directly use the “passwd” command to change passwords, followed by flashing the edited clone. Presumably, if all you’ve changed related to account names and passwords were the default passwords of accounts already existing, then this would result in exactly the same thing as copying from the “Linux_for_Tegra/rootfs/etc/” files.


Sometimes boot can be set to allow booting from an SD card or external USB SATA drive. If the environment searches for such a device and only boots the eMMC when no such other device is found, then this could be used as a rescue image. You’d then chroot into the eMMC image and run the “passwd” command (your alternate image would allow sudo since you are using its password and not the one on eMMC). Instructions for doing this varies depending on release, and is often best set up prior to a system failure. The reason this works is because the boot content (not the root filesystem) is on other partitions (think of those partitions as the missing BIOS/UEFI function, along with a pointer to the boot device). Creating a rescue image would likely use the “Linux_for_Tegra/rootfs/” content anyway, along with some boot configuration edits. Best done prior to a failure as some efforts to set this up could accidentally overwrite the original rootfs (if you have a clone then you can fail and not really lose anything).

Hi There,

Booting from an SD card and then using chroot to recover the sudo password, sounds like a good option.

Do not you have a goo link on how to do it.

and

Just wondering how or the reason from one day to another the su password stop working. I mean what could have prompt this issue?

Thank you

Most of the time when the password stops working it is because someone got into the system and maliciously changed it. Do you see a timestamp from “ls -l /etc/passwd”? If the last time an account was updated (any account in any way) was more recent than what you remember, then it might have been tampered with.

There are also password related commands which, if used incorrectly, might have changed something you did not expect to change. Passwords can be set to expire, but in that case the user is prompted to update (expiration is not the default behavior, this would have to be intentionally set). Other than this passwords do not just change on their own, even for hardware failure.



You will be able to find documentation about setting up for boot to an SD card, and using serial console to boot into the SD card if detecting the card does not automatically boot to the alternate rootfs. Once you can do this we test chroot. Any SD card image would presumably use a password you know.

If you are creating an image for an SD card, then you would need to set up the password on that rootfs prior to copy to the SD card. The script here is quite useful:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37

Note that this script could be used on a loopback mounted clone, and that a clone (with minor edits) could be used for an SD card rescue. The script creates an account and sets its password, along with making sure the account is a member of group “video”. In the case of a rootfs which already has the account you’d simply comment out the part which creates preexisting names, but still allow it to set the password.

In the case that you clone, then if you were to set the password via that script and flash with the clone instead of a generated rootfs, then you’d be done and wouldn’t need to use chroot. That same rootfs clone would be the best source of a rescue (you’d simply make an edit to the “/boot/extlinux/extlinux.conf”). “Clone is your friend”.



Without cloning you can still use the sample rootfs for rescue, but more effort is required. If you unpack the sample rootfs, and use the “apply_binaries.sh” to add the NVIDIA drivers, then you are almost there. If you ever flashed, then you already have this. The rest is that you would still need to set up the rescue image’s “/boot”. During a flash content is copied in to “rootfs/boot/”, and so you might have most of this as well if you actually flashed once, although you would need to edit the “rootfs/boot/extlinux/extlinux.conf”.

For the edit to extlinux.conf I would suggest removing “quiet”, and then appending (space delimited) “root=/dev/mmcblk1p1” (“mmcblk0” is eMMC, “mmcblk1” is the SD card, and the image will be going onto the first partition of the SD, thus “mmcblk1p1”). Basically replace the “quiet” with the “root=” content. I have not done this in a while, and there may be changes which cause the booting Jetson (depending on release) to not use this entry (if that is the case you are back to using a clone).

If you are interested in cloning, just ask for any info you need. Clones are the recommended method…even if something fails, then you still have your content and can try again.

Hi,

I have just checked ls -l /etc/passwd and I got.

Dec 12 2016 /etc/passwd

Probably it was a password related command.

I have been trying to set up for boot to an SD card. I have follow the following link.

A20 OlinuXino Micro

I had successfully done the whole process, however when I insert the sdcard into the jetson and I boot the system, it does not boot into the sdcard.

I am confuse if the previous link is the right one, maybe is the wrong image.

And, to be sincere I do not know which image to use under the platform tab in the following link platform

Is it possible for you to guide me, or what did I do wrong?

Maybe the easiest way is to re-flash the jetsonTX2.

Thank you.

Unfortunately, the above is not a valid “ls -l”. The command should return file permissions. If permissions cannot be retrieved, then this would imply password software will reject the file. I am unsure as to whether this was abbreviated or quoted badly, or if this was an actual error. If you quote this into the forums, try surrounding the output with the single back quote character on each side (the `, which is near the tab key). Or you can highlight the text and click the “</>” icon in the upper part of the menu bar.

For SD card boot issues you will want to provide a serial console log of the boot. See:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

A log will give more information about where the boot failed.

Hi,

In the end of the day I decided to re flash the JetsonTX2.

The sudo password works now, the only thin is that I need to re install everything.

Just wondering whether I could get some advises in order to avoid the issue with the password.

Thank you

Just make sure that if your system is not isolated on a private network, e.g., with a router blocking connections not originating from the Jetson, that your password is good so nobody can guess it. I think probably the largest number of users where something malicious happened were using university networks where all of the student’s can directly reach every other student.

You could also consider enabling and verifying any firewall rules. A nice way to work with this is the “ufw” application, or the GUI version, “gufw”. To make sure both are installed:
sudo apt-get install ufw gufw

Information on best practices for firewall setup tend to be the same on all of the Ubuntu systems regardless of whether it is embedded or a PC, so there is a lot available there. For example, you might cut out all web server traffic (and you probably don’t even run a web server unless you use Jupyter or similar) from routes that shouldn’t be using your web server.

Also, when you flash, make sure the content being flashed is from a Linux filesystem type. For example, it isn’t unusual for someone with lack of disk space to temporarily attach a USB disk which is already formatted as NTFS. Running “df -H -T /where/ever/flashed/from/Linux_for_Tegra/” can tell you if there is enough space and if it is type ext4 or other native Linux filesystem type.

Hi,

Thank you for your suggestions. I guess I need to change the default nvidia sudo password for another reliable one, right?

I have re flashed the jetsonTX2 by means of the scrip JetPack-L4T-3.2.1-linux-x64_b23.run and the Audivea_TX2_jetpack patch for mouse and keyboard issues.

However, even it was stated in the installation process the installation of CUDA-09. It turned out that CUDA-09 was not installed on the jetsonTX2.

I am wondering why, never experience this situation before.

well, I run the bash script again and I can see the following error:

Determining the IP address of target...
nc: Address already in use

JetPack is unable to determine the IP address of the Jetson Developer Kit
Failure to run bash command "timeout 180 nc -l 33338" because of error: exit status 1, nc: Address already in use
Please select which action do you want:
1. Retry
2. Manually enter IP address

How can I solve the IP address error?

Thank you so much :)

Correct. In newer releases the end user is actually forced to create the admin account login name and pass on first boot. Just make sure on older releases (JetPack 3.x and before) you do not use a default pass, and that on newer releases (JetPack 4.x and newer) you use an actual “good” password. I’ve seen firewalls log attempts to brute force ssh access via default passwords within less than two minutes on unprotected networks. You have about that long to change the password if the interface is in the wild.

JetPack flashes first, if you have checked that off. Optional packages, e.g., CUDA, do not exist in the flash image. Once the flashed system is fully booted you can then use ssh over ethernet to add packages from JetPack. In a normal flash the system reboots by itself once flash completes, and thus it may seem like the flash included CUDA, but in reality these are separate steps. You can deselect flash and simply install extra packages at any time.

Do note that “optional packages” from one JetPack release cannot be used with a system flashed by another release (there might be an exception for bug fix releases).

The reason for needing the IP and name/pass is due to the use of ssh to copy from the host PC JetPack to the Jetson. The network address can be from any network route, but typically earlier releases were more convenient from wired ethernet, while in newer releases a virtual wired ethernet over USB is less trouble (I use actual wired ethernet even when virtual wired ethernet is available because it has higher bandwidth and everything is already set up for that).

Because you are using an older release, if you are logged in to the Jetson, what do you see from the command “ifconfig”? This assumes the TX2 wired ethernet is connected to a router and that the router is allowed to assign an address (some corporate routers don’t do this without talking to the I.T. department and providing a MAC address).

For “eth0”, can you ping that address from the host PC? If you can, are you able to “ssh name@address” (replace “name” and “address” with actual login name and IP address)? This is the precondition before JetPack can use ssh to add optional packages.

Just remember that you can deselect “flash” and add or work with extra packages at any time. You do not need to flash each time.

Hi,

Thank you for your replay.

Based on this this forum discussion, I just Looked for any nc processes and killed them. Then JetPack was able to determine the IP address of the Jetson Developer kit.

I hope one day I can upgrade to the latest version :)

I have a question.

I remember the last command I used before the sudo password did work was the following:

rosbag record to sd card. Do you think this command may had influenced the sudo password not working?

Cheers

I have no experience with that command, though it seems to be for robot operating system (which I do not use). I suppose that there are a number of ways this could have gone wrong when used with sudo, but it isn’t possible to really know without logs of what the command actually did. As an example, something as simple as incorrectly naming the SD card as destination could fill the eMMC and prevent sudo from working due to lack of temporary file space. Or naming an incorrect output location with sudo might overwrite something else (easier to do than it sounds if you use tab completion). How ROS deals with passwords and admin I do not know…never used it before…but perhaps it has its own commands which would alter password or sudo behavior.

If you do this again, I suggest that while doing it you have a serial console logged in, and that on the serial console you first drop into a root shell with “sudo -s”. Then if something goes wrong root can fix the issue short of something which locks up the operating system.