Nvme0n1p1 not found - Restore image failed

Hi all,
I created an image of my ORIN NX with a Seeedstudio A603 using:

sudo ./tools/backup_restore/l4t_backup_restore.sh -b p3509-a02+p3767-0000

Jetpack 5.1.2
As SSD I used a KingSpec 1TB M.2 2242 NVMe SSD - M.2 PCIe 3.0x4

I can correctly see the partitions saved here:

gorgo@razer:/media/gorgo/PopOS/home/gorgo/ORIN_RT_5_1_2/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra$ ll tools/backup_restore/images/
total 15622108
drwxr-xr-x 3 root root 4096 apr 23 11:18 ./
drwxr-xr-x 3 root root 4096 mar 1 15:27 …/
-rw-r–r-- 1 root root 16896 apr 23 10:48 gptbackup.img
-rw-r–r-- 1 root root 20480 apr 23 10:48 gptmbr.img
-rw-r–r-- 1 root root 1407123 apr 23 11:18 nvme0n1p10_bak.img
-rw-r–r-- 1 root root 332878 apr 23 11:18 nvme0n1p11_bak.img
-rw-r–r-- 1 root root 504948 apr 23 11:18 nvme0n1p12_bak.img
-rw-r–r-- 1 root root 4608 apr 23 11:18 nvme0n1p13_bak.img
-rw-r–r-- 1 root root 292755 apr 23 11:18 nvme0n1p14_bak.img
-rw-r–r-- 1 root root 15802265637 apr 23 11:05 nvme0n1p1.tar.gz
-rw-r–r-- 1 root root 37801401 apr 23 11:18 nvme0n1p2_bak.img
-rw-r–r-- 1 root root 312317 apr 23 11:18 nvme0n1p3_bak.img
-rw-r–r-- 1 root root 9254801 apr 23 11:18 nvme0n1p4_bak.img
-rw-r–r-- 1 root root 46768185 apr 23 11:18 nvme0n1p5_bak.img
-rw-r–r-- 1 root root 77752 apr 23 11:18 nvme0n1p6_bak.img
-rw-r–r-- 1 root root 146388 apr 23 11:18 nvme0n1p7_bak.img
-rw-r–r-- 1 root root 30584777 apr 23 11:18 nvme0n1p8_bak.img
-rw-r–r-- 1 root root 77752 apr 23 11:18 nvme0n1p9_bak.img
-rw-r–r-- 1 root root 1817 apr 23 11:18 nvpartitionmap.txt
-rw-r–r-- 1 root root 67108864 apr 23 10:48 QSPI0.img
drwxr-xr-x 3 root root 4096 apr 23 10:48 tmp/

When I have to restore the image the problems start.
If I used a new KingSpec 1TB M2 ssd, everything works like expected and I can boot into the image.
I bought some Corsair MP600 Micro 1TB M.2 NVMe PCIe x4 Gen4 2 SSD - M.2 2242 which shall perform better.

Initially I flash the brand new Orin NX with the Corsair SSD with:

sudo ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3509-a02+p3767-0000 internal

The flashing works and I can boot into the vanilla Jetpack 5.1.2.

I eventually put my Orin into recovery and I restore the image previously created.
The flashing procedure finished correctly:

restore_log.log (112.3 KB)

Unfortunately the boot doesn’t complete correctly and I eventually get:

[ 2.831358] Root device found: nvme0n1p1

[ 2.907885] usb 1-3: new full-speed USB device number 3 using tegra-xusb

[ 3.037778] usb 1-3: New USB device found, idVendor=8087, idProduct=0a2b, bcdDevice= 0.10

[ 3.037784] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[ 5.201091] random: crng init done

[ 12.969082] ERROR: nvme0n1p1 not found

Full boot log:
boot_corsair.log (83.0 KB)

Note:

  • I formatted the SSD to ext4 before running l4t_initrd_flash.sh
  • In the image I created I changed the root bootarg to:

APPEND ${cbootargs} root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb

I manually set /dev/nvme0n1p1 because in my previous test I got a similar ‘not found’ error with the old PARTUID.

Any clue?

I don’t know if it helps, but if I read the ssd with an external driver AFTER restoring, I get the following error with gparted:

gorgo@razer:~/drone-racing/src/drone-controllers$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by write.
The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Command (m for help): p

Disk /dev/sda: 931,53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: RTL9210B-CG
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2251D0CF-C792-4C28-85E2-087D39FD950C

Device Start End Sectors Size Type
/dev/sda1 1863208 1953523239 1951660032 930,6G Microsoft basic data
/dev/sda2 40 262183 262144 128M Microsoft basic data
/dev/sda3 262184 263719 1536 768K Microsoft basic data
/dev/sda4 263720 328487 64768 31,6M Microsoft basic data
/dev/sda5 328488 590631 262144 128M Microsoft basic data
/dev/sda6 590632 592167 1536 768K Microsoft basic data
/dev/sda7 592168 656935 64768 31,6M Microsoft basic data
/dev/sda8 656936 820775 163840 80M Microsoft basic data
/dev/sda9 820776 821799 1024 512K Microsoft basic data
/dev/sda10 821800 1436199 614400 300M Microsoft basic data
/dev/sda11 1436200 1567271 131072 64M EFI System
/dev/sda12 1567272 1731111 163840 80M Microsoft basic data
/dev/sda13 1731112 1732135 1024 512K Microsoft basic data
/dev/sda14 1732136 1863207 131072 64M Microsoft basic data

Partition table entries are not in disk order.

Is this issue specific to this disk?
Like if you format the original KingSpec SSD, then does it work after restoring?

Hi @DaveYYY
Yes the issue seems specific to the disk. The disk is not broken out-of-the-box since I can flash a vanilla Jetpack and run it. The issue is related to the restore process from an image created with the kingspec ssd.

I formatted the KingSpec SSD to ext4 and restore the image:
kingssd_restore.log (112.2 KB)

The orin boots and I can login into the restored image:

boot_kingspec.log (81.5 KB)

Then what if you do the same on the Corsair one?

I get the behavior I reported in the first topic. (Check the boot_corsair.log)
In addition, I’m testing the Corsair flashed image with gdisk:

gorgo@razer:/media/gorgo/PopOS/home/gorgo/ORIN_RT_5_1_2/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use ‘v’ to
verify disk integrity, and perhaps options on the experts’ menu to repair
the disk.
Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don’t match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.


Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: main GPT header’s backup LBA pointer (2000409263) doesn’t
match the backup GPT header’s current LBA pointer (1953525167).
The ‘e’ option on the experts’ menu may fix this problem.

Problem: main GPT header’s last usable LBA pointer (2000409224) doesn’t
match the backup GPT header’s last usable LBA pointer (1953525128)
The ‘e’ option on the experts’ menu can probably fix this problem.

Problem: main header’s disk GUID (74965ED3-D5D4-40CE-8176-6859A2889A2B) doesn’t
match the backup GPT header’s disk GUID (2251D0CF-C792-4C28-85E2-087D39FD950C)
You should use the ‘b’ or ‘d’ option on the recovery & transformation menu to
select one or the other header.

Problem: Disk is too small to hold all the data!
(Disk size is 1953525168 sectors, needs to be 2000409264 sectors.)
The ‘e’ option on the experts’ menu may fix this problem.

Warning: There is a gap between the main partition table (ending sector 33)
and the first usable sector (40). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using ‘j’ on the experts’ menu can adjust this gap.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 2000409224, but backup header is at
2000409263 and disk size is 1953525168 sectors.
The ‘e’ option on the experts’ menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 8 problems!

I don’t think it’s related to Jetson in any aspect.
Please make sure the disk functions normally at least on your host PC.

Sorry @DaveYYY but I don’t agree with you in this case. The disk stops working after restoring the saved image with sudo ./tools/backup_restore/l4t_backup_restore.sh -r p3509-a02+p3767-0000. I told you it works normally if I flash the Jetpack only. I’m seeking help with making it work after the restore process.
Both the SSDs are 1TB (Kingspec is PCIe 3.0x4 while Corsair is PCIe x4 Gen4).
You’re definitely more knowledgeable about how the Jetpack manages the 14 different partitions.

Run w in gdisk so it writes the partition table again.

Yes I’ve just fixed altering the partition table:

gorgo@razer:/media/gorgo/PopOS/home/gorgo/ORIN_RT_5_1_2/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by write.
The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Command (m for help): m

Help:

GPT
M enter protective/hybrid MBR

Generic
d delete a partition
F list free unpartitioned space
l list known partition types
n add a new partition
p print the partition table
t change a partition type
v verify the partition table
i print information about a partition

Misc
m print this menu
x extra functionality (experts only)

Script
I load disk layout from sfdisk script file
O dump disk layout to sfdisk script file

Save & Exit
w write table to disk and exit
q quit without saving changes

Create a new label
g create a new empty GPT partition table
G create a new empty SGI (IRIX) partition table
o create a new empty DOS partition table
s create a new empty Sun partition table

Command (m for help): d
Partition number (1-14, default 14): 1

Partition 1 has been deleted.

Command (m for help): p
Disk /dev/sda: 931,53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: RTL9210B-CG
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2251D0CF-C792-4C28-85E2-087D39FD950C

Device Start End Sectors Size Type
/dev/sda2 40 262183 262144 128M Microsoft basic data
/dev/sda3 262184 263719 1536 768K Microsoft basic data
/dev/sda4 263720 328487 64768 31,6M Microsoft basic data
/dev/sda5 328488 590631 262144 128M Microsoft basic data
/dev/sda6 590632 592167 1536 768K Microsoft basic data
/dev/sda7 592168 656935 64768 31,6M Microsoft basic data
/dev/sda8 656936 820775 163840 80M Microsoft basic data
/dev/sda9 820776 821799 1024 512K Microsoft basic data
/dev/sda10 821800 1436199 614400 300M Microsoft basic data
/dev/sda11 1436200 1567271 131072 64M EFI System
/dev/sda12 1567272 1731111 163840 80M Microsoft basic data
/dev/sda13 1731112 1732135 1024 512K Microsoft basic data
/dev/sda14 1732136 1863207 131072 64M Microsoft basic data

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

gorgo@razer:/media/gorgo/PopOS/home/gorgo/ORIN_RT_5_1_2/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition number (1,15-128, default 1): 1
First sector (1863208-1953525128, default 1863680): 1863208
Last sector, +/-sectors or +/-size{K,M,G,T,P} (1863208-1953525128, default 1953525128):

Created a new partition 1 of type ‘Linux filesystem’ and of size 930,6 GiB.
Partition #1 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: N

Command (m for help): w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

The problem probably came from the smaller size of the Corsair compared to Kingspec even if both claimed 1TB.
Resizing APP partition fixed the issue

1 Like

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