cd Linux_for_Tegra/rootfs/
sudo tar xpf path_to_backup_rootfs.tar
cd ..
sudo ./flash.sh jetson-tx2 mmcblk0p1
Above procedure works great for l4t 28.2.1 (kernel 4.4.38, for jetpack 3.3) and l4t 32.5.1 (kernel 4.9.201, for jetpack 4.5). I performed a similar procedure for l4t 32.6.1 (kernel 4.9.253, for jetpack 4.6), but when I launched the Jetson after flashing, I received such log:
cp: not writing through dangling symlink ‘etc/resolv.conf’
cgroup: cgroup2: unknown option “nsdelegate”
using random self ethernet address
using random host ethernet address
using random self ethernet address
using random host ethernet address
CPU1: shutdown
CPU2: shutdown
Bridge firewalling registered
At this, the launch is suspended.
I need help for solving this problem …
When creating a backup, the file system was archived, which was previously flashed through the same L4T - 32.6.1. I performed similar steps for old L4Ts (32.5.1 and 28.2.1) and everything worked without problems!
I also did an experiment like this:
Flashing sample-rootfs through L4T 32.6.1:
wget https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/t186/jetson_linux_r32.6.1_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/t186/tegra_linux_sample-root-filesystem_r32.6.1_aarch64.tbz2
tar xf jetson_linux_r32.6.1_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
sudo tar xpf tegra_linux_sample-root-filesystem_r32.6.1_aarch64.tbz2
cd ..
sudo ./apply_binaries.sh
*Set recovery mode* (manipulations with buttons on devkit )
sudo ./flash.sh jetson-tx2-devkit mmcblk0p1
After flashing, an operating system on the Jetson starts up normally
Flashing the backup, obtained in the previous step
cd Linux_for_Tegra/rootfs/ #I'm not creating a new folder Linux_for_Tegra, I'm using the same Linux_for_Tegra, which was created earlier in step 1
sudo rm -r * # delete previous rootfs
sudo tar xpf path_to_backup_rootfs.tar # backup_rootfs, that was obtained in step 2
cd ..
sudo ./flash.sh jetson-tx2 mmcblk0p1
After flashing I launched Jetson and get the same log that was given in my first message here
I did not look at all details, but just want to add that it is probably a bad idea to simply use tar on a running filesystem. Basically you need a copy of the actual files, down to permissions and type of file, and if you were to attempt this, then you are better off simply making a copy of “mmcblk0p1” using dd, or to use “rsync” with the option for not crossing filesystems (this would be imperfect, but better than tar).
If you were to dd copy “/dev/mmcblk0p1”, and if the filesystem does not change in a fatal way during the copy, then this could be used directly on the host PC performing flashes if you use the “-r” option and place the dd copy as “Linux_for_Tegra/bootloader/system.img”. You would also possibly be able to dump this image’s content (after loopback mount) into “Linux_for_Tegra/rootfs/” and have this as the source for generating a default image (the boot content would be edited slightly during flash, but most other content would match your original system’s root filesystem).
It is best to use an actual clone from recovery mode since the filesystem would not be changing during clone.
I solved this problem. Despite this error, access to the terminal was still available. I went to the terminal through Ctrl+Alt+F2 and executed the following commands: