Problem SMB Jetson Nano

I have a problem connecting from Jetson Nano to a Samba server

sudo mount -t cifs -o vers=3.0,credentials=/home/user/.smbfile,rw,user,uid=1000,gid=1000 //192.168.21.114/Data/ /home/user/mnt/Data
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

From other computers I can access to the server without problems

From the Jetson Nano I can connect to other computers

I think the problem is the different versions of samba.
All the software is updated

Thank you very much

sudo mount.cifs //192.168.21.114/Data/ /home/user/mnt/Data vers=3.02,credentials=/home/juser/.smbfile,rw,user,uid=1000,gid=1000
Password for root@//192.168.21.114/Data/: **************************************
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount.cifs -V
mount.cifs version: 6.8
joaquin@Jetson:~$ samba --version
Version 4.7.6-Ubuntu
joaquin@Jetson:~$ modinfo cifs
filename: /lib/modules/4.9.140-tegra/kernel/fs/cifs/cifs.ko
version: 2.09
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French sfrench@us.ibm.com
alias: fs-cifs
srcversion: 7F8AA5566FE260E55F0531A
depends:
intree: Y
vermagic: 4.9.140-tegra SMP preempt mod_unload modversions aarch64
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (uint)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (uint)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (uint)
parm: cifs_max_pending:Simultaneous requests to server. Default: 32767 Range: 2 to 32767. (uint)
parm: enable_oplocks:Enable or disable oplocks. Default: y/Y/1 (bool)

In the Samba server

mount.cifs -V
mount.cifs version: 6.8
samba --version
Version 4.9.5-Debian
joaquin@Perseus:~ $ modinfo cifs
filename: /lib/modules/5.10.63-v7l+/kernel/fs/cifs/cifs.ko
softdep: gcm
softdep: ccm
softdep: aead2
softdep: sha512
softdep: sha256
softdep: cmac
softdep: aes
softdep: nls
softdep: md5
softdep: md4
softdep: hmac
softdep: ecb
version: 2.29
description: VFS to access SMB3 servers e.g. Samba, Macs, Azure and Windows (and also older servers complying with the SNIA CIFS Specification)
license: GPL
author: Steve French
alias: smb3
alias: fs-smb3
alias: fs-cifs
srcversion: CF249888CE69BFFF3AE59AB
depends: libarc4
intree: Y
name: cifs
vermagic: 5.10.63-v7l+ SMP mod_unload modversions ARMv7 p2v8
parm: CIFSMaxBufSize:Network buffer size (not including header) for CIFS requests. Default: 16384 Range: 8192 to 130048 (uint)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (uint)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (uint)
parm: cifs_max_pending:Simultaneous requests to server for CIFS/SMB1 dialect (N/A for SMB3) Default: 32767 Range: 2 to 32767. (uint)
parm: enable_oplocks:Enable or disable oplocks. Default: y/Y/1 (bool)
parm: enable_gcm_256:Enable requesting strongest (256 bit) GCM encryption. Default: n/N/0 (bool)
parm: require_gcm_256:Require strongest (256 bit) GCM encryption. Default: n/N/0 (bool)
parm: disable_legacy_dialects:To improve security it may be helpful to restrict the ability to override the default dialects (SMB2.1, SMB3 and SMB3.02) on mount with old dialects (CIFS/SMB1 and SMB2) since vers=1.0 (CIFS/SMB1) and vers=2.0 are weaker and less secure. Default: n/N/0 (bool)

From other computers I can access to the server without problems

From the Jetson Nano I can connect to other computers

I think the problem is the different versions of samba.
All the software is updated

Thank you very much

I don’t have any way to check, and don’t use Samba, but in general an operation not supported implies an option in the kernel is missing. Unlike a desktop an embedded system does not (by default) add every possible module you want. So you will want to find out which kernel features are needed for “cifs” (this is likely the missing feature). Then add that feature as a kernel module. Possibly there would be user space software as well, but I would bet that any kernel feature addition via a module would mostly get things working.

FYI, you can browse what features your running Jetson has via:
zcat /proc/config.gz | less

Features which are “=m” were built in the form of a module, and if that module is loaded, then it would show up under “lsmod”. Features which are “=y” are integrated and always loaded (they won’t show up in “lsmod”, but they are guaranteed available). You could look at modules via “lsmod” on one of your working Linux systems and see if something looks related to cifs as a clue. Or simply look for Samba tutorials or man pages to see what cifs feature is required.

I see with asmod that the module cifs is installed and working.
But I doesn’t connect to the serv er
Thank you very much

If it still says something about an unsupported operation, then there is probably something to be found on the internet about that plus cifs plus Linux. It just wouldn’t be the cifs module since it is loaded.

Sometimes though there are two versions of something like a filesystem or cifs…perhaps it needs a different release (if and only if there is more than one release, and I am just illustrating so this might be way off…the inspiration is that NFS filesystems have multiple variants, and would need the correct variant).

I had help from someone else who has a better understanding of CIFS. He suggested seeing this URL:
https://forums.developer.nvidia.com/t/how-to-mount-windows-shared-folder-on-xavier/70289/25

Does this help or provide a new error message?

Another update URL pointed out by another user:
https://forums.developer.nvidia.com/t/mount-network-folder-samba-cifs/70922/25
(this one includes kernel config information)

Investigating the links in the answers I get:

$ mount.cifs -V
mount.cifs version: 6.8

$ samba --version
Version 4.7.6-Ubuntu

$ modinfo cifs
filename: /lib/modules/4.9.140-tegra/kernel/fs/cifs/cifs.ko
version: 2.09
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French sfrench@us.ibm.com
alias: fs-cifs
srcversion: 7F8AA5566FE260E55F0531A
depends:
intree: Y
vermagic: 4.9.140-tegra SMP preempt mod_unload modversions aarch64
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (uint)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (uint)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (uint)
parm: cifs_max_pending:Simultaneous requests to server. Default: 32767 Range: 2 to 32767. (uint)
parm: enable_oplocks:Enable or disable oplocks. Default: y/Y/1 (bool)

$ gunzip -c /proc/config.gz | grep CONFIG_CIFS_SMB

CONFIG_CIFS_SMB2 is not set

$ ls /lib/modules/$(uname -r)/kernel/fs/cifs/
cifs.ko

So CIFS is installed in the system but it not installed in the kernel, isn’t it?
The module is compiled, isn’t it?

$ lsmod
Module Size Used by
veth 6345 0
xt_conntrack 3609 2
ipt_MASQUERADE 2346 2
nf_nat_masquerade_ipv4 3111 1 ipt_MASQUERADE
nf_conntrack_netlink 28859 0
nfnetlink 7959 2 nf_conntrack_netlink
xt_addrtype 3670 2
iptable_filter 2481 1
iptable_nat 2882 1
nf_conntrack_ipv4 11992 3
nf_defrag_ipv4 1836 1 nf_conntrack_ipv4
nf_nat_ipv4 6712 1 iptable_nat
nf_nat 20406 2 nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack 105820 6 nf_conntrack_ipv4,nf_conntrack_netlink,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
br_netfilter 16250 0
zram 26166 4
uvcvideo 90357 0
cifs 346185 0
overlay 48691 0
spidev 13282 0
userspace_alert 5665 0
nvgpu 1580772 13
bluedroid_pm 13912 0
ip_tables 19441 2 iptable_filter,iptable_nat
x_tables 28951 5 ip_tables,iptable_filter,ipt_MASQUERADE,xt_addrtype,xt_conntrack

But here says that the module is installed.
I don’t understand. Should I recompile the kernel?
If yes how to compile the kernel for the Jetson nano in the Jetson nano?

Thank you very much

When a symbol is found in “/proc/config.gz”, then this indicates what the kernel Image file was configured for at the moment of building it. Lacking CONFIG_CIFS_SMB2 says the kernel itself never had this feature enabled. However, the twist to the story is that if you build that feature as a module at a later date, and then copied it to the Jetson, then you might have the feature as the module loads even though the kernel itself did not know about the feature at the time of its original compile.

Did you add CIFS features via modules at a later date? If so, then you might have the feature (if and only if the module is loaded). If not, then you probably need to build and install the kernel module. Many features use multiple “kernel symbols”, and although I have not looked, it is possible that the cifs.ko module only provides part of what is needed. Don’t know, that’s something to research.

The commands which use CIFS, e.g., “mount.cifs”, are use space programs which you’d have installed via a package. This is separate from kernel features. The programs complete their work by making “system calls” to the kernel, and those calls are essentially symbols or features of the kernel. If a symbol or feature is missing, then your user space program is functioning normally when it fails since the kernel did not have the ability to honor the required system calls.

I haven’t set up CIFS in years, so I don’t remember requirements, but any URL about setting up CIFS which mentions kernel config items (symbols, such as “CONFIG_CIFS_SMB2” will apply to a Jetson just as much as to any Linux host computer. My guess is that this needs to be present, and that you need to check if kernel module cifs.ko provides that symbol or not.

Note that sometimes there is more than one protocol release of various drivers. NFS filesystem is typical, as it has both an NFSv3 and NFSv4 in common use, plus an older NFSv2. Having the wrong one means that a command to use the wrong release will fail (two different releases are considered completely separate software in most cases). I don’t know the details of CIFS, but there might be more than one version available for this as well (which is why checking on required kernel configuration/symbols needs to consider if there is more than one version). Perhaps cifs.ko works, but perhaps for the wrong release (don’t know, I have not worked with this in a long time).

I haven’t add CIFS via modules. I never build and install a kernel module.
Have I build the module? Any URL with instructions to build the kernel module?

Thank you very much

There are different ways to do this, with some being easier than others. Some terminology to start will help…

If you have a Linux desktop PC running Ubuntu 18.04, then this will cover official instructions. This is because the official instructions are for “cross compiling”. Meaning use of the PC to compile for an architecture different than its own (in this case the “different” architecture is arm64/aarch64, the Jetson’s architecture, while the host PC is x86_64/amd64). If you were to instead build software on the Jetson for the Jetson, then this is “native” compile, and is the simplest compile (however, a Jetson may lack disk space or other resources which the PC would consider “trivial” to provide).

Either type of compile will turn out to be “easier than it looks” if you’ve done this once (I am providing a lot more information than you need if you were just following a recipe, so don’t be intimidated…what follows is to actually understand rather than following a recipe). Both native and cross-compile of kernel and/or module build has much in common. Once you have content to put in place though you should be careful to install that content with the easiest and/or safest method. Modules do not need any flashing, though some instructions will use flash to do this. Avoid flashing when you are just installing modules.

You should note the output of this command on the Jetson before you start: “uname -r”. This is related to both compile setup and installation of modules. As an example I’ll pretend the result of the command is “4.9.140-tegra”. In this name the base kernel version is “4.9.140”, and is determined by the kernel version itself. The “suffix” of “-tegra” (including the hyphen) is related to source configuration at the moment the 4.9.140 source was compiled. This suffix is important, as explained below. This applies whether using cross-compile or native compile.

The file “/boot/Image” is the actual kernel (this can be loaded from a partition as well, but normally it would be this file…no need to flash if it is the file, and it is safer to not flash if you can just put a file in place, but default official instructions use flash). Modules are part of the kernel, but they are dynamically loaded by the kernel at a later time, and can be loaded or unloaded at will. The location which the kernel finds its modules at is why the “uname -r” matters. That kernel will search for modules (which are just files and never part of a partition) here:
/lib/modules/$(uname -r)/kernel

For reference, when you see comments on setting the “CONFIG_LOCALVERSION” prior to kernel or module compile, this refers to the suffix of “uname -r”, and the default is usually:
CONFIG_LOCALVERSION="-tegra"

If your kernel source version and the CONFIG_LOCALVERSION during module build are the same as your running kernel, then you can simply copy the module file to the correct subdirectory of “/lib/modules/$(uname -r)/kernel”. If you do build the entire kernel and place it as “/boot/Image”, and if the new kernel had a matching configuration to the old kernel (but perhaps with an added feature), and if that Image has the same “uname -r”, then the new Image will find and use all of the old modules at the same location as which the old kernel found them. If not, then replacing the Image would in fact also require building and installing all of the modules into the new location with the changed “/lib/modules/$(uname -r)/kernel”. Just getting the configuration as a correct match, including “CONFIG_LOCALVERSION” (and thus indirectly “uname -r”) will save you much effort.

There is actually more than one way to specify the CONFIG_LOCALVERSION, but I included what would be an edit to the kernel configuration file at build time. Other documents will start a compile with an environment variable, which has the same result.

The official documents which come with a particular release provide this information in the “kernel customization” section. This cross compile information is easy to use from a host PC. Just skip the part where it uses flash to install and ask here if you need to know more about copying a file into the Jetson. You should basically compile the entire kernel once as an “acid test” to see if configuration is correct, but only copy the new module in place once done. Native compile on the Jetson is a bit simpler, but the Jetson would probably run out of disk space unless you build on external storage, e.g., a thumb drive, or perhaps your SD card is larger than minimum (see “df -H -t ext4” to see your relevant disk usage). If you don’t have a Linux PC, then this is a convenient alternate should you have sufficient disk space.

The particular L4T release (Ubuntu plus NVIDIA hardware accelerated drivers) can be found via:
head -n 1 /etc/nv_tegra_release

The document URL for that particular release can be found here (and the documentation there has a document with the kernel customization official information):
https://developer.nvidia.com/linux-tegra

If you want more information kernel naming and module install without flashing, see:
https://forums.developer.nvidia.com/t/jetson-nano-board-setup/163668/6

A URL similar to the one just above, but with more detail on finding and setting features, is here:
https://forums.developer.nvidia.com/t/attempts-to-set-up-ecryptfs-and-fscrypt-failed-and-failed-and-failed/119083/2

The gist is that configuring by any method will create a file “.config” at the top of the kernel source code build location. The build target “tegra_defconfig” sets this up as a match to the default a Jetson would ship with. Alternatively, the file “/proc/config.gz” can be extracted from the Jetson and renamed as “.config” to get a nearly exact match of the running kernel’s config (not needed if you just want the default, but suppose you’ve configured something new before…then the “/proc/config.gz” would be a superior config starting point compared to make target “tegra_defconfig”). In every case you’d need to set the CONFIG_LOCALVERSION. In each case there are various ways to propagate the new config before building a module (and if you’ve started by building “Image”, then you don’t need to propagate anything…it just takes time to build an “Image”, and I recommend building it once anyway just to see if things work with that config). An example of not building Image first would be to run the make command “modules_depend” before building modules.

The above is a lot of reference. If you want to, then just start with the official docs and come back after you’ve cross-compiled the module you want. The reality is that having done this just once you’ll find it to be fairly trivial to build and install a kernel module.

Incidentally, here is something of a short recipe “cheat sheet” for native compile if the source code is on the Jetson (this shows how to build everything, not just modules, so you wouldn’t care about things like firmware):

# --- Setting Up: -------------------------------------------------------
# DO NOT BUILD AS ROOT/SUDO!!! You might need to install source code as root/sudo.
mkdir -p "${HOME}/build/kernel"
mkdir -p "${HOME}/build/modules"
mkdir -p "${HOME}/build/firmware"

export TOP="/usr/src/sources/kernel/kernel-4.9"
export TEGRA_KERNEL_OUT="${HOME}/build/kernel"
export TEGRA_MODULES_OUT="${HOME}/build/modules"
export TEGRA_FIRMWARE_OUT="${HOME}/build/firmware"
export TEGRA_BUILD="${HOME}/build"

# --- Notes: ------------------------------------------------------------
# It is assumed kernel source is at "/usr/src/sources/kernel/kernel-4.9".
# Check if you have 6 CPU cores, e.g., via "htop".
# If you are missing cores, then experiment with "sudo nvpmodel -m 0, -m 1, and -m 2".
# Perhaps use "htop" to see core counts.
# Using "-j 6" in hints below because of assumption of 6 cores.
# -----------------------------------------------------------------------

# Compile commands start in $TOP, thus:
cd $TOP

# Do not forget to provide a starting configuration. Probably copy of "/proc/config.gz",
# to $TEGRA_KERNEL_OUT, but also perhaps via:
make O=$TEGRA_KERNEL_OUT nconfig

# If building the kernel Image:
make -j 6 O=$TEGRA_KERNEL_OUT Image

# If you did not build Image, but are building modules:
make -j 6 O=$TEGRA_KERNEL_OUT modules_prepare

# To build modules:
make -j 6 O=$TEGRA_KERNEL_OUT modules

# To build device tree content:
make -j 6 O=$TEGRA_KERNEL_OUT dtbs

# To put modules in "$TEGRA_MODULES_OUT":
make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

# To put firmware and device trees in "$TEGRA_FIRMWARE_OUT":
make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT

(the above has temporary output to the “TEGRA_KERNEL_OUT” location so as to not interfere with the pristine default source code; similar for temporary output locations to avoid mixing temporary content with source code, and to avoid installing directly to the Jetson without having an opportunity to install in the easiest manner)

Note: The feature CONFIG_CIFS_SMB2 is also known as a “symbol” if you are performing kernel config. Config editors can set this for you if you search for CIFS_SMB2 (to be added after base configuration matches the running kernel). There are multiple ways to do this, but when you have your base kernel config built you can then use an editor to add this “symbol” (or feature). The result, if built as a module, is that the .config file has this added to it, and the actual build would produce the CIFS kernel module for copy to the correct location.

Hello
I do:

$ make O=$TEGRA_KERNEL_OUT nconfig
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
GEN ./Makefile
scripts/kconfig/nconf Kconfig
make[1]: Leaving directory ‘/home/joaquin/L4T/32.6.1/build/kernel’

And exit with F9

$ make -j 6 O=$TEGRA_KERNEL_OUT Image
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
Using /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9 as source for kernel
CHK scripts/mod/devicetable-offsets.h
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/base/dma-coherent.o
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/drivers/base/dma-coherent.c:973:12: error: ‘shrink_thread’ defined but not used [-Werror=unused-function]
static int shrink_thread(void *arg)
^~~~~~~~~~~~~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/drivers/base/dma-coherent.c:280:12: error: ‘declare_coherent_heap’ defined but not used [-Werror=unused-function]
static int declare_coherent_heap(struct device *dev, phys_addr_t base,
^~~~~~~~~~~~~~~~~~~~~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/drivers/base/dma-coherent.c:96:13: error: ‘dma_debugfs_init’ defined but not used [-Werror=unused-function]
static void dma_debugfs_init(struct device *dev, struct heap_info *heap)
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:335: recipe for target ‘drivers/base/dma-coherent.o’ failed
make[3]: *** [drivers/base/dma-coherent.o] Error 1
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:649: recipe for target ‘drivers/base’ failed
make[2]: *** [drivers/base] Error 2
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/Makefile:1122: recipe for target ‘drivers’ failed
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs…
make[1]: *** wait: No child processes. Stop.
Makefile:171: recipe for target ‘sub-make’ failed
make: *** [sub-make] Error 2

Any idea how to solve this?

Could you clarify this:

Do not forget to provide a starting configuration. Probably copy of “/proc/config.gz”,

Thank you very much

Did you use any other configuration prior to this? “nconfig” is meant to alter an existing config. An example of something to do prior to this is either use the existing system’s configuration, or else to use “make O=$TEGRA_KERNEL_OUT tegra_defconfig” (the factory setting) prior to nconfig (and then use nconfig to make some specific change you are interested in). You should also make sure CONFIG_LOCALVERSION has been set (most likely to "-tegra").

It is important to know if you did not have a starting configuration that you will get a lot of unpredictable errors. Unless we know you had a starting configuration prior to nconfig, then none of the errors listed would have meaning.

The use of “/proc/config.gz” is a nice special case of being what your system is currently using (other than needing CONFIG_LOCALVERSION to be set). If you never modified your Jetson, then “tegra_defconfig” works nicely, but if you’ve made an adjustment, then I highly recommend the use of “/proc/config.gz” (copy it somewhere, gunzip config.gz at that copy location, “mv config .config” to get the correct name “.config”, and edit “CONFIG_LOCALVERSION”).

Also, can I verify this was performed natively on the Jetson itself? If not, then cross compile steps need to be added.

Yes I am compiling in the Jetson Nano

$ export CONFIG_LOCALVERSION="-tegra"
joaquin@Jetson:~$ export BASE_L4T="${HOME}/L4T/32.6.1"
joaquin@Jetson:~$ export TOP="${BASE_L4T}/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9"
joaquin@Jetson:~$ export TEGRA_KERNEL_OUT="${BASE_L4T}/build/kernel"
joaquin@Jetson:~$ export TEGRA_MODULES_OUT="${BASE_L4T}/build/modules"
joaquin@Jetson:~$ export TEGRA_FIRMWARE_OUT="${BASE_L4T}/build/firmware"
joaquin@Jetson:~$ export TEGRA_BUILD="${BASE_L4T}/build"
joaquin@Jetson:~$ cd $TOP
joaquin@Jetson:~/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9$ make O=$TEGRA_KERNEL_OUT tegra_defconfig
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
GEN ./Makefile

configuration written to .config

make[1]: Leaving directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
joaquin@Jetson:~/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9$ make -j 6 O=$TEGRA_KERNEL_OUT Image
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
GEN ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
……
OBJCOPY arch/arm64/boot/Image
make[1]: Leaving directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
joaquin@Jetson:~/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9$ make -j 6 O=$TEGRA_KERNEL_OUT modules_prepare
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9 as source for kernel
CHK include/generated/utsrelease.h
CHK scripts/mod/devicetable-offsets.h
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/checksyscalls.sh
make[1]: Leaving directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
joaquin@Jetson:~/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9$ make -j 6 O=$TEGRA_KERNEL_OUT modules
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
………
CC [M] net/netfilter/xt_mark.o
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c:16:10: fatal error: linux/netfilter/xt_mark.h: No such file or directory
#include <linux/netfilter/xt_mark.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:341: recipe for target ‘net/netfilter/xt_mark.o’ failed
make[3]: *** [net/netfilter/xt_mark.o] Error 1
make[3]: *** Waiting for unfinished jobs…
CC [M] drivers/infiniband/sw/rdmavt/srq.o
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:649: recipe for target ‘net/netfilter’ failed
make[2]: *** [net/netfilter] Error 2
make[2]: *** Waiting for unfinished jobs…
CC [M] drivers/infiniband/sw/rdmavt/trace.o
………
CC [M] drivers/net/wireless/realtek/rtl8822ce/core/rtw_mp.o
LD [M] drivers/net/wireless/realtek/rtl8822ce/rtl8822ce.o
make[1]: Leaving directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
Makefile:171: recipe for target ‘sub-make’ failed
make: *** [sub-make] Error 2

The file net/netfilter/xt_mark.c exists but no xt_mark.h

In xt_mark.c
#include <linux/module.h>
#include <linux/skbuff.h>

#include <linux/netfilter/xt_mark.h>
#include <linux/netfilter/x_tables.h>

Where can I get the file?

Thank you very much

Interesting, it should probably work. After the tegra_defconfig, did you make any other changes? If you did make changes, did you use a configuration editor?

Within your kernel source (the “$TOP”) it would be in a subdirectory:
./include/uapi/linux/netfilter/xt_mark.h
(but I’m looking at kernel release 4.9.140, so if you have another release, then perhaps it changed since then)

It is possible for a file to show as “missing” when there was a feature dependency…if a feature were enabled, and the dependency were missed (such as via manually editing the “.config”), then something similar might occur. Does the file exist at the location I mentioned in the previous paragraph?

Hello
I do
export CONFIG_LOCALVERSION="-tegra"
export BASE_L4T="${HOME}/L4T/32.6.1"
export TOP="${BASE_L4T}/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9"
export TEGRA_KERNEL_OUT="${BASE_L4T}/build/kernel"
export TEGRA_MODULES_OUT="${BASE_L4T}/build/modules"
export TEGRA_FIRMWARE_OUT="${BASE_L4T}/build/firmware"
export TEGRA_BUILD="${BASE_L4T}/build"

cd $TOP

The file ./include/uapi/linux/netfilter/xt_mark.h doesn’t exists but ./include/uapi/linux/netfilter/xt_MARK.h yes, so:
cp ./include/uapi/linux/netfilter/xt_MARK.h ./include/uapi/linux/netfilter/xt_mark.h

make O=$TEGRA_KERNEL_OUT tegra_defconfig
I don’t make any change

make -j 6 O=$TEGRA_KERNEL_OUT Image
make -j 6 O=$TEGRA_KERNEL_OUT modules_prepare

$ make -j 6 O=$TEGRA_KERNEL_OUT modules
make[1]: Entering directory ‘/home/joaquin/L4T/32.6.1/build/kernel’
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9 as source for kernel
CC [M] net/netfilter/xt_mark.o
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c: In function ‘mark_tg’:
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c:33:32: error: dereferencing pointer to incomplete type ‘const struct xt_mark_tginfo2’
skb->mark = (skb->mark & ~info->mask) ^ info->mark;
^~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c: In function ‘mark_mt’:
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c:42:27: error: dereferencing pointer to incomplete type ‘const struct xt_mark_mtinfo1’
return ((skb->mark & info->mask) == info->mark) ^ info->invert;
^~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c: At top level:
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c:50:27: error: invalid application of ‘sizeof’ to incomplete type ‘struct xt_mark_tginfo2’
.targetsize = sizeof(struct xt_mark_tginfo2),
^~~~~~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/net/netfilter/xt_mark.c:59:27: error: invalid application of ‘sizeof’ to incomplete type ‘struct xt_mark_mtinfo1’
.matchsize = sizeof(struct xt_mark_mtinfo1),
^~~~~~
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:341: recipe for target ‘net/netfilter/xt_mark.o’ failed
make[3]: *** [net/netfilter/xt_mark.o] Error 1
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/scripts/Makefile.build:649: recipe for target ‘net/netfilter’ failed
make[2]: *** [net/netfilter] Error 2
make[2]: *** Waiting for unfinished jobs…
/home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel_src/kernel/kernel-4.9/Makefile:1122: recipe for target ‘net’ failed
make[1]: *** [net] Error 2

There is a problem with the code

Btw, if you have made the “Image” target, then you don’t need the “modules_prepare” target (but it shouldn’t hurt).

I suspect the source code you have might be from an incomplete archive of the kernel. What I did was to build using the same options and the same kernel from R32.6.1, directly on a Jetson (it was a TX2, but most Jetsons will never know any difference in kernel compile results), and all of it built without the failure related to “fatal error: linux/netfilter/xt_mark.h: No such file or directory”.

If your kernel source is not the same as that found in the R32.6.1 source package, then I am hoping you can delete the old source and put in the source from that package. R32.6.1 can be found here:
https://developer.nvidia.com/embedded/linux-tegra-r3261

Within that you will find a link for “L4T Driver Package (BSP) Sources”, with this URL:
https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/sources/t210/public_sources.tbz2

You can extract just the archive content of “Linux_for_Tegra/source/public/kernel_src.tbz2”, copy that to the Jetson, and unpack it in place of the old source. You can use a tool like “ark” to extract just the one file from that tar archive. Then build again using this (this should contain the needed xt_mark.h file).

If this does not work, then I’m wondering if the intermediate file “xt_mark.o” simply wasn’t there because the system ran out of disk space. Building just the modules takes a lot of disk space, and building both that and the Image implies a lot more space. It is possible that at some point missing files were just a result of build not having a place to put the results. During a build I was watching “watch -n 1 df -H /” and could see the remaining space consume several GB more than was available.

Also, the gcc available on a Jetson should be fine for native compile, but you might include the output of “gcc --version”.

Hello
I have reload the source to restart again. I have deleted the old folder.

export ORIGIN_L4T="${HOME}/mnt/Proyects_IoT/Jetson/L4T/32.6.1"
export BASE_L4T="${HOME}/L4T/32.6.1"
echo $BASE_L4T
cp $ORIGIN_L4T/public_sources.tbz2 $BASE_L4T/public_sources.tbz2
cd $BASE_L4T
ls -la
tar -xf public_sources.tbz2
ls -la
cd $BASE_L4T/Linux_for_Tegra/source/public
ls
tar -xf kernel_src.tbz2
ls -la

mkdir -p “${BASE_L4T}/build/kernel”
mkdir -p “${BASE_L4T}/build/modules”
mkdir -p “${BASE_L4T}/build/firmware”
ls -la $BASE_L4T

export CONFIG_LOCALVERSION="-tegra"
export BASE_L4T="${HOME}/L4T/32.6.1"
export TOP="${BASE_L4T}/Linux_for_Tegra/source/public/kernel/kernel-4.9"
export TEGRA_KERNEL_OUT="${BASE_L4T}/build/kernel"
export TEGRA_MODULES_OUT="${BASE_L4T}/build/modules"
export TEGRA_FIRMWARE_OUT="${BASE_L4T}/build/firmware"
export TEGRA_BUILD="${BASE_L4T}/build"

cd $TOP

ls ./include/uapi/linux/netfilter/xt_mark.h
Now the file is here. I don’t understand why it isn’t before

$ gcc --version
gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make -j 6 O=$TEGRA_KERNEL_OUT Image
Compile with no errors. There are enough space in the SD. Only use 36% (it’s 128Gb SD).
I have compile with no changes to see if it works. If it works I will change it to add cifs.

make -j 6 O=$TEGRA_KERNEL_OUT modules
make -j 6 O=$TEGRA_KERNEL_OUT dtbs
make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT

Seems that it’s compiled correctly
$ ls -la $TEGRA_KERNEL_OUT
total 1626500
drwxrwxr-x 22 joaquin joaquin 4096 Nov 24 11:52 .
drwxrwxr-x 5 joaquin joaquin 4096 Nov 24 10:16 …
drwxrwxr-x 3 joaquin joaquin 4096 Nov 24 10:31 arch
drwxrwxr-x 3 joaquin joaquin 4096 Nov 24 11:02 block
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 11:02 certs
-rw-rw-r-- 1 joaquin joaquin 166793 Nov 24 10:29 .config
drwxrwxr-x 2 joaquin joaquin 12288 Nov 24 11:41 crypto
drwxrwxr-x 83 joaquin joaquin 4096 Nov 24 11:39 drivers
drwxrwxr-x 36 joaquin joaquin 4096 Nov 24 11:42 firmware
drwxrwxr-x 32 joaquin joaquin 12288 Nov 24 11:42 fs
drwxrwxr-x 4 joaquin joaquin 4096 Nov 24 10:31 include
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 11:02 init
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 11:02 ipc
drwxrwxr-x 13 joaquin joaquin 12288 Nov 24 11:52 kernel
drwxrwxr-x 11 joaquin joaquin 20480 Nov 24 11:42 lib
-rw-rw-r-- 1 joaquin joaquin 704 Nov 24 11:51 Makefile
-rw-rw-r-- 1 joaquin joaquin 1383 Nov 24 11:51 .missing-syscalls.d
drwxrwxr-x 2 joaquin joaquin 12288 Nov 24 11:02 mm
-rw-rw-r-- 1 joaquin joaquin 22141 Nov 24 11:02 modules.builtin
-rw-rw-r-- 1 joaquin joaquin 27700 Nov 24 11:52 modules.order
-rw-rw-r-- 1 joaquin joaquin 852080 Nov 24 11:40 Module.symvers
drwxrwxr-x 28 joaquin joaquin 4096 Nov 24 11:14 net
drwxrwxr-x 7 joaquin joaquin 4096 Nov 24 11:02 scripts
drwxrwxr-x 4 joaquin joaquin 4096 Nov 24 11:02 security
drwxrwxr-x 21 joaquin joaquin 4096 Nov 24 11:42 sound
lrwxrwxrwx 1 joaquin joaquin 72 Nov 24 11:51 source → /home/joaquin/L4T/32.6.1/Linux_for_Tegra/source/public/kernel/kernel-4.9
-rw-rw-r-- 1 joaquin joaquin 5599377 Nov 24 11:00 System.map
-rw-rw-r-- 1 joaquin joaquin 2232440 Nov 24 10:59 .tmp_kallsyms1.o
-rw-rw-r-- 1 joaquin joaquin 13163085 Nov 24 10:59 .tmp_kallsyms1.S
-rw-rw-r-- 1 joaquin joaquin 2232440 Nov 24 11:00 .tmp_kallsyms2.o
-rw-rw-r-- 1 joaquin joaquin 13163085 Nov 24 11:00 .tmp_kallsyms2.S
-rw-rw-r-- 1 joaquin joaquin 5599377 Nov 24 11:00 .tmp_System.map
drwxrwxr-x 2 joaquin joaquin 24576 Nov 24 11:52 .tmp_versions
-rwxrwxr-x 1 joaquin joaquin 292178296 Nov 24 10:59 .tmp_vmlinux1
-rwxrwxr-x 1 joaquin joaquin 294406584 Nov 24 11:00 .tmp_vmlinux2
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 11:02 usr
-rw-rw-r-- 1 joaquin joaquin 2 Nov 24 10:58 .version
drwxrwxr-x 3 joaquin joaquin 4096 Nov 24 11:14 virt
-rwxrwxr-x 1 joaquin joaquin 294406584 Nov 24 11:00 vmlinux
-rw-rw-r-- 1 joaquin joaquin 218 Nov 24 11:00 .vmlinux.cmd
-rw-rw-r-- 1 joaquin joaquin 741899232 Nov 24 10:59 vmlinux.o

$ ls -la $TEGRA_MODULES_OUT
total 8
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 10:16 .
drwxrwxr-x 5 joaquin joaquin 4096 Nov 24 10:16 …

$ ls -la $TEGRA_FIRMWARE_OUT
total 8
drwxrwxr-x 2 joaquin joaquin 4096 Nov 24 10:16 .
drwxrwxr-x 5 joaquin joaquin 4096 Nov 24 10:16 …

This is normal?

Once the kernel and modules are compiled. How I install it? I need to move to any directory? Change the boot loader?
Once installed the new kernel when I update the system with apt upgrade, Will the kernel that I have compiled removed?

I also don’t know why, but it is common for some sources (as in download site or command) can lose something. This sort of occurrence does not happen a lot, but it also is not rare. That’s why I always download from the particular release’s source package.

The above is normal, and should do the job. I do want to mention that I didn’t see a starting make target of “tegra_defconfig” (or using “/proc/config.gz” after correct copy and unpack), but compile would have failed if you hadn’t performed that step.

For the case of adding a feature as a module you would delete all of the TEGRA_KERNEL_OUT content, and do the same operation, but after either the “make” of “tegra_defconfig” or the use of unpacking “/proc/config.gz”, then your next step would be to use a config editor to add that feature. I recommend something like “make O=$TEGRA_KERNEL_OUT nconfig” since “nconfig” has symbol search and runs on any command line.

Do note that if make with any of the config editors fails due to missing a package, that you should do this:
sudo apt-get install libncurses5-dev
…and then when you build everything there will be a module in this step:

make -j 6 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

If the source code for the driver is in some subdirectory, then as an example (completely contrived, not a real driver, just an example), if your module is compiled as “drivers/something/mysomething.ko”, the location you’d find the module is at:
$TEGRA_MODULES_OUT/lib/modules/$(uname -r)/kernel/drivers/something/mysomething.ko

You’d simply copy to the Jetson’s library path mirroring the above, but without the “$TEGRA_MODULES_OUT”. Then either reboot or use the “sudo depmod -a” and see if the module inserts and works.