JetPack 5.1.2 → 6.2 OTA fails or succeeds depending on A/B slot state

musa6 · April 21, 2026, 9:39am

Environment:

Device: Jetson Orin NX (devkit)
Storage: NVMe (128GB)
Base JetPack: 5.1.2
Target JetPack: 6.2
Rootfs A/B enabled (ROOTFS_AB=1)

Flash Command (JetPack 5.1.2)

sudo ROOTFS_AB=1 ./tools/kernel_flash/l4t_initrd_flash.sh \
  --sparse \
  --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_nvme_rootfs_ab.xml \
  -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --network usb0 \
  jetson-orin-nano-devkit \
  internal

OTA Payload Generation
5.1.2 → 5.1.3

sudo ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh \
  --external-device nvme0n1 \
  jetson-orin-nano-devkit \
  R35-4

5.1.3 → 6.2

sudo ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh \
  --external-device nvme0n1 \
  jetson-orin-nano-devkit \
  R35-5

Issue Summary
OTA to JetPack 6.2 behaves inconsistently depending on which slot is targeted, even though both slots originate from the same 5.1.2 flash.

Case 1 (Fails)

Flash 5.1.2 → boot Slot A
OTA → 5.1.3 → updates Slot B → boot Slot B
OTA → 6.2 → updates Slot A

Result:
OTA reports success but:

Target partition has no filesystem (lsblk -f)
Device enters reboot loop

Case 2 (Succeeds)

Flash 5.1.2 → boot Slot A
Manually switch to Slot B:

$ sudo nvbootctrl set-active-boot-slot 1
$ reboot

3. OTA → 5.1.3 → updates Slot A → boot Slot A
4. OTA → 6.2 → updates Slot B

Result:

OTA completes successfully
Device boots into JetPack 6.2

Additional Observation
If both slots are first updated to JetPack 5.1.3, OTA to 6.2 works reliably regardless of which slot is targeted.
This suggests that once both slots have gone through a 5.1.3 OTA cycle, they reach a consistent state (in terms of partition layout, filesystem initialization, and slot metadata), eliminating the failure seen when one slot remains in its original 5.1.2 flash state.

Question
Why does OTA update to 6.2 fail when targeting slot A (on 5.1.2) from slot B (on 5.1.3) but succeed when targeting Slot B (on 5.1.2) from slot A (on 5.1.3), even though both were originally identical?
Does this suggests OTA success depends on slot state (activation/initialization history), not just JetPack version.

Any official guidance on correct A/B slot handling for JetPack 6.x OTA would be helpful.

carolyuu · April 21, 2026, 9:54am

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

The issue described is related to the inconsistent behavior of OTA (Over-the-Air) updates on the Jetson Orin NX device, specifically when updating from JetPack 5.1.2 to JetPack 6.2. The problem arises when the update is targeted at a specific slot (A or B) on the device, and the behavior differs depending on the slot’s state and history.

To understand this issue, let’s break down the key points:

Slot A and Slot B: The Jetson Orin NX device has two slots, A and B, which can be used for AB updates. Both slots originate from the same 5.1.2 flash.
OTA update behavior: When updating from 5.1.2 to 6.2, the behavior differs depending on which slot is targeted. If Slot A is targeted, the update fails, while targeting Slot B succeeds.
Slot state and history: The issue seems to be related to the state and history of the slots. When both slots have gone through a 5.1.3 OTA cycle, they reach a consistent state, and the update to 6.2 works reliably regardless of which slot is targeted.

Now, let’s analyze the possible reasons behind this behavior:

Partition layout and filesystem initialization: The OTA update process involves updating the partition layout and initializing the filesystem. It’s possible that the update process is not correctly handling the partition layout and filesystem initialization when targeting Slot A on 5.1.2 from Slot B on 5.1.3.
Slot metadata: The slot metadata, which includes information about the slot’s state and history, might be playing a role in the update process. The fact that the update succeeds when targeting Slot B on 5.1.2 from Slot A on 5.1.3 suggests that the slot metadata is being correctly updated and used during the update process.
AB slot handling: The issue might be related to how the AB slots are handled during the OTA update process. It’s possible that the update process is not correctly handling the AB slots, leading to inconsistent behavior.

To resolve this issue, it’s recommended to follow these best practices for AB slot handling:

Ensure consistent slot state: Before performing an OTA update, ensure that both slots have the same state and history. This can be achieved by updating both slots to the same version (e.g., 5.1.3) before attempting to update to 6.2.
Use the correct update sequence: When updating from 5.1.2 to 6.2, use the correct update sequence. First, update Slot A to 5.1.3, then update Slot B to 5.1.3, and finally update both slots to 6.2.
Verify slot metadata: Verify that the slot metadata is correctly updated and used during the update process.

In terms of official guidance, NVIDIA recommends following the best practices for AB slot handling, as outlined above. Additionally, NVIDIA provides documentation on the OTA update process and AB slot handling in the JetPack 6.2 documentation.

In summary, the inconsistent behavior of OTA updates on the Jetson Orin NX device is likely related to the state and history of the slots, as well as the partition layout and filesystem initialization. By following best practices for AB slot handling and ensuring consistent slot state, you can minimize the risk of update failures and ensure a successful update to JetPack 6.2.

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

talha3 · April 21, 2026, 10:19am

You mentioned that we need to update both slots to the same JetPack version first. However, the issue is that when we flash the device with JetPack 5.1.2, switch from slot A to slot B, and then update to 5.1.3, the update completes successfully. After that, when we perform another update from JetPack 5.1.3 to 6.1.2 (again switching from slot A to slot B), it also completes successfully.

This suggests that there may not be a strict requirement for both slots to have the same JetPack version.

What could be the root cause of this behavior? Is there a possible bug in the NVIDIA workflow? Requiring both slots to have the same JetPack version adds an extra step and complexity. I also haven’t found any documentation or forum discussions from NVIDIA that clearly mention this requirement.

How can I identify the real cause of this issue?

JerryChang · April 22, 2026, 5:59am

hello musa6,

as mentioned by developer guide,
Updating Jetson Linux with Image-Based Over-the-Air Update

It is necessary to upgrade both chains to this release by performing the OTA update twice.

musa6 · April 22, 2026, 7:15am

Thanks for the clarification.

We tested this approach, and confirming that upgrading both slots (chains) to JetPack 5.1.3 before attempting 6.2 OTA works reliably. Once both slots are on 5.1.3, the 6.2 update succeeds regardless of which slot is targeted.

However, we observed a behavior that we would like to better understand:

When starting from:

Slot A → JetPack 5.1.2 (post-flash)
Slot B → updated to JetPack 5.1.3 via OTA

We see that:

OTA to 6.2 fails when targeting Slot A (still on 5.1.2) while running from Slot B (5.1.3)
OTA to 6.2 succeeds when targeting Slot B (still on 5.1.2) while running from Slot A (5.1.3)

Question:

Could you clarify that why a slot still on 5.1.2 can succeed as an OTA target in one case but fail in another?

Thanks.

2759897880 · April 22, 2026, 7:30am

Hello Musa6,
I also encountered a similar problem like yours. Could you please tell me how you upgraded both slots to version 5.1.3? My first OTA operation was able to upgrade the bootloadB slot to 5.1.3, while the A slot remained at 5.1.1. However, when I attempted to repeat the OTA upgrade to bring the A slot up to 5.1.3, I received the following prompt:

get_update_control /ota_work UPDATE_BOOTLOADER UPDATE_ROOTFS
UPDATE_BOOTLOADER=1, UPDATE_ROOTFS=1
select_uefi_capsule /ota_work
check_bsp_version /ota_work BASE_VERSION
The version of OTA package(R35-3) does not match the version of current system(R35-5), please check whether the OTA package is correct
Failed to run “check_bsp_version /ota_work BASE_VERSION”

This log seems to indicate that the OTA tool detected that my system is already at version 5.1.3, but the BASE VERSION of my OTA tool is 5.1.1, which is why it prevented me from performing the OTA operation.

Any assistance would be greatly appreciated.

musa6 · April 22, 2026, 7:33am

Hi,

Yes, first tell me that are you using the same payload and ota tools, which use used to update jetpack 5.1.1 to 5.1.3, for this update ( 5.1.3 to 5.1.3 )?

2759897880 · April 22, 2026, 7:48am

Hi,

Thank you very much for your reply.

Yes, I repeated the operation again to ensure it was correct. Here is my log:

zzd@zzd-desktop:~$ cd $WORKDIR
zzd@zzd-desktop:~/temp$ cd $WORKDIR/Linux_for_Tegra/tools/
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools$ ls
ota_tools
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools$ sudo rm -rf ota_tools/
[sudo] password for zzd: 
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools$ 
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools$ scp -r zzd@192.168.4.148:/disk/E/NVIDIA/JP5.1.3/Linux_for_Tegra/tools/ota_tools .
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools$ cd /ota/
zzd@zzd-desktop:/ota$ ls
ota_payload_package.tar.gz
zzd@zzd-desktop:/ota$ sudo rm -rf ota_payload_package.tar.gz 
zzd@zzd-desktop:/ota$ sudo scp zzd@192.168.4.148:/disk/E/NVIDIA/JP5.1.3/Linux_for_Tegra/bootloader/recomputer-orin/ota_payload_package.tar.gz .
zzd@192.168.4.148's password: 
ota_payload_package.tar.gz                                                                                                                                                       100% 8349MB  93.6MB/s   01:29    
zzd@zzd-desktop:/ota$ cd ${WORKDIR}/Linux_for_Tegra/tools/ota_tools/version_upgrade
zzd@zzd-desktop:~/temp/Linux_for_Tegra/tools/ota_tools/version_upgrade$ sudo ./nv_ota_start.sh /ota/ota_payload_package.tar.gz
Command: ./nv_ota_start.sh /ota/ota_payload_package.tar.gz
Current rootfs is on /dev/nvme0n1
init_ota_log /ota_log
Create log file at /ota_log/ota_20260422-033914.log
OTA_LOG_FILE=/ota_log/ota_20260422-033914.log
Extract /ota/ota_payload_package.tar.gz
update_nv_boot_control_in_rootfs /ota_work
3767--0003--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: nvme0n1
Info. Legacy mode: false
TNSPEC 3767-300-0003-P.1-1-0-recomputer-orin-
COMPATIBLE_SPEC 3767--0003--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE nvme0n1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3767--0003--1--jetson-orin-nano-devkit-.
Info. Uninstalling mtdblock.
check_prerequisites
decompress_ota_package ota_package.tar /ota_work
decompress_ota_package: start at Wed 22 Apr 2026 03:41:03 AM EDT
Sha1 checksum for /ota_work/ota_package.tar (fe7e6a3860737556ecc6d6610c4b501c38d7d98a) matches
decompress_ota_package: end at Wed 22 Apr 2026 03:42:47 AM EDT
nv_ota_update_without_layout_change.sh
Command: nv_ota_update_without_layout_change.sh
check_target_board /ota_work TARGET_BOARD
get_chip_id CHIP_ID
ota_choose_images /ota_work
COMPATIBLE_SPEC=3767--0003--1--jetson-orin-nano-devkit-
TEGRA_CHIPID=0x23
_BOARD_SPEC_NAME=3767--0003-
Copy files from ./images-R35-ToT/3767--0003-/ to ./images-R35-ToT/
is_rootfs_a_b_enabled ROOTFS_AB_ENABLED ROOTFS_CURRENT_SLOT
ROOTFS_AB_ENABLED=0
ROOTFS_CURRENT_SLOT=0
is_rootfs_encryption_enabled ROOTFS_ENC_ENABLED
ROOTFS_ENC_ENABLED=0
get_update_slot UPDATE_SLOT
UPDATE_SLOT=B
get_update_control /ota_work UPDATE_BOOTLOADER UPDATE_ROOTFS
UPDATE_BOOTLOADER=1, UPDATE_ROOTFS=1
select_uefi_capsule /ota_work
check_bsp_version /ota_work BASE_VERSION
The version of OTA package(R35-3) does not match the version of current system(R35-5), please check whether the OTA package is correct
Failed to run "check_bsp_version /ota_work BASE_VERSION"

zzd@zzd-desktop:~$ sudo nvbootctrl dump-slots-info
Current version: 35.5.0
Capsule update status: 0
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal

zzd@zzd-desktop:~$ sudo nvbootctrl dump-slots-info
Current version: 35.3.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal

musa6 · April 22, 2026, 7:58am

GIve me the command you use to create your ota payload.

2759897880 · April 22, 2026, 8:05am

Hi,

Here is the command I used to create the OTA payload (I am using a custom board, but I have already made the adaptation):

sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh   --external-device nvme0n1 -S 80GiB recomputer-orin R35-3

musa6 · April 22, 2026, 8:16am

Yes, here is the problem. You are using the payload created for update 5.1.1 to 5.1.3. You will need to create a new payload to update 5.1.3 to 5.1.3:

cd < 5.1.3 Linux_for_tegra directory >
sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh  --external-device nvme0n1 -S 80GiB recomputer-orin R35-5

Note: Use the 5.1.3 jetpack ota tools when upgrading from 5.1.3 to 5.1.3

Also, have you set ROOTFS_AB=1 as an environment variable ?

I recommend parsing it to the payload command:

sudo ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh   --external-device nvme0n1 -S 80GiB recomputer-orin R35-5

2759897880 · April 22, 2026, 11:03am

Hi musa6,

After your correction, I have successfully upgraded to the latest version. Regarding the issue you mentioned about adding ROOTFS_AB=1, I would like to share that our customized carrier board currently has only one partition and has not been partitioned into A/B, so this does not need to be added.

In short, thank you very much for your help. It is my pleasure to have contacted you. I wish you happiness every day!

Topic		Replies	Views
Regarding the startup issues from 5.1.1 ota to 6.2.2 Jetson Orin Nano boot , ota , jetson	5	69	April 24, 2026
OTA update from JetPack 6.2.0 to 6.2.1 fail Jetson Orin Nano ota	20	557	November 4, 2025
Image-based OTA update for JetPack 5.1.3 Jetson Orin Nano ota	5	777	March 4, 2024
Redundant A/B rootfs does not switch automatically after OTA Jetson AGX Xavier boot , security	24	478	September 18, 2025
Transition from Jetpack 5 to Jetpack 6 Jetson Orin NX security , ota	3	345	August 19, 2025
OTA Update from 5.1.2 to 6.1 using Jetson Orin NX	6	304	August 7, 2025
After OTA update the version of Jetpack stays the same but should be updated Jetson AGX Xavier ota	5	841	April 27, 2023
The image-based OTA upgrade shows success, but after reboot, slot 1 fails to boot Jetson AGX Orin ota	13	107	February 3, 2026
OTA JP6.2.2 to JP6.2.2 support question Jetson AGX Orin ota	1	78	May 7, 2026
Issue that OTA works on some Jetsons but not others Jetson AGX Orin ota , uefi	44	891	July 16, 2025

JetPack 5.1.2 → 6.2 OTA fails or succeeds depending on A/B slot state

Related topics