tegrity-qemu: new nvidia-l4t-ccp-t186ref package pre-installation script subprocess returned error exit status 1

[joekale]

I am working on modifying your application to work for alternate boards. In trying to customize the rootfs with your tegrity-qemu script I have run into this issue after adding the nvidia apt repositories and trying to install the nvidia-jetpack meta package. t186 is the tx2 code. I am using JetPack 4.3 / L4T 32.3.1.

Full Error:

Preparing to unpack .../nvidia-l4t-ccp-t186ref_32.3.1-20191209230245_arm64.deb ...
L4T Debian install is not supported on your configuration
You should install an L4T image from the latest releases - starting
from r32.3+ to have Debian package support
dpkg: error processing archive /var/cache/apt/archives/nvidia-l4t-ccp-t186ref_32.3.1-20191209230245_arm64.deb (--unpack):
 new nvidia-l4t-ccp-t186ref package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/nvidia-l4t-ccp-t186ref_32.3.1-20191209230245_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

[joekale]

The issue was that I had errors when trying to run the apply_binaries.sh script which installs the proper deb packages for this package to properly detect the board configuration. This will probably require corrections to the Dockerfile to allow sudo permissions since the rootfs is not present at the time of building.

[mdegans]

So, apt packages are basically tarballs with some pre and post installation scripts built in the archive that can pretty much do whatever they want (they run as root and convention is the only limit).

"L4T Debian install is not supported on your configuration" comes from one of these scripts. Some Nvidia packages check to ensure that they're installing on a Linux for Tegra rootfs. a few possible solutions:

• start from an Nvidia provided rootfs (boards are defined here)
• extract the apt package, figure out what it checks for, and mock that on your rootfs so the script doesn't fail. It's possibly /etc/nv_tegra_release that it checks for or something.
• the way to bypass these checks the Nvidia way is to use the --target-overlay option with the rootfs script, which passes that flag to apply_binaries.sh Nvidia script, which then extracts some tarballs onto the rootfs (without running any scripts).

Just note that if you do it the second way, you won't able to install any nvidia apt packages even if you add their apt repos because they will depend on their various base l4t packages. You'd still have to mock things to get them to install.

[mdegans]

The issue was that I had errors when trying to run the apply_binaries.sh script which installs the proper deb packages for this package to properly detect the board configuration. This will probably require corrections to the Dockerfile to allow sudo permissions since the rootfs is not present at the time of building.

If you're using the dev branch, there is some experimental support to build in docker, even rootless docker, however it won't be possible to build in docker with the main branch since apply_binaries.sh and some other scripts depend on the ability to use mount which can't work (safely) in Docker.

[mdegans]

This may not be intresting to you @joekale , since you're using tx2, but you could take the approach i am currently using with this project and build in a VM. No SDKM is required and it's tested to work on Windows as well as Linux (probably MacOS will work as well, but this is untested). It currently produces SD card images but it could be modified to produce system images for tx2 as well. I'd recommend that over tegrity. It incorporates parts of this project anyway.

[joekale]

If you're using the dev branch, there is some experimental support to build in docker, even rootless docker, however it won't be possible to build in docker with the main branch since apply_binaries.sh and some other scripts depend on the ability to use mount which can't work (safely) in Docker. Good to know. I'll avoid the docker work. I tested docker mostly to see if it corrected my problems.

So far tegrity is handling what I need it to do, but I'm open to new ideas once I get the first try finished. Mostly I needed a new rootfs with some bumped packages and some packages that need compiled pre-installed so my colleagues don't need to run an hours long script at boot for every device.