Issue with restore clone.img(JP6.1) on Orin NX

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
,
1

Hi,
In JP6.1, I used NVIDIA’s documentation for cloning the rootfs to generate clone.img. Then, I successfully flashed the image using the command:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0 --massflash 1

But the system failed to start properly, displaying the error shown in the attached image.

message
message1920×321 92.8 KB

I found that the issue was caused by the /etc/fstab file, which still contained the previous hard drive configuration:

cat /etc/fstab 
# /etc/fstab: static file system information.
#
# These are the filesystems that are always mounted on boot, you can
# override any of these by copying the appropriate line from this file into
# /etc/fstab and tweaking it as you see fit.  See fstab(5).
#
# <file system> <mount point>             <type>          <options>     <dump> <pass>
/dev/root            /                     ext4           defaults           0 1
UUID=FB2A-A65C /boot/efi vfat defaults 0 1

After removing this UUID entry, the system was able to boot normally. However, a new configuration UUID entry is automatically generated in the fstab file.
I checked the fstab configuration in JP6.0 and noticed that it does not include any UUID entry.
What is the purpose of this configuration? Is there a way to prevent it from being generated?

3

Hi Wavee,

Are you using the devkit or custom board for Orin NX?

Is the issue specific to JP6.1?

How did you create mfi package before flash?

How about if you configure it the same as JP6.0?

5

Hi:
I use custom board.

The command to create the mfi package is:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1 -S 55GiB -c ./tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --massflash 5 --network usb0 jetson-orin-nano-devkit nvme0n1p1

If remove the UUID configuration in fstab and reboot, the system can boot normally, but the UUID configuration is restored.

I think this issue arises in JP6.1, when I clone JP6.0 rootfs, there was no UUID configuration in the fstab.

Using grep, I found that the issue might be caused by lines 828 to 898 in the file Linux_for_Tegra/rootfs/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh.
Comparing the nv-l4t-bootloader-config.sh files in JP6.0 and JP6.1, I noticed that this part was newly added.
nv-l4t-bootloader-config.sh-JP6.0.txt (18.8 KB)
nv-l4t-bootloader-config.sh-JP6.1.txt (29.0 KB)

7

Hi KevinFFF, hi Wavee

We came across the same issue when using the l4t_backup_restore.sh approach, on every boot, the efi entry is added to the fstab. So before taking a backup image, we had to remove the entry from the fstab and then take the backup. Otherwise, when restoring to a different carrier board, the system would be stuck on boot.
Is this behavior wanted?

8

Hi sevm89

I deleting the EFI entry from fstab before creating a backup image, and the clone.img restoring to another board can boot normally.

I also tried commenting out lines 870-871 in /Linux_for_Tegra/rootfs/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh during system customization. This prevented the EFI entry from appearing in fstab, and the system can boot normally.

# Configure the /etc/fstab to mount esp automatically at boot time.
# sed -i '/UUID='"${esp_uuid}"'/d' "${FS_TABLE}"
# sed -i '$a\UUID='"${esp_uuid}"' '"${ESP_MOUNT_POINT}"' vfat defaults 0 1' "${FS_TABLE}"

I’m not sure which method is appropriate, nor do I know if this behavior is necessary.

9

Hi Wavee,

Do you mean the issue is caused from mount_esp() in nv-l4t-bootloader-config.sh?

It is used to mount esp partition automatically.
If you don’t have it, then you might get failed during OTA since it cannot update esp partition.

As the WAR, you can remove UUID entry in /etc/fstab before creating clone image.

11

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