Jetson NX upgrade from JP5.1 to JP5.1.2

Hello, I have followed the instructions as mentioned to update the Jetpack from 5.1 to 5.1.2 -

  1. edit etc/apt/sources.list.d/nvidia-l4t-apt-source.list to r35.4
  2. sudo apt update
  3. sudo apt dist-upgrade

I have faced the following two error scenarios -

  1. Upgrade to L35.4 - #5 by DaveYYY
  2. Upgrade to L35.4 - #10 by KerseyFabrications

There is no feasibility of accessing Orin NX physically to reflash it using mass flash or SDK. The update has to happen via the terminal only.

What are the proper steps and is there any documentation I can look at?

This is the error after - sudo apt update followed by sudo apt upgrade.

DevKit or custom carrier board?
Also, don’t put any log as screenshots. They are not preferred; put them as text file, please.

Hello Dave, this is on a custom carrier board.

Then you are not allowed to do sudo apt dist-upgrade here, as these debian packages are only meant to be used with DevKits, and we don’t know what customization people are doing with their custom carrier boards.
If you cannot access the device physically, then there is nothing you can do and it’s gone.

Hi @DaveYYY, I am working with @sanket193 on this issue.

Our custom carrier board is compatible with the nVidia-provided Orin NX Devkit board configuration files. We have some extra hardware built-in to the board to manage peripherals (i2c interfaces, camera interfaces, etc.) and we lack the cvb/cvm EEPROM that is in the devkit. I do not see how these changes should impact our upgrade from jetpack 5.1 to jetpack 5.1.2.

If we shouldn’t run sudo apt dist-upgrade, what method would nVidia recommend to force an upgrade to 5.1.2, even if it’s not officially supported?

The error log told you that it failed with nvidia-l4t-kernel-dtbs, which is clearly related to your customized hardware. I don’t know why you think it would work.

Please use image-based OTA with all your customization included.
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/SoftwarePackagesAndTheUpdateMechanism.html#updating-jetson-linux-with-image-based-over-the-air-update

HI @DaveYYY,

Thanks for the reply, we will continue to look into image-based OTA.

I am currently trying to understand the errors that we see in the update process.

After following the commands to update to a new minor release (located here), we have the dpkg errors that were seen in the original post of this topic

dpkg: error processing package nvidia-l4t-kernel-dtbs (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-l4t-kernel
 nvidia-l4t-kernel-headers
 nvidia-l4t-jetson-io
 nvidia-l4t-display-kernel
 nvidia-l4t-kernel-dtbs
E: Sub-process /usr/bin/dpkg returned an error code (1)

However, running cat /etc/nv_tegra_release shows the following output:

# R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug  1 19:57:35 UTC 2023

And running uname -r gives the following output:

5.10.120-tegra

This all points to the system being updated to L4T 35.4.1 and JetPack 5.1.2.

Is there any way we can fix the dependency problems that are outlined in the full error excerpt below?

Reading package lists... Done
Building dependency tree       
Reading state information... Done
htop is already the newest version (2.2.0-2build1).
The following packages were automatically installed and are no longer required:
  fltk1.3-doc fluid fonts-lato freeglut3-dev gazebo11 gazebo11-common gazebo11-plugin-base gir1.2-goa-1.0 gir1.2-gst-plugins-bad-1.0 hddtemp ignition-tools libassimp-dev libassimp5 libavdevice-dev libavfilter-dev libbullet-dev libbullet2.88 libccd-dev libccd2
  libdart-collision-bullet-dev libdart-collision-ode-dev libdart-dev libdart-external-ikfast-dev libdart-external-odelcpsolver-dev libdart-utils-dev libdart-utils-urdf-dev libdart6 libdart6-collision-bullet libdart6-collision-ode libdart6-external-odelcpsolver libdart6-utils
  libdart6-utils-urdf libexif-dev libfcl-dev libfcl0.5 libfltk-cairo1.3 libfltk-forms1.3 libfltk-gl1.3 libfltk-images1.3 libfltk1.3 libfltk1.3-dev libfreeimage-dev libfreeimage3 libfwupdplugin1 libgazebo11 libgazebo11-dev libgdcm-dev libgphoto2-dev libgts-dev
  libignition-cmake2-dev libignition-common3 libignition-common3-av libignition-common3-av-dev libignition-common3-core-dev libignition-common3-dev libignition-common3-events libignition-common3-events-dev libignition-common3-graphics libignition-common3-graphics-dev
  libignition-common3-profiler libignition-common3-profiler-dev libignition-fuel-tools4 libignition-fuel-tools4-dev libignition-math6 libignition-math6-dev libignition-msgs5 libignition-msgs5-dev libignition-tools-dev libignition-transport8 libignition-transport8-core-dev
  libignition-transport8-dev libignition-transport8-log libignition-transport8-log-dev libilmbase-dev libjxr0 libnorm-dev liboctomap-dev liboctomap1.9 libode-dev libode8 libogre-1.9-dev libogre-1.9.0v5 libopenexr-dev libpgm-dev libprotoc-dev libpyside2-dev libpyside2-py3-5.14
  libqwt-qt5-6 libqwt-qt5-dev libruby2.7 libsdformat9 libsdformat9-dev libshiboken2-dev libshiboken2-py3-5.14 libsimbody-dev libsimbody3.6 libsodium-dev libspnav0 libtar-dev libtar0 libtinyxml-dev liburdfdom-dev liburdfdom-headers-dev liburdfdom-model liburdfdom-model-state
  liburdfdom-sensor liburdfdom-world libxmlb1 libxmu-dev libxmu-headers libyaml-dev libzip-dev libzip5 libzmq3-dev libzzip-0-13 nsight-systems-2022.5.2 pyqt5-dev python3-opengl python3-pyqt5.qtopengl python3-pyqt5.qtsvg python3-pyqt5.qtwebkit python3-pyside2.qtcore
  python3-pyside2.qtgui python3-pyside2.qtsvg python3-pyside2.qtwidgets python3-sip-dev rake ros-noetic-actionlib-tutorials ros-noetic-angles ros-noetic-bond-core ros-noetic-camera-calibration ros-noetic-camera-info-manager ros-noetic-cmake-modules ros-noetic-common-msgs
  ros-noetic-common-tutorials ros-noetic-compressed-image-transport ros-noetic-control-msgs ros-noetic-control-toolbox ros-noetic-controller-interface ros-noetic-controller-manager ros-noetic-controller-manager-msgs ros-noetic-depth-image-proc ros-noetic-desktop
  ros-noetic-diagnostic-analysis ros-noetic-diagnostic-common-diagnostics ros-noetic-diagnostics ros-noetic-diff-drive-controller ros-noetic-executive-smach ros-noetic-filters ros-noetic-forward-command-controller ros-noetic-gazebo-dev ros-noetic-gazebo-msgs
  ros-noetic-gazebo-plugins ros-noetic-gazebo-ros ros-noetic-gazebo-ros-control ros-noetic-gazebo-ros-pkgs ros-noetic-geometry ros-noetic-geometry-tutorials ros-noetic-gl-dependency ros-noetic-hardware-interface ros-noetic-image-common ros-noetic-image-pipeline
  ros-noetic-image-proc ros-noetic-image-publisher ros-noetic-image-rotate ros-noetic-interactive-marker-tutorials ros-noetic-interactive-markers ros-noetic-joint-limits-interface ros-noetic-joint-state-controller ros-noetic-joint-state-publisher
  ros-noetic-joint-state-publisher-gui ros-noetic-kdl-parser ros-noetic-laser-assembler ros-noetic-laser-filters ros-noetic-laser-geometry ros-noetic-laser-pipeline ros-noetic-librviz-tutorial ros-noetic-map-msgs ros-noetic-media-export ros-noetic-mk ros-noetic-nodelet-core
  ros-noetic-nodelet-tutorial-math ros-noetic-perception-pcl ros-noetic-pluginlib-tutorials ros-noetic-polled-camera ros-noetic-position-controllers ros-noetic-python-qt-binding ros-noetic-qt-dotgraph ros-noetic-qt-gui ros-noetic-qt-gui-cpp ros-noetic-qt-gui-py-common
  ros-noetic-qwt-dependency ros-noetic-realtime-tools ros-noetic-robot ros-noetic-robot-state-publisher ros-noetic-ros ros-noetic-ros-base ros-noetic-ros-comm ros-noetic-ros-core ros-noetic-ros-tutorials ros-noetic-rosbag-migration-rule ros-noetic-rosbash ros-noetic-rosboost-cfg
  ros-noetic-roscpp-core ros-noetic-roscpp-tutorials ros-noetic-roscreate ros-noetic-roslang ros-noetic-roslint ros-noetic-roslisp ros-noetic-rosmake ros-noetic-rospy-tutorials ros-noetic-rqt-action ros-noetic-rqt-bag ros-noetic-rqt-bag-plugins ros-noetic-rqt-common-plugins
  ros-noetic-rqt-console ros-noetic-rqt-dep ros-noetic-rqt-graph ros-noetic-rqt-gui ros-noetic-rqt-gui-cpp ros-noetic-rqt-gui-py ros-noetic-rqt-image-view ros-noetic-rqt-launch ros-noetic-rqt-logger-level ros-noetic-rqt-moveit ros-noetic-rqt-msg ros-noetic-rqt-nav-view
  ros-noetic-rqt-plot ros-noetic-rqt-pose-view ros-noetic-rqt-publisher ros-noetic-rqt-py-common ros-noetic-rqt-py-console ros-noetic-rqt-reconfigure ros-noetic-rqt-robot-dashboard ros-noetic-rqt-robot-monitor ros-noetic-rqt-robot-plugins ros-noetic-rqt-robot-steering
  ros-noetic-rqt-runtime-monitor ros-noetic-rqt-rviz ros-noetic-rqt-service-caller ros-noetic-rqt-shell ros-noetic-rqt-srv ros-noetic-rqt-tf-tree ros-noetic-rqt-top ros-noetic-rqt-topic ros-noetic-rqt-web ros-noetic-rviz ros-noetic-rviz-plugin-tutorials
  ros-noetic-rviz-python-tutorial ros-noetic-self-test ros-noetic-shape-msgs ros-noetic-simulators ros-noetic-smach ros-noetic-smach-msgs ros-noetic-smach-ros ros-noetic-stage ros-noetic-stage-ros ros-noetic-stereo-image-proc ros-noetic-stereo-msgs ros-noetic-tf2-kdl
  ros-noetic-trajectory-msgs ros-noetic-transmission-interface ros-noetic-turtle-actionlib ros-noetic-turtle-tf ros-noetic-turtle-tf2 ros-noetic-turtlesim ros-noetic-urdf ros-noetic-urdf-parser-plugin ros-noetic-urdf-sim-tutorial ros-noetic-urdf-tutorial ros-noetic-vision-opencv
  ros-noetic-visualization-marker-tutorials ros-noetic-visualization-tutorials ros-noetic-viz ros-noetic-webkit-dependency ros-noetic-xacro ruby ruby-minitest ruby-net-telnet ruby-power-assert ruby-test-unit ruby-xmlrpc ruby2.7 rubygems-integration sbcl sdformat9-sdf shiboken2
  sip-dev ttf-dejavu-core
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up nvidia-l4t-kernel (5.10.120-tegra-35.4.1-20230801124926) ...
Using the existing boot entry 'primary'
/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh: line 554: warning: command substitution: ignored null byte in input
/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh: line 554: warning: command substitution: ignored null byte in input
/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh: line 554: warning: command substitution: ignored null byte in input
/opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh: line 554: warning: command substitution: ignored null byte in input
Warning: Cannot get compatible board name.
3767-000-0000--1--monarch_e5000_revC-
Info. Installing mtdblock.
Info. Active boot storage: nvme0n1
Info. Legacy mode: false
TNSPEC 3767-500-0000--1-1-monarch_e5000_revC-
COMPATIBLE_SPEC 3767-000-0000--1--monarch_e5000_revC-
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-000-0000--1--monarch_e5000_revC-.
Starting kernel post-install procedure.
Rootfs AB is not enabled.
ERROR. Procedure for A_kernel update FAILED.
Cannot install package. Exiting...
dpkg: error processing package nvidia-l4t-kernel (--configure):
 installed nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-headers:
 nvidia-l4t-kernel-headers depends on nvidia-l4t-kernel (= 5.10.120-tegra-35.4.1-20230801124926); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-headers (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          dpkg: dependency problems prevent configuration of nvidia-l4t-jetson-io:
 nvidia-l4t-jetson-io depends on nvidia-l4t-kernel (>> 5.10.120-tegra-35.4-0); however:
  Package nvidia-l4t-kernel is not configured yet.
 nvidia-l4t-jetson-io depends on nvidia-l4t-kernel (<< 5.10.120-tegra-35.5-0); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-jetson-io (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-display-kernel:
 nvidia-l4t-display-kernel depends on nvidia-l4t-kernel (= 5.10.120-tegra-35.4.1-20230801124926); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-display-kernel (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-dtbs:
 nvidia-l4t-kernel-dtbs depends on nvidia-l4t-kernel (= 5.10.120-tegra-35.4.1-No apport report written because the error message indicates its a followup error from a previous failure.
                          No apport report written because MaxReports is reached already
                                                                                        No apport report written because Max
Reports is reached already
                          20230801124926); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-dtbs (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-l4t-kernel
 nvidia-l4t-kernel-headers
 nvidia-l4t-jetson-io
 nvidia-l4t-display-kernel
 nvidia-l4t-kernel-dtbs
E: Sub-process /usr/bin/dpkg returned an error code (1)

Specifically, nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1

Is there a way that I can see this post-installation script so that I can get more details as to what is failing and causing the dependency errors?

We are trying to avoid having to re-flash the entire module/SSD in order to perform this upgrade in our products so any help is appreciated.

I have said.
Don’t do any Debian-based OTA on devices with custom carrier boards.
It’s only meant to be used with NVIDIA’s DevKits.

Nothing to check.
It’s just the package knew nothing about your carrier board, so it failed.

Thanks for the reply. I have tried this again in an nVidia Xavier NX devkit but I am still getting the same errors.

I have flashed our Orin NX using the following method:

I prepared L4T 35.2.1

$ tar xf ${L4T_RELEASE_PACKAGE}
$ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/
$ cd Linux_for_Tegra/
$ sudo ./apply_binaries.sh
$ sudo ./tools/l4t_flash_prerequisites.sh

I then generated a massflash file using the following commands:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --massflash 6 -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml --no-systemimg" --network usb0 p3509-a02+p3767-0000 nvme0n1p1

I flashed the device using the following command:

sudo ionice -c 1 -n 0 ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --massflash 1 --showlogs --network usb0 --keep

I then cloned our SSD image that we use that has L4T 35.2.1 and an already prepared rootfs from the sample rootfs.

I am still seeing the same errors as posted above. I have included the log file in this post.
x1_ota_failure.txt (30.5 KB)

If this issue lies on the SSD, what files can I change to allow for the OTA to complete successfully? If I change the board name to a compatible board name will that solve the problem?

Please try with an Orin Nano DevKit as the carrier board.
I think the combination of p3509-a02+p3767-0000 would not work neither.

I have tried the OTA process with the Orin Nano devkit. Our products have L4T 35.2.1 installed currently, which does not natively support Orin Nano Devkit without an overlay (from my understanding).

We don’t have physical access to these Orin NX modules in our product in order to re-flash them, so I am using the Orin Nano devkit with our L4T 35.2.1 rootfs in order to test this scenario (Orin NX module is flashed using tools provided with L4T 35.2.1 / JP 5.1 as well).

With the L4T 35.2.1 rootfs in the Orin Nano devkit, I am seeing the same errors and failures as posted above.

I am also curious how I may find more detail into how this failure is occuring nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1. Is there any way I can further debug this issue?

Something needs to be modified in the rootfs to allow for the OTA to complete, how can I further debug and find what changes need to be made?

Also, we are using a custom pinmux (generated according to nVidia’s methods), would these items prevent OTA from succeeding?

Oh sorry.
I just checked the document, and it shows that OTA for Orin NX/Nano is only supported starting from 35.4.1, so you can only upgrade to 35.4.1 with manual re-flash.
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/SoftwarePackagesAndTheUpdateMechanism.html#updating-jetson-linux-with-image-based-over-the-air-update

Understood,

We were able to get OTA to work from L4T 35.2.1 to L4T 35.4.1 by using the following commands:

  1. Editing the nvidia-l4t-apt-source.list file

    sudo vi /etc/apt/sources.list.d/nvidia-l4t-apt-source.list
    
    • File after editing:
    deb https://repo.download.nvidia.com/jetson/common r35.4 main
    deb https://repo.download.nvidia.com/jetson/t234 r35.4 main
    
  2. The following apt update commands were ran:

    $ sudo apt update
    $ sudo apt dist-upgrade
    
  3. After update completed (with errors that can be seen in the posts above), the following commands are ran to fix the apt configuration errors:

    $ sudo apt-get autoclean 
    $ sudo mv /var/lib/dpkg/info/ /var/lib/dpkg/backup/ 
    $ sudo mkdir /var/lib/dpkg/info/ 
    $ sudo apt-get update 
    $ sudo apt-get -f install 
    $ sudo apt-get dist-upgrade 
    

After all these commands are ran, the system reports the correct kernel and jetpack version.

x1@x1-Dec-7:~$ uname -r
5.10.104-tegra
x1@x1-Dec-7:~$ cat /etc/nv_tegra_release 
# R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug  1 19:57:35 UTC 2023

Is there any reason we shouldn’t perform the steps I listed above to update from L4T 35.2.1 to 35.4.1?

Thanks!

Are you sure the update is complete?
The kernel version is 5.10.120 for 35.4.1, and 5.10.104 is used on 35.3.1.

Anyway, the link I posted earlier is for image-based OTA, and the limitation is not the same for Debian-based OTA.

I pasted the output from the incorrect system in my post above, the kernel version is actually 5.10.120.

We have observed weird behavior when forcing apt OTA with this method, so we will push forward using image-based OTA.

Is there any way to keep my rootfs from 35.2.1 during the image-based OTA to 35.4.1?

So far the only way I can think to keep our files during OTA with image-based OTA is to generate our rootfs on a testbench and package it with the ota payload, which will require a lot of work on our end. Is there an easier way to keep our files during this update proces that I am not aware of?

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