To manually flash you would need to manually install some content on the host PC without the use of sdkmanager. It would perhaps be easier to install Ubuntu 18, although that also might not be practical for many cases (if you can, consider adding another disk to the PC and installing Ubuntu 18 to that for multi-boot)
However, if you do wish to flash on command line, this implies:
- Downloading the “driver package” and “sample rootfs” for your exact L4T release (L4T is what actually gets flashed, which is Ubuntu plus NVIDIA drivers, and JetPack/SDKM are front end utilities used to perform the flash through the “driver package”).
- Unpacking the driver package as a regular user.
- Unpacking the sample rootfs in the new “
Linux_for_Tegra/rootfs/” which was created by unpacking the driver package, using root authority (using “sudo”).
- Adding the drivers to that content via “
sudo ./apply_binaries.sh” from the “Linux_for_Tegra/” directory.
- Optionally, and recommended for your case, running “
sudo ./tools/l4t_create_default_user.sh” to pre-create the first boot login. You would use the exact account name which is supposed work on your current install. This would give you the files you need to repair the original.
- At this point you could:
- Flash and recreate with your account repaired, but it would lose existing customization.
- Clone the original rootfs, and use the content of the now updated “
Linux_for_Tegra/rootfs/” to perhaps repair sudo; then flash using the repaired clone.
- Important: You must use the same L4T release that is on the existing rootfs if you wish to repair.
- The list of L4T releases is at here.
- Normally SDKM will do this for you, but your host PC release does not allow it in this combination.
One would clone on command line, and if this is an ordinary TX2 dev kit, the clone would be with the Jetson in recovery mode, and go something like this:sudo ./flash.sh
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
This would produce a “raw” image, “my_backup.img.raw”, plus it would produce a “sparse” image, “my_backup.img”. Both of these are very large files, but the “raw” image is the exact byte size of the partition, and the “sparse” image is around the size of the content actually stored (as the partition fills the sparse size approaches the raw size; in that case you’d get two files which are each the size of the partition).
If your partition is 14 GB, and if the content you have is 8 GB, then this alone will produce 22 GB on the host PC.
Both can be used to flash, but the smaller sparse image is faster. Unfortunately, you cannot use loopback with a sparse image. I personally delete the sparse image. Just a copy of the raw image can take an hour to move from one location to another if it is on different media, and you might want to have a pristine copy plus a working copy until you know it is going to work. If you get one that works, then you could save it as backup, and maybe compress it with “bzip2 -9” (which can itself take a couple of hours to complete on large files).
If your raw file is “my_backup.img.raw”, then you could cover it with loopback like this:
sudo losetup --show ./my_backup.img.raw
(assumes you are in the directory containing your working copy of my_backup.img.raw)
If it turns out that the name of the loop device is “/dev/loop0” (it might have a different number), then you could mount it like this on the host PC’s “/mnt” directory (any empty directory works):
sudo mount -o loop /dev/loop0 /mnt
Alternately, you can mount directly and tell the mount command to create the loop device:
sudo mount -o loop ./my_backup.img.raw /mnt
You can always monitor “dmesg --follow” on the host PC and regardless of whether you use “losetup” or “mount -o loop” it would tell you the loop device name that was created. There are a limited number of loopback devices available, so you can detached a loop device, or detach all non-busy loop devices. Example, when done with the work:
sudo losetup -D
(see “man losetup”)
sudo ./flash.sh
From there, wherever you mounted the loopback, e.g., assuming “/mnt”, you can see and access your entire rootfs in “/mnt”. Example: “cd /mnt; ls`”.
Now if you know what files were altered on the Jetson, and if you have the correctly set up sample rootfs which has added your user, then the “/mnt/etc/sudoers” (or other related files) should be the original you started with. If you preserve permissions correctly (remember that this is a special kind of file), then you can probably copy it to the loopback mounted clone to fix the previous error.
Then you could flash again while reusing that corrected clone.
If you were to “just flash”, without the clone, it would go like this:
sudo ./flash.sh jetson-tx2 mmcblk0p1
To instead flash reusing the existing image (which you must set up to be the unmounted corrected clone);
sudo ./flash.sh -R jetson-tx2 mmcblk0p1
Any binary image which is placed at “Linux_for_Tegra/bootloader/”, *and renamed to “system.img” will be flashed. If you flash “normally”, then a default “bootloader/system.img” is created before the flash. The “-R” argument says to not overwrite the system.img.