Corrupted kernel-headers package in L4T 32.6.1

Hi,
It seems that the kernel headers package included with the latest L4T release is corrupted.
This is what happens when running apply_binaries.sh:

Unpacking nvidia-l4t-kernel-headers (4.9.253-tegra-32.6.1-20210726122859) ...
dpkg: error processing archive /opt/nvidia/l4t-packages/kernel/nvidia-l4t-kernel-headers_4.9.253-tegra-32.6.1-20210726122859_arm64.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

I was able to extract the deb package manually with ar and zstd so I am not sure how exactly its corrupt.
Has anyone else experienced this?

Hi,
Please share the steps for reference. If you download image through SDKManager you should not need to execute apply_binaries.sh. Would like to get detail of the use-case and steps.

This is what I observed also. For example, if one needs to install Secure Boot so that the JAX can boot from NVMe, the rootfs and BSP need to be expanded.

Can you share what are the steps to hit this issue?

I am using Ubuntu 18.04 on my development machine.
Here are the steps to reproduce:

  • Download L4T BSP and sample rootfs from https://developer.nvidia.com/embedded/linux-tegra
  • Extract BSP with tar -Ilbzip2 -xf Jetson_Linux_R32.6.1_aarch64.tbz2
  • Extract RootFS with sudo tar -Ilbzip2 -pxf Tegra_Linux_Sample-Root-Filesystem_R32.6.1_aarch64.tbz2 -C Linux_for_Tegra/rootfs
  • cd to Linux_for_Tegra
  • run sudo ./apply_binaries.sh
  • Get the failure from above.

@daneLLL
I cannot use SDK manager since I have a custom carrier board with some scripts that assemble my custom BSP. Once apply_binaries is run, I apply my changes that allow it to work on my board so this is being done on a ‘clean’ version.

Hi,
For information, is your host PC Ubuntu 16.04 or 18.04? We try on 16.04 and don’t hit the issue.

Hi sgidel,

We tried on Ubuntu-16.04 and 18.04 are no issue.
Please follow below steps to try again. Thanks!

tar xpvf Jetson_Linux_R32.6.1_aarch64.tbz2 
cd Linux_for_Tegra/rootfs/
sudo tar xpvf ../../Tegra_Linux_Sample-Root-Filesystem_R32.6.1_aarch64.tbz2 
cd ../
sudo ./apply_binaries.sh 

The host PC typically downloads those files automatically (if using JetPack/SDKM), and places them in “~/Downloads/nvidia/nvidia_sdkm/”. Perhaps if you are using this you could delete (or temporarily change to unavailable by using bzip2 on the “.deb”) and see if downloading again changes the checksum. Similar if you are manually downloading, try new download.

Hm, well at this point I have no idea what is going on. its random almost and its making me suspect hardware failure. Ill try it on another machine later.

Ive tried both methods and both would sometimes work and sometimes not. I diffed a case that worked and one that didnt and prior to running apply_binaries it came out identical. after running apply_binaries it was different.

I also verified checksums of the offending debfile and got MD5 10d25b115a0cfb9c0e2ef07310720141 for nvidia-l4t-kernel-headers_4.9.253-tegra-32.6.1-20210726122859_arm64.deb both times.

Well I was able to extract and run apply_binaries on my xavier multiple times without issues so it seems to be something with my dev box.
I still have no issues with L4T 32.5.1 though.

2 Likes