Error during backup and restore script execution for Orion NX 16 GB on l4T ver 35.5 JP 5.1.3

Hi,

I am getting below error when trying to backup the Orion NX 16 GB unit using the backup and restore script as shown below:

root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r35.5.0/Linux_for_Tegra# sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orion-nano-devkit
/home/trident/Downloads/r35.5.0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --initrd --showlogs jetson-orion-nano-devkit mmcblk0p1
/home/trident/Downloads/r35.5.0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh: line 48: /home/trident/Downloads/r35.5.0/Linux_for_Tegra/jetson-orion-nano-devkit.conf: No such file or directory
/home/trident/Downloads/r35.5.0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash.func: line 216: /home/trident/Downloads/r35.5.0/Linux_for_Tegra/jetson-orion-nano-devkit.conf: No such file or directory


  •                                    *
    
  • Step 1: Generate rcm boot commandline *
  •                                    *
    

ROOTFS_AB= ROOTFS_ENC= /home/trident/Downloads/r35.5.0/Linux_for_Tegra/flash.sh --no-flash --rcm-boot jetson-orion-nano-devkit mmcblk0p1
Error: Invalid target board - jetson-orion-nano-devkit.

Usage: sudo ./flash.sh [options] <target_board>
Where,
target board: Valid target board name.
rootdev: Proper root device.
options:
-c ---------- Flash partition table config file.
-d ---------- device tree file.
-f --------- Path to flash application (tegraflash.py)
-h -------------------- print this message.
-i – key for disk encryption support.
-k ----- partition name or number specified in flash.cfg.
-m ------ MTS preboot such as mts_preboot_si.
-n --------- Static nfs network assignments
:::
-o ---------- ODM data.
-r -------------------- skip building and reuse existing system.img.
-t -------- tegraboot binary such as nvtboot.bin
-u ------ PKC key used for odm fused board.
-v ------ Secure Boot Key (SBK) key used for ODM fused board.
-w ---------- warm boot binary such as nvtbootwb0.bin
-x ---------- Tegra CHIPID.
-B ---------- BoardId.
-C ---------- Kernel commandline arguments.
WARNING:
Each option in this kernel commandline gets
higher preference over the values set by
flash.sh. In case of NFS booting, this script
adds NFS booting related arguments, if -i option
is omitted.
-F ---------- Flash server such as cboot.bin.
-G -------- Read partition and save image to file.
-I ----------- initrd file. Null initrd is default.
-K ----------- Kernel image file such as zImage or Image.
-L ------- Bootloader such as cboot.bin or u-boot-dtb.bin.
-M --------- MTS boot file such as mts_si.
-N ---------- i.e. :/my/exported/nfs/rootfs.
-R ------- Sample rootfs directory.
-S ------------- Rootfs size in bytes. Valid only for internal
rootdev. KiB, MiB, GiB short hands are allowed,
for example, 1GiB means 1024 * 1024 * 1024 bytes.
-T —The number of the sectors of the external storage device.
The default value is 122159104 if this option is not set.
-Z -------------------- Print configurations and then exit.
–no-flash ------------ perform all steps except physically flashing the board.
This will create a system.img.
–external-device------ Generate flash images for external devices
–sparseupdate--------- only flash partitions that have changed. Currently only support SPI flash memory
–no-systemimg -------- Do not create or re-create system.img.
–bup ----------------- Generate bootloader update payload(BUP).
–single-image-bup Generate specified single image BUP, this must work with --bup.
–bup-type ----- Generate specific type bootloader update payload(BUP), such as bl or kernel.
–multi-spec----------- Enable support for building multi-spec BUP.
–clean-up------------- Clean up BUP buffer when multi-spec is enabled.
–usb-instance — Specify the USB instance to connect to;
= USB port path (e.g. 3-14).
–no-root-check ------- Typical usage of this script require root permissions.
Pass this option to allow running the script as a
regular user, in which case only specific combinations
of command-line options will be functional.
–uefi-keys <keys_conf> Specify UEFI keys configuration file.
–rcm-boot ------------ Do RCM boot instead of physically flashing the board.
–sign ---------------- Sign images and store them under “bootloader/signed”
directory. The board will not be physically flashed.
–image --------------- Specify the image to be written into board.
–boot-chain-flash Flash only a specific boot chain (ex. "A, “B”, “all”).
Defaults to “all”, inputs are case insensitive.
Not suitable for production.
–boot-chain-select Specify booting chain (ex. “A” or “B”) after the board is flashed.
Defaults to “A”, inputs are case insensitive.
–pv-crt -------------- The certificate for the key that is used to sign cpu_bootloader
–with-systemimg ------ Generate system images also when using -k option
–pv-enc <enc_key>----- The encryption key that is used to encrypt cpu_bootloader.
–uefi-enc <uefi_enc_key> Key file (0x19: 16-byte; 0x23: 32-byte) to encrypt UEFI payloads
–uda-dir-------------- Directory to store user data that will be encrypted in UDA partition.
–separate-rcmboot-binary ------ Enable use of different binaries for rcmboot and coldboot.
–generic-passphrase – Use generic passphrase for disk encryption.
–disable-random-iv — Disable generation of random IV, SALT1, SALT2 and DERSTR.
–read-info ----------- Read and display board related info, fuse info (based on fuse_t234.xml),
and EEPROM content.
–reuse-uuid --------- Reuse uuid which is already generated first time.

Cleaning up…

Note:
1) The same command worked for us before for our another Jetson AGX Xavier Industrial unit.
2) We observed that there is a conf file for jetson-orion-nano-devkit in that path as shown below. But it is soft linked to another file. But we dont see any permission issue for this to throw the error.
Kindly let us know, how to fix this and proceed with backup and restore.

root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r35.5.0/Linux_for_Tegra# ls -l jetson*.conf
lrwxrwxrwx 1 root root 40 Feb 20 10:08 jetson-agx-orin-devkit-as-jao-32gb.conf → p3737-0000+p3701-0000-as-p3701-0004.conf
lrwxrwxrwx 1 root root 40 Feb 20 10:08 jetson-agx-orin-devkit-as-nano4gb.conf → p3737-0000+p3701-0000-as-p3767-0004.conf
lrwxrwxrwx 1 root root 40 Feb 20 10:08 jetson-agx-orin-devkit-as-nano8gb.conf → p3737-0000+p3701-0000-as-p3767-0003.conf
lrwxrwxrwx 1 root root 40 Feb 20 10:08 jetson-agx-orin-devkit-as-nx-16gb.conf → p3737-0000+p3701-0000-as-p3767-0000.conf
lrwxrwxrwx 1 root root 40 Feb 20 10:08 jetson-agx-orin-devkit-as-nx-8gb.conf → p3737-0000+p3701-0000-as-p3767-0001.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-agx-orin-devkit.conf → p3737-0000+p3701-0000.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-agx-orin-devkit-industrial.conf → p3737-0000+p3701-0008.conf
lrwxrwxrwx 1 root root 31 Feb 20 10:08 jetson-agx-orin-devkit-industrial-maxn.conf → p3737-0000+p3701-0008-maxn.conf
lrwxrwxrwx 1 root root 31 Feb 20 10:08 jetson-agx-orin-devkit-maxn.conf → p3737-0000+p3701-0000-maxn.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-agx-xavier-devkit.conf → p2822-0000+p2888-0004.conf
lrwxrwxrwx 1 root root 32 Feb 20 10:08 jetson-agx-xavier-ind-noecc.conf → p2822-0000+p2888-0008-noecc.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-agx-xavier-industrial.conf → p2822-0000+p2888-0008.conf
lrwxrwxrwx 1 root root 31 Feb 20 10:08 jetson-agx-xavier-industrial-mxn.conf → p2822-0000+p2888-0008-maxn.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-orin-nano-devkit.conf → p3768-0000+p3767-0000.conf
lrwxrwxrwx 1 root root 31 Feb 20 10:08 jetson-orin-nano-devkit-nvme.conf → p3768-0000+p3767-0000-nvme.conf
lrwxrwxrwx 1 root root 26 Feb 20 10:08 jetson-xavier.conf → p2822-0000+p2888-0004.conf
lrwxrwxrwx 1 root root 27 Feb 20 10:08 jetson-xavier-maxn.conf → p2972-0000-devkit-maxn.conf
lrwxrwxrwx 1 root root 34 Feb 20 10:08 jetson-xavier-nx-devkit.conf → p3509-0000+p3668-0000-qspi-sd.conf
lrwxrwxrwx 1 root root 36 Feb 20 10:08 jetson-xavier-nx-devkit-emmc.conf → p3509-0000+p3668-0001-qspi-emmc.conf
lrwxrwxrwx 1 root root 31 Feb 20 10:08 jetson-xavier-nx-devkit-qspi.conf → p3509-0000+p3668-0000-qspi.conf
lrwxrwxrwx 1 root root 30 Feb 20 10:08 jetson-xavier-slvs-ec.conf → p2972-0000-devkit-slvs-ec.conf
root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r35.5.0/Linux_for_Tegra#

Hi,

Will it still happen if you delete the whole BSP folder and extract it again?
Also, is the partiton where the BSP lives an ext4 one?

Yes. BSP resides on EXT4.

I saw this release 35.5 package has old back and restore scripts where we need to manually change “mmcblk0” to “nvme0n1” in backup and restore, nv_backup, nv_restore scripts.

After editing I am able to successfully take back up.

Today I am planning to perform restore operation.
Let me know should I replace “mmblck0” with “nvme0n1” at all places in nv_restore… because I see there are 15 places that needs to be changed…

I don’t know why you need to do this.
This is not required on 35.5 with the -e option.

I tried to to git sync to download BSP code but did not give tag release name correctly and later tried downloading the source BSP manually and extracted.

Can I copy back and restore folder for release 35.4.1 and use it. As it was working fine with the partx patch for NVMe restore.
Please confirm?

This script should work universally across different BSP versions.

You mean 35.4.1?

YES, it should.

I was able to successfully backup and restore.

But have few queries:

  1. When we reboot the restored device, it always tries to boot from http ipv6, ipv4, pxe etc…
    I tried to press F11 key to enter boot manager and try to configure from NVMe but it is not entering boot manager.

How to fix this issue?

Below snap shot for booting issue…

Then does pressing ESC give access to the UEFI menu?

Will try this today and see, if ESC key enter UEFI menu

Also if we have internet connection it tries to boot from.https, pxe etc. Or else it says network connection not found and proceeds with normal boot.

This issue was not there when we do normal flash think.
It happens only for restored units through back and restore scripts I suppose. I need to confirm.

Even ESC key does not give access to UEFI menu nor F11 key during boot up

Hi @DaveYYY

I am getting error during restoring to nvme on a new fresh jetson orion NX module.

pls find the error logs attached for details.

Waiting for target to boot-up…
Waiting for device to expose ssh …Waiting for device to expose ssh …Device has booted into initrd. You can ssh to the target by the command:
$ ssh root@fc00:1:1:0::2
Cleaning up…
Log is saved to Linux_for_Tegra/initrdlog/flash_1-6_0_20240709-182259.log
Run command:
ln -s /proc/self/fd /dev/fd && mount -o nolock [fc00:1:1::1]:/home/trident/Downloads/r36_3_0/Linux_for_Tegra/tools/backup_restore /mnt && /mnt/nvrestore_partitions.sh -e nvme0n1 -n
on root@fc00:1:1::2
/mnt/images ~
nvrestore_partitions.sh: Use the default nvpartitionmap.txt as the index file.
40+0 records in
40+0 records out
20480 bytes (20 kB, 20 KiB) copied, 0.000460128 s, 44.5 MB/s
Error: Unable to partprobe /dev/nvme0n1
/mnt/nvrestore_partitions.sh: line 296: 667 Segmentation fault partprobe “/dev/${INTERNAL_STORAGE_DEVICE}” > /dev/null 2>&1

Note: the same back and restore script worked fine earlier for another jetson orion NX module, which we has flashed using initrd.sh flash earlier…

restore-errors_9_jul.txt (97.2 KB)
restore-serial_log_errors-nvme.txt (93.5 KB)

Then does the same disk work for that module?

As the NVMe disk are mounted and fixed, we cannot remove them anymore.

My understanding is, this error is caused as there js no partition happened on the NVMe disk.

Also this nv_restore…sh script does not has the partx command for erasing and partitioning.

Whereas release 35.5 has partx which does the erasing and partitioning of NVMe in the restore script…

Shall I copy nv_restore…sh script from 35.5 release to 36.3 release and try… I am planning this today.

Let us know your thoughts

What exact version you are using?
Why are you mixing up with 35.5 and 36.3?

36.3

As restore is giving error in 36.3 for fresh NVMe disk

This should not be an issue.
Please try another disk as I just said,

But we had successfully restored similar disk on another orion nx unit…

You mean NVMe disk mounting on the custom carrier board might be the issue?
Which is causing this error…

YES, exactly.