ORIN restored SSD boot: ERROR: PARTUUID=8c740455-e7e3-4f7d-8902-65e619f9046f mount fail

[lxy1]

Hi, we are using our self-developed carrier board with an ORIN NX 16G SOM. L4T：35.4.1,JETPACK:5.1.2, We plan to clone an existing intact system. Using the following commands：
sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit
sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r jetson-orin-nano-devkit，

backup and restore command work properly, but during the restored nvme startup, the screen goes black. Observing via UART, the following error appears:
[ 12.334246] random: crng init done
[ 22.795150] ERROR: PARTUUID=8c740455-e7e3-4f7d-8902-65e619f9046f mount fail…

uart_boot.log (156.4 KB)

According to this post ERROR: PARTUUID=bbc76f97-xxxx-xxxxx-xxxx-92697925be65 mount fail,
Modify the content of the file Linux_for_Tegra/bootloader/l4t-rootfs-uuid.txt to 1e5a432c-0466-4d31-b009-d4d9239271d3 ，after executing command：
sudo ./flash.sh --reuse-uuid jetson-orin-nano-devkit internal

it shows that the command cannot be executed, probably because the --reuse-uuid option is invalid. Please provide assistance.

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing is related to the PARTUUID mismatch during the restore process of your Jetson AGX Orin system. This is a common problem when cloning an existing system to a new device.

The error message “ERROR PARTUUID8c740455e7e34f7d890265e619f9046f mount fail” indicates that the system is unable to mount the root filesystem due to a mismatch in the PARTUUID.

The solution provided in the post you mentioned suggests modifying the content of the file Linux_for_Tegra/bootloader/l4t-rootfs-uuid.txt to match the PARTUUID of the new device. However, this solution is not applicable in your case, as the reuseuuid option is not valid for the flash.sh command.

Instead, you can try the following steps to resolve the issue:

1. Check the PARTUUID of the new device by running the command sudo blkid on the new device. This will display the PARTUUID of the device.
2. Modify the content of the file Linux_for_Tegra/bootloader/l4t-rootfs-uuid.txt to match the PARTUUID of the new device.
3. Run the command sudo flash.sh -r jetson-orin-nano-devkit internal to re-flash the device with the updated PARTUUID.

Alternatively, you can try using the --no-flash option with the l4tbackuprestore.sh command to restore the system without flashing the device. This will allow you to modify the PARTUUID manually before flashing the device.

It’s also worth noting that the l4tbackuprestore.sh command is not officially supported by NVIDIA, and it’s recommended to use the official flash.sh command for flashing and restoring Jetson devices.

In comparison to the Jetson Orin Nano and Jetson Orin NX, the Jetson AGX Orin has a similar architecture and uses the same L4T (Linux for Tegra) operating system. However, the Jetson AGX Orin has a more powerful GPU and is designed for more demanding applications.

In terms of troubleshooting, the UART log you provided is helpful in identifying the issue. The error message “ERROR PARTUUID8c740455e7e34f7d890265e619f9046f mount fail” is a clear indication of the PARTUUID mismatch. The blkid command can be used to verify the PARTUUID of the device, and the flash.sh command can be used to re-flash the device with the updated PARTUUID.

Overall, the solution to this issue requires modifying the PARTUUID of the new device to match the one in the l4t-rootfs-uuid.txt file, and then re-flashing the device using the flash.sh command.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[lxy1]

Hi, the command，sudo ./flash.sh -r jetson-orin-nano-devkit internal， doesn’t work, and it gets stuck here:

uart_log.txt (26.6 KB)

I tried flashing the QSPI with this command:
sudo ./flash.sh -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal
and it executes normally, but the issue persists.

[DavidDDD]

Hi,

Could you provide the backup/restore log and record the serial console log at the same time?

Thanks

[lxy1]

Thanks for your reply.
In order to obtain the log, I performed the backup operation again,
sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit
but it seems like the backup didn’t complete before exiting. I tried twice, and the same issue occurred both times.

and the backuped file should be greater than 600GB, but it is only less than 300GB.

log files:
flash_1-1_0_20250805-220837.log (6.5 KB)
uart_boot.log (86.0 KB)

[DavidDDD]

Hi,

Since you are using the r35.4.1, please refer to

Can not restore nvme with Orin Nano

Apply this patch: diff --git a/scripts/backup-restore/nvrestore_partitions.sh b/scripts/backup-restore/nvrestore_partitions.sh index 78ae589..695a700 100755 --- a/scripts/backup-restore/nvrestore_partitions.sh +++ b/scripts/backup-restore/nvrestore_partitions.sh @@ -313,10 +313,18 @@ echo "${SCRIPT_NAME} Checksum of ${FIELDS[2]} does not match the checksum in the index file." exit 1 fi - # partx delete must be called before flashing, and partx add after flashing. - partx -d "/dev/$…

Thanks

[lxy1]

Thanks for your reply. following the method above, I successfully performed the backup and restore process, but the restored system still can’t boot, showing an error that the PARTUUID cannot be found.

the PARTUUID=8c740455-e7e3-4f7d-8902-65e619f9046f is the backuped nvme0n1p1’s

flash_1-1_0_20250808-193127.log (6.2 KB)

flash_1-1_0_20250808-203236.log (6.1 KB)

uart_boot.log (88.8 KB)

Please provide suggestions.

[DavidDDD]

Hi.

Just to confirm — did you place your device into Recovery Mode before running the backup and restore process?
We’ve noticed that your backup log looks quite different from ours.

Thanks

[lxy1]

yes, it is in recovery mode, and get the backup files successfuly as follows:

[DavidDDD]

Hi,

Is your host a ubuntu or a windows?

Do you use the vm to run ubuntu?

Thanks

[lxy1]

Hi,

Yes, I am using a virtual machine system in WIN10, and it is running Ubuntu 18.04.

[DavidDDD]

Hi,

We recommend preparing a native Ubuntu environment, as virtual machines can sometimes cause issues during the flashing/restore process.

Using a native Ubuntu system will allow us to better focus on resolving your backup restore issue.

Thanks