Error after changing rootfs on Jetson TX2 (L4T 32.6.1)

My task: to flash a backup (previously saved as tar-archive) of the rootfs into the Jetson TX2.

How that backup was obtained:

sudo tar -cf rootfs_backup.tar /bin /boot /dev /etc /home /lib /opt /README.txt /root /sbin /snap /srv /usr /var

(I also sometimes use pigz or zstdmt)

How I flash a previously saved backup:

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 …

Always use uart log to tell your problem instead of using the HDMI monitor.

https://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

Also, where does this “rootfs_backup.tar” come from ? I mean what is the base jetpack version for it?

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:

  1. 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

  1. Making backup of new filesystem on Jetson:
sudo tar -cf rootfs_backup.tar /bin /boot /dev /etc /home /lib /opt /README.txt /root /sbin /snap /srv /usr /var
  1. 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

So what is the target BSP jetpack version you are using in step 3 Linux_for_Tegra?

And please dump boot log from uart.

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:

sudo systemctl start gdm3.service
sudo dpkg-reconfigure gdm3

in the opened window, select: gdm3

sudo reboot

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