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):
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:
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:
- Download the driver package and sample rootfs:
- 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
- Unpack the sample rootfs with sudo:
sudo tar xvfj /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R28.2.1_aarch64.tbz2
- Apply binaries for drivers:
(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:
- Save a raw clone somewhere safe.
- Copy this raw clone to new name and location:
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):
# 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
mount -o loop /where/ever/it/is/Linux_for_Tegra/bootloader/system.img /mnt
# Randomly examine the root of the loopback mounted clone:
# Examine password related files:
ls *shadow* *passwd* *group*
# Perhaps change or edit something in "/mnt/etc/", then umount:
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:
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* .
# Proceed to flash. Content will be the clone with original passwords
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).