There was one release when switching from NVIDIA content just being tar archives to actual .deb packages, but I’m thinking it was prior to R32.4.4. Right now I’m looking at an NX with R32.4.3, and this has nv_tegra_release, so I’m positive that missing this file on your R32.4.4 is definitely wrong.
Do note that during a flash JetPack/SDKM is just a front end to the flash software. The actual flash software is also somewhat independent of the flashed content. This needs a bit of explanation to show why this matters.
During setup on the host PC prior to flash the “driver package” produces the “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra” directory and content, except for “Linux_for_Tegra/rootfs/”. It is this latter which ends up being flashed to the Jetson. The content is first created with a purely Ubuntu filesystem unpacked there, and then the “apply_binaries.sh” script is run (with sudo) to overlay NVIDIA content into what would otherwise be purely Ubuntu. At this point you can call it “Linux for Tegra” (“L4T”).
Finally, as flash begins, some content of “rootfs/boot/” is added based on the parameters passed to the flash program, e.g., a device tree might be picked and added to the “rootfs/boot/” before generating the actual image to flash.
Although not relevant to this, there are many other partitions related to boot (non-Linux stages) which are stored on either eMMC (if it is an eMMC model) or QSPI memory (if SD card model and if a recent release…amount on QSPI differs depending on release). All of this content is part of the “driver package” and is not found within the rootfs image which is generated from “Linux_for_Tegra/rootfs/”. I say “not relevant” because we’re looking at content on the rootfs itself.
Mostly I am very curious as to why nv_tegra_release is missing on your particular release. libcgmanager.so should probably have never been part of the rootfs unless you’re manually adding it. On the other hand I see “apt” is failing to open because “apt” itself wants this. This shouldn’t be possible on this particular release.
The command “ldd” can list what libraries an application needs to dynamically link against in order to function. On my R32.4.3 NX (SD card model) I see this:
root@nx:~# ldd /usr/bin/apt-get
linux-vdso.so.1 (0x0000007fab87e000)
libapt-private.so.0.0 => /usr/lib/aarch64-linux-gnu/libapt-private.so.0.0 (0x0000007fab7a9000)
libapt-pkg.so.5.0 => /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0 (0x0000007fab5ed000)
libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fab459000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fab435000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fab2db000)
/lib/ld-linux-aarch64.so.1 (0x0000007fab853000)
libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007fab2b6000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fab28a000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007fab25d000)
libbz2.so.1.0 => /lib/aarch64-linux-gnu/libbz2.so.1.0 (0x0000007fab23d000)
liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x0000007fab20d000)
liblz4.so.1 => /usr/lib/aarch64-linux-gnu/liblz4.so.1 (0x0000007fab1e1000)
libzstd.so.1 => /usr/lib/aarch64-linux-gnu/libzstd.so.1 (0x0000007fab16b000)
libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007fab141000)
libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000007fab0bc000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fab003000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007faafee000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007faafd7000)
libgcrypt.so.20 => /lib/aarch64-linux-gnu/libgcrypt.so.20 (0x0000007faaf1c000)
libgpg-error.so.0 => /lib/aarch64-linux-gnu/libgpg-error.so.0 (0x0000007faaefa000)
Nowhere in this list does it show that “apt-get” should ever care about “libcgmanager” (of any version). So I think something is “wonky” (one of those technical terms I wish I had a patent on) with your installed system.
If you run the command “sudo ldd /usr/bin/apt-get 2>&1 | tee log_ldd.txt”, then you should see what is linked against your apt-get, and it will produce the log file “log_ldd.txt” which you can attach to the forum.
There is one other twist in the story if your ldd does not show apt-get requiring the libcgmanager: One library can require yet another library in a chain of dependencies, and the ldd will only show what apt-get directly links against. Unfortunately I don’t think there is any sort of recursive version of ldd, but if your apt-get shows it requires libcgmanager, then this would be an error for your release. Somewhere along the line I’m wondering if some sort of apt command has broken dependencies. If not, then perhaps the original flashed image was at fault, e.g., with some sort of version mixing or from a failure of JetPack to correctly apply_binaries.sh.
Is your NX the SD card model dev kit? Or is it the eMMC model on a third party carrier board? Do you have valuable content you need to save if you were to flash again from scratch? In the end I’m thinking you will need to flash from scratch.