Hello, I’m currently encountering a problem when installing Jetpack.
The following is the system version queried through jetson_release after the system was just flashed. It can be seen that it is R38.2.1, which is consistent with the system version I flashed.
If you did sudo apt install jetpack or just apt update && apt upgrade, then apt would have upgraded your installed cat /etc/nv_tegra_release from 38.2.1 to 38.2.2. 38.2.2 is the current release version.
what does cat /etc/nv_tegra_release show 38.2.2 or 38.2.1.
If 38.2.2, I would not do apt install jetpack as it is already installed via flashing of your Thor.
Your jetson_stats / jtop is an older version, from “pip install jetson_stats” and gave you the spurious response as that version jtop is not updated for Thor.
The apt package system has to set a timestamp. Then all packages have their versions compared to what is available for update at that timestamp. Nothing really happens until you then “sudo apt-get upgrade”. This is not a release upgrade, it just upgrades packages to those at the timestamp within this release. At some point you might be offered a release upgrade, but that’s always obvious and the combination of “sudo apt update” and “sudo apt-get upgrade” is just a normal package maintenance.
However, there are sometimes bugs with packages. It doesn’t happen a lot, but sometimes the normal package release update/upgrade mechanism has a possibility of going wrong. If you have a pure developer’s kit, then the odds of this are fairly low. If you have a third party carrier board, and if that third party has different firmware (device tree), then whether or not it fails depends on whether the third party has correctly set up firmware dependencies. Other issues have been known to occur with different boot schemes, e.g., A/B redundancy might need a correct setup or else a normal update (which does not know about the A/B redundancy) could go wrong. I’m not saying this happens a lot, but it is a good idea at some point to back up the rootfs partition. There are a number of ways to do that.
So how should this be solved? I tested with devkit, which is not a custom board and system, and the probability of the system being updated after installation is a percentage.
I currently select “N” during the installation of Jetpack, but this seems to keep the /etc/nv_tegra_release, and the system files I modified are still updated.
Hi,
Do you build a custom kernel? Could you explain any specific reason for not wanting to update the version?
It seems expected that it would update to r38.2.2 when install nvidia-jetpack.
It is currently used on the Thor DevKit, using the RT kernel of R38.2.1, and no other content has been modified.
Because we need to make customized boards and customized systems in the future, we are currently doing verification on Devkit. If the system is updated to the latest version when nvidia-jetpack is installed, this means that the custom system will be overwritten and the function will be affected.
Even if we use the latest version at the time of development, it is unavoidable that NVIDIA will update the new version in the future.
Can this be solved? Because this problem did not occur on R35. * and R36. * versions before, the system will be updated only when executing apt upgrade.
Another question is that the official website is only updated to R38.2.1, but R38.2.2 is not seen. Why is this process updated to this version? I remember that even after the apt upgrade, it would only be updated to the latest version officially released.
You can blacklist packages which would destroy your content. For example, a kernel package.
You can see a list of current packages with “dpkg -l” (perhaps “dpkg -l | grep -i kernel”). There are ways to add these to a file, but you can also use “sudo apt-mark hold <package>” (and similarly “unhold” or “showhold” to see).
This is more or less just an “Ubuntu thing”, it isn’t specific to Jetsons. This would allow you to update other packages provided they do not depend on the held package.
You could temporarily remove the packages which can’t succeed due to dependencies, get everything as up-to-date as possible, and then try to add them back in. You’d want to be sure to know which packages are removed, and this might be a chain of packages, so you could log any apt removal operation.
If you run any “sudo apt ....” type command, and append " 2>&1 | tee log_operation.txt", then you will get a log by that name to refer to. Log the removal, then fix things, then try to add them back in. It doesn’t mean there will be a particular package which works, but I think that is your best chance at finding what the issue is and resolving it (“apt” can be used to remove packages too).
Hello,
I tried to do what you said today, but I still can’t. There are too many interdependent packages, and almost every step is limited.
Is there any other way? Previous use of AGX Orin and Orin NX/NANO will not be so troublesome.
Looking forward to your reply！
The kernel customization limits some choices. What you might do is to go ahead and install the standard packaged kernel, and then when done, have a script to reinstall the RT kernel. Regardless of what you choose I’d clone the rootfs as a reference if you have another Linux computer you can put a large file on (the size of the entire filesystem plus the size of the partition…that’s huge) since I suspect whatever you do is going to risk needing to reinstall. A loopback mounted raw clone can be used in many ways, including backup and restore, or just referencing content on another Linux system (ways which allow update from or too the loopback partition via rsync). I don’t know what the actual dependency issue is, but I suspect you won’t have an easy solution without first using the regular kernel and then installing the RT kernel (then you could blacklist package update; that’s ok for you, but might be a problem for units in the field or for customers). In the end you might need to create your own Debian package for your RT kernel such that it replaces the existing kernel (that’s a big learning curve).
Hello,
I know what you mean.
But I tried to install jetpack directly on the regular kernel with the same result. So the problem doesn’t seem to have anything to do with my use of RT-Kernel.
When you went back to the default kernel did you do so by flashing all content, or just changing the kernel? There could be some pretty large differences between a full clean install and just changing the kernel. Is there a single specific capability or package or library you need? There are a lot of listed unmet dependencies, but I’m wondering if one in particular is blocking your work?
