I have successfully flashed JetPack 7.1 onto this DevKit with a 256GB SSD using SDK Manager. The flashing process was smooth, and the system boots/operates perfectly.
But I am consistently encountering a hang issue while performing a system backup using the official l4t_backup_restore.sh tool on Jetson Thor.
The backup process proceeds correctly for the first 7 partitions (including the large 235GB APP partition nvme0n1p1), but it consistently hangs when it reaches nvme0n1p8 (PARTLABEL=“esp_alt”).
Steps to Reproduce :
Put Jetson Thor into Recovery Mode. Run on Host PC :
1.sudo systemctl stop udisks2.service
2.sudo tools/l4t_flash_prerequisites.sh
3.sudo service nfs-kernel-server start
4.sudo ./tools/backup_restore/l4t_backup_restore.sh -b jetson-agx-thor-devkit (or with -c for massflash). Observe the logs until it reaches partition 8.
Diagnostic Evidence :
Local Read Success : I SSH’ed into the Thor initrd and manually ran dd if=/dev/nvme0n1p8 of=/dev/null — it finished in seconds. This proves the DevKit can read its own disk. NFS Deadlock : The hang occurs during the NFS write-back phase. dmesg reports:
Thank you for your response. As requested, I have attached the full logs captured from both the Host PC and the Jetson Thor serial console during the failed backup session.
Attached Files :
backup-thor.log : Full execution log from the Host PC side, showing the command used and exactly where it stopped. thor-serial-console.log : Serial console log captured directly from the Jetson Thor’s debugging port, including the dmesg output during the hang.
Key Highlights from the Logs :
You will notice that the backup succeeds for partitions 1 through 7.
The hang occurs immediately when the script attempts to back up nvme0n1p8 (esp_alt).
In the serial log, you can clearly see the dd task being blocked for more than 120 seconds.
Please let me know if you need any further information or if there are specific tests you would like me to run based on these logs.
Thanks for the suggestion. I tried the command with -e nvme0n1, but the backup still hangs at Partition 8.
The Call Trace shows the dd process is consistently blocked at nfs4_file_flush and nfs_wb_all.
It appears to be a writeback/locking issue during the transport phase.
I would appreciate any guidance or further insights you could provide to help resolve this.
Thanks for the reply. I can confirm that my host PC has sufficient disk space (over 500GB free) and I have tested different USB ports with high-quality cables. The issue persists regardless of these factors.
My Host PC is running Ubuntu 24.04 LTS.
It seems the backup hanging issue is caused by an NFSv4 locking/lease timeout when writing large partition images from the Jetson (initrd client) to the Host PC (NFS server).
The default l4t_backup_restore.sh lets the client negotiate the NFS version, and Ubuntu 24.04’s NFS server defaults to v4, which seems unstable for this specific high-throughput scenario.
I’m not sure if this is the correct fix, but forcing NFSv3 on the client side has at least resolved the current backup timeout issue for me.
Change applied in l4t_backup_restore.sh (around line 180):
Original:
mount -o nolock ${hostip}:${nfs_folder} /mnt
Modified (Working):
mount -o nolock,nfsvers=3 ${hostip}:${nfs_folder} /mnt
With nfsvers=3, the backup completes successfully every time without hanging.