OTA with sda1 is not supported on jetson-xavier-nx-devkit-emmc - why?

After struggling with the tremendously cryptic scripts for over a week, I finally got to the point of being able to generate an OTA package to go from R32.7.3 to R34.5.1 this morning, only to get this message from the l4t_generate_ota_package.sh script:

OTA with sda1 is not supported on jetson-xavier-nx-devkit-emmc

… our R32.7.3 appliances all have root on a USB SSD (sda1). I’ve been working (slowly) on the upgrade to R35 for MONTHS now. Is it really true that in order to update to R35.4.1 I’m going to have to do a field visit to every single device?

More about our deployment: all the Xavier NX units we have contain a base system on the EMMC (/dev/mmcblk0p1), but because there isn’t enough room for our application, a second APP partition is on /dev/sda1, and the extlinux.conf setup boots from SDA1. This works fine, but is now causing us issues during the upgrade. I have ported our app to work on R35.4.1 and can install it, but I was relying on the OTA capability (which until 10 minutes ago I though I had) to upgrade units in the field.

What can I do here?
+j

Hi riz94107,

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

How did you create the second APP partition before?

Can you share the lsblk and ls -al /dev/disk/by-partlabel result on your board?

Are you trying to perform image-based OTA update for the SSD drive connected through USB?
It seems we support only NVMe as external device for image-based OTA.

Just by creating a gpt with partition, newfs the partition, and untar the fs onto it.

Sure. This is on an R32.7.3 board:

olyns@localhost:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0    16M  1 loop
sda            8:0    0 465.8G  0 disk
└─sda1         8:1    0  55.9G  0 part /
mtdblock0     31:0    0    32M  0 disk
mmcblk0      179:0    0  14.7G  0 disk
├─mmcblk0p1  179:1    0    14G  0 part /media/olyns/6ae0b690-ea5f-43ec-b9dd-39a81fa0
├─mmcblk0p2  179:2    0    64M  0 part
├─mmcblk0p3  179:3    0    64M  0 part
├─mmcblk0p4  179:4    0   448K  0 part
├─mmcblk0p5  179:5    0   448K  0 part
├─mmcblk0p6  179:6    0    63M  0 part
├─mmcblk0p7  179:7    0   512K  0 part
├─mmcblk0p8  179:8    0   256K  0 part
├─mmcblk0p9  179:9    0   256K  0 part
├─mmcblk0p10 179:10   0   300M  0 part
└─mmcblk0p11 179:11   0 199.1M  0 part
mmcblk0boot0 179:32   0     4M  1 disk
mmcblk0boot1 179:64   0     4M  1 disk
mmcblk0rpmb  179:96   0     4M  0 disk
zram0        252:0    0 971.5M  0 disk [SWAP]
zram1        252:1    0 971.5M  0 disk [SWAP]
zram2        252:2    0 971.5M  0 disk [SWAP]
zram3        252:3    0 971.5M  0 disk [SWAP]
olyns@localhost:~$ ls -al /dev/disk/by-partlabel
total 0
drwxr-xr-x 2 root root 260 Mar 18 01:01 .
drwxr-xr-x 8 root root 160 Mar 18 01:01 ..
lrwxrwxrwx 1 root root  10 Mar 18 01:01 APP -> ../../sda1
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel_b -> ../../mmcblk0p3
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel-bootctrl -> ../../mmcblk0p8
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel-bootctrl_b -> ../../mmcblk0p9
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel-dtb -> ../../mmcblk0p4
lrwxrwxrwx 1 root root  15 Mar 18 01:01 kernel-dtb_b -> ../../mmcblk0p5
lrwxrwxrwx 1 root root  15 Mar 18 01:01 recovery -> ../../mmcblk0p6
lrwxrwxrwx 1 root root  15 Mar 18 01:01 recovery-dtb -> ../../mmcblk0p7
lrwxrwxrwx 1 root root  16 Mar 18 01:01 RECROOTFS -> ../../mmcblk0p10
lrwxrwxrwx 1 root root  16 Mar 18 01:01 UDA -> ../../mmcblk0p11

It seems there’s only rootfs on your USB SSD drive.

You can check the partition layout XML in <Linux_for_Tegra>/tools/kernel_flash/flash_l4t_external.xml.
There should be other partitions for external storage.

I would suggest you flashing the USB SSD to update the board.
Or use NVMe SSD instead.

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