Image-based OTA update with A/B redundancy using a pre-generated system image

Hello,
I would like to know if it is possible to flash a Jetson device with a pre-generated system image using OTA update in both of the following cases:

  1. first-time setup (Jetson device is not flashed)
  2. Image update (Jetson device has a working image (incl. JetPack) that needs to be updated)

hello LNN,

please check developer guide, Updating the Rootfs Partition with a Customized Updater and Image.

‘You cannot use OTA update to update a Jetson device on which Jetpack is installed’
Does this apply to both forms of OTA?
And is this because of some size restrictions or is there another reason why it cannot be done?

it can be achieved by using a package management tool, here shows the instructions in the JetPack documentation.

So if my device has a system image (including JetPack, my app, etc
) and I want to update the app using OTA (keeping the same JetPack version), I should first remove the JetPack components, perform the update as per Image-based OTA update and then install the new JetPack components?
Is that true? or am I missing something?
Would appreciate some clarifications about the subject in the case where I got it wrong.
Thank you

hello LNN,

which release version you’re currently based-on? you may use apt upgrade for moving to the latest release.

I am currently based on L4T 32.5.
My goal is not moving to the latest release. It is rather to update my app that is running on the device keeping the same release.

hello LNN,

why don’t you just copy the updated application to the target, you may replace the binary file to update the app directly.

My goal is to have a generic solution which allows me to update my app, and also update to a newer BSP release whenever i need to

hello LNN,

you could create a *.deb package to include your app, and also other dependency files.

for example,

  1. you should create a directory for the package. please also have a DEBIAN directory,
  2. copy all the files into the directory,
  3. create a control file in the DEBIAN directory to define the mandatory fields in the control file, check this binary package control files for details.
  4. create the package, $ dpkg-deb --build <filename>
  5. you may deliver this package to other machines, and execute $ dpkg -i *.deb for installation.

Hello,
I have already succeeded to update the image on the Jetson device (without Jetpack installation) using Image Based OTA update .
I just want a confirmation that this workaround can help me bypass the issue with using OTA update on a device that has JetPack already installed.

hello LNN,

You cannot use OTA update to update a Jetson device on which Jetpack is installed.

this statement means the OTA update ($ sudo apt upgrade) process only update the BSP. (i.e. r32.5 → r32.6.1)
you’ll need to perform addition step (i.e. $ sudo apt install nvidia-jetpack) to upgrade the other JetPack components, such as CUDA toolkit, cuDNN, TensorRT
etc.

besides, you may need to remove those JetPack components only if your target’s disk space is limited. that’s the workarounds to free up additional disk space for downloading new JetPack component binaries.
thanks

1 Like

All clear! Thank you for the detailed answer

Now concerning rootfs A/B redundancy, is it enough to flash the jetson device with rootfs redundancy enabled ($ sudo ROOTFS_AB=1 ./flash.sh [options] <target_board> <rootdev>) ? Does this ensure a fail safe OTA update or is there any additional steps to be done? and what if the base release does not support rootfs redundancy (example r32.4) but the target release does (example r32.5), does that mean that the OTA update cannot be performed with rootfs redundancy enabled?

hello LNN,

ya, it depends-on the disk space.
you can use image-based OTA on a device with rootfs redundancy enabled.
the OTA update process is the same whether or not the bootloader A/B or RootFS A/B is enabled.

What I meant is:

  1. Is it enough to flash the jetson device using this command ($ sudo ROOTFS_AB=1 ./flash.sh [options] <target_board> <rootdev>) to have the device “rootfs redundancy enabled”?
  2. If so, is this supported by all BSP releases?
  3. How can I make sure that I have bootloader A/B and rootFS A/B on the target device?
  4. And since you mentioned disk space, Is there any workarounds that can be done in order to benefit from rootfs redundancy even if the target device has low disk space? For example, how to make use of the SSD in such case?

hello LNN,

it’s the simple step to add ROOTFS_AB into flash command-line to enables rootfs redundancy.
you may check the flash configuration file, p2972-0000.conf.common, it’ll load the different emmc config file for image flashing.
for example,

# Rootfs A/B:
if [[ "${ROOTFS_AB}" == 1 && "${ROOTFS_ENC}" == "" ]]; then
        rootfs_ab=1;
        EMMC_CFG=flash_t194_sdmmc_rootfs_ab.xml;
        ROOTFSSIZE=14GiB;
        SMDFILE="slot_metadata.bin.rootfsAB";

A/B Root File System redundancy is included in JetPack-4.6,
please check JetPack SDK | NVIDIA Developer for the JetPack-4.6 key features.

you may also have your own customization, please check developer guide for the details, Root File System Redundancy.
once you’ve flashed with bootloader A/B or rootFS A/B, you may review your partition layouts for confirmation.
for example, check the partition label, $ ls -al /dev/disk/by-partlabel

there’s new flashing tool to flash external media,
please access the developer guide and check Flashing with initrd for reference,

furthermore,
suggest you should initial another new discussion thread for tracking your specific questions.
thanks

1 Like

Thank you for your quick response.

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