Subject: Urgent Assistance Needed: Istio Setup on Nvidia Orin with Missing Kernel Module
I am reaching out for urgent assistance regarding an issue I am encountering while setting up Istio’s east-west gateway on an Nvidia Orin platform. The system details are as follows:
- Linux version 5.10.65-tegra (aarch64)
- Ubuntu 20.04.5 LTS (Focal Fossa)
- Nvidia Orin board with release R34 (GCID: 30414990)
Issue Description: While working with basic Istio functionalities, the setup works well. However, when attempting to add the annotation “ISTIO_META_DNS_CAPTURE: “true”” during installation, an error occurs after launching a Kubernetes deployment. The Istio-init container logs indicate issues executing certain commands.
$ k logs -f vs-55df9c749d-969kp -n sample -c istio-init
Command error output: xtables other problem: line 2 failed
Failed to execute: iptables-restore --noflush, exit status 1
PS: If we install Istio without the above annotation, the pods are unable to resolve the DNS of the other services. They can discover the internal IP of the pod but not the domain name. This adds to the urgency of resolving the missing kernel module issue.
Important Note: This issue seems related to the missing kernel module ‘xt_CT.ko,’ as discussed in this GitHub issue. The absence of this module is causing a critical roadblock in our Istio deployment.
Request for Assistance: I am seeking urgent guidance on how to enable the missing module or any alternative solutions. If enabling the module requires kernel configuration edits and reflashing, I would appreciate step-by-step instructions.
Thank you for your time and support.
This topic belongs in theJetson forums.
I have moved it for you.
Rel-34 comes from JetPack 5.0 DP which is not a GA release.
Please reflash your system with our latest software (JetPack5.1.2/r35.4.1)
The detailed steps can be found in the below document:
Hi @AastaLLL ,
Thank you for your suggestion. We tried re-flashing the board with JetPack5.1.2/r35.4.1 but the issue still persists. The CT module still seems missing.
Any other solutions to work this around are really appreciated.
Thanks for your time.
As mentioned the L4T R34.x is not a regular release. The latest R35.x is what you want:
However, note that it is fairly simple to compile kernel modules if this release in R35.x does not have what you want. Adding a module which is built against the existing kernel is a simple file copy. Just ask if you need more information on that.
The official docs tell you how to download and build kernel source via cross compile. The install directions though are via setting up for flash, which you don’t need to do. If you need to build, and if you have set up the configuration to match the existing kernel (including setting up
CONFIG_LOCALVERSION to be “
-tegra” for default systems), then you simply add that module via a configuration editor (such as
nconfig, which are dependency-aware), and build. The module is in a subdirectory of the kernel build output, and that matches the subdirectory you put it on the Jetson at.
Linux kernels produce the output of “
uname -r”, and is the base kernel version which is appended to via the
CONFIG_LOCALVERSION. If for example the kernel source is
5.15.0, and if
CONFIG_LOCALVERSION is “
-tegra”, then “
uname -r” responds with
5.15.0-tegra. Kernel modules are searched for at:
If the subdirectory for your kernel module within the source is “
drivers/foo/bar/”, and if the module name produces “
foobar.ko”, then you would copy to:
You might then reboot or run “
sudo depmod -a”. This is simpler than putting in some place on the host and then flashing the host when all that is needed is a file copy.
Thanks a lot @linuxdev and @AastaLLL . Will try this out and let you know