Oh no, the edit is not after installation I did not copy anything to Jetson yet.
Also I have a doubt, after make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j<n> in host PC I should install modules(make O=~/intermediate INSTALL_MOD_PATH=~/modules modules_install) in the host PC itself right?
Also, why can’t I find squashfs in other devices but I’m still able to install ubuntu-frame?
Is make O=~/intermediate dtbs command mandatory to get squashfs.ko file?
How will only copying squashfs.ko to /lib/modules/4.9.253-tegra/kernel will enable compression in Jetson, there won’t be any dependency issue?
Yes, the modules_install step to the alternate output location is from the host PC. That should allow you to more easily find the squashfs.ko file (I don’t know if that is the exact file name, but probably it is). Assuming that is the right file name you could do this on the host PC to find it:
cd ~/modules
cd lib/modules
find . -name '*squash*'
The subdirectory which find sees would be the same matching subdirectory on the Jetson if you were to place it somewhere under “/lib/modules”.
There could be other dependencies, but I don’t think so for squashfs. If there are other dependencies, then the attempt to load the module will simply tell you about a missing dependency…after which you can look in the same host PC “~/modules/lib/modules” location with “find” to get the other dependency.
When you say you can’t find it, can I verify that this is from the location specified in the “INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install” step?
Also, if you go to the location specified in “O=$TEGRA_KERNEL_OUT”, what do you see from: grep -i squash .config
In fact, if you can, go to the “$TEGRA_KERNEL_OUT” location, and copy “.config” to “config.txt”, and then post it here on the forum:
cd $TEGRA_KERNEL_OUT
cp .config config.txt
Mostly I think you are almost there. If this does not explain it, then we can have you compile again and log it, then post the log.
I have put everything that I have done till now in this link, please let me know if I’m missing something. Also, sorry for not responding for 2 days i was on week off.
Export of your cross tool environment also seems correct.
Kernel source code version is correct from NVIDIA.
Added libraries is correct.
Empty new temporary output location for “O=” is good.
Basic config using tegra_defconfig is correct.
Addition of squashfs is where it went wrong.
Here I see “*” in the configuration of squashfs. This means it is being integrated into the kernel and not created as a module, which is the hard way to do this. I suggest you completely erase your “O='/home/factana/t4l-kernel'” location, and recreate it as an empty directory. Then do exactly as you did before, except use the “m” key to select that feature as a module (versus integrating into the kernel Image). You’d see an “<m>” there instead of “<*>”.
FYI, you did build that feature, but it wasn’t in the form of a module.
Hi @linuxdev, Thank you so much for patiently looking at the doc I uploaded.
For clarification I had tried with <m> when I built kernel initially and since I didn’t get a squahfs.ko file I tried with <*> this time because <*> was set by default when opened it config fine using nconfig. Sorry to ask is there anything else i’m missing here?
Try again with “m”. When toggled, it should show “<m>”. Not using “m” guarantees no module is built. Once you have this built we can find the module. In some cases a feature is not allowed as a module, but then the “m” key would not toggle, so you’d know immediately.
I’m saying <m> did come while toggling when I initially (I mean the first time) built the kernel and I was not able to find squashfs.ko and that is the time where I told you I’m not able to find squashfs.ko in the module folder.
I changed it to <*> when I was preparing this gist to see if it will make any difference, anyways I can try again with <m> and I will update the logs so that you can have look into it.
Go ahead and recompile with the “m” setting, using a clean intermediate output directory (the “O=/some/where”). Be sure to run tegra_defconfig again, then nconfig, followed by modules_prepare; then build modules. Once that is done, cd to that intermediate output location and run this command: find . -type f -name '*squash*.ko'
If that does not show up, the post the “.config” file in the intermediate output directory (the “O=/some/where” file “.config”).
If a “.ko” file shows up for squashfs, then you can run the “modules_install” to the alternate module location specified in the “INSTALL_MOD_PATH=/some/where/else” and cd to that location, followed by the same “find” command. If both this and the intermediate output location fail be sure to post the compile log. During compile you can append “2>&1 | tee log_build.txt” to get a log file of the compile. For example: make O=$TEGRA_KERNEL_OUT modules 2>&1 | tee log_build.txt
(this is the step we need the log from if the file is failing to show up)
Sorry for the mistake after installing i found squashfs.ko in /($INSTALL_MOD_PATH)/lib/modules/4.9.253-tegra/kernel/fs/squashfs$ ls squashfs.ko
I copied this to Jetson nano but still it shows the same error.
The notes leave some confusion, so here are some questions and comments:
If you “make mrproper”, then this completely cleans the kernel source. All configuration must then be recreated if and only if you are also building in the kernel source $TOP directory. When you run “make O=/some/where mrproper”, then the same thing applies to the “O=/some/where” directory. Before you build again, if you have never built in the kernel source $TOP without the “O=/some/where”, then you don’t need to “make mrproper” (without the “O=...”). You should “make mrproper” when first install kernel source, and if you wish to start over using “O=/some/where”, then you should “make O=/some/where mrproper” each time you wish to start from scratch (or delete “/some/where” and create a new empty “/some/where”).
Once you’ve started to rework at “O=/some/where”, then you should once again set up kernel configuration. This is likely “make O=/some/where tegra_defconfig”, making sure CONFIG_LOCALVERSION is set at “/some/where/.config”, and propagating configuration via “make O=/some/where modules_prepare”. Then add your squashfs feature in the config editor, e.g., “make O=/some/where nconfig”. Following this you are free to build “make O=/some/where modules”.
Looking at your “.config”, was this from the “O=/some/where/.config”? This looks correct, and if you did all of the config steps, this should work. You did create a squashfs.ko file, which is correct, and which could be copied to the right location on the Jetson.
We are performing a lot of steps, and so I need to know if there was an error indicated in any of the “sudo depmod -a” or “sudo modprobe squashfs”. If there is an error I need to know the exact error (you could even monitor “dmesg --follow” while inserting the module to see if anything is noted there in addition to the actual command line you typed in).
An addtional command is to explicitly install that module via what follows, and see what error is visible (I don’t know if I’m stating the right path, but adjust if not…I’m going by your previous posts, and so this path is probably correct): sudo insmod /lib/modules/4.9.253-tegra/kernel/fs/squashfs/squashfs.ko
Yes I figured so removed all files and recreated everything and then I got squashfs.ko in INSTALL_MOD_PATH.
Well I’m getting error here
[ 2.295071] squashfs: SQUASHFS error: Xattrs in filesystem, these will be ignored
[ 2.302737] squashfs: SQUASHFS error: unable to read xattr id index table
Also I had tried this command
And I got this error message:
$ sudo insmod /lib/modules/4.9.253-tegra/kernel/fs/squashfs/squashfs.ko
insmod: ERROR: could not insert module /lib/modules/4.9.253-tegra/kernel/fs/squashfs/squashfs.ko: Device or resource busy
Seems like I’m missing something again and I guess it was xattr option and i don’t think I enabled it in .config file
“Xattrs” refers to “extended attributes”. On Linux this implies SElinux, the “security enhanced Linux” which adds “roles” to help with filesystem security (this is in addition to the normal permissions). Jetson’s don’t use this (they could, but I don’t know of anyone who does use this). If these attributes are ignored, then this is ok and not an issue. I am guessing that these were copied from your host PC when generating the Jetson filesystem (a host PC would normally have these, but be set to non-enforcing mode until someone sets up for a higher security level; SElinux warnings might occur in logs, but these don’t really have any operational effect if non-enforcing).
However, it is odd to see this from insmod. Squashfs itself might have been configured to use extended attributes, but not have them available in terms of kernel features which would understand xattrs, and thus not be able to load. Or, as a sort of inverse of that speculation, perhaps when squashfs sees a filesystem with extended attributes, this might trigger use of xattrs which are unavailable. Still, seeing the attributes are to be ignored, I wonder if seeing this as an “error” (and not a warning) has any meaning. Perhaps this is why module load fails, or perhaps this is unrelated.
This error is more interesting:
I say this because it implies something is already accessing that module or otherwise using it. Once again though, it is confusing to understand just what is accessing the module. Does “lsmod” show squashfs when this error shows up? From what you’ve said I would say likely it is not showing up, which makes the error different than being busy due to already being loaded.
If you can enable CONFIG_SQUASHFS_XATTR as a module, then you are correct, this would be the next step. After adding that module, and running “sudo depmod -a”, then it should be possible to either have this “just work” after reboot, or else use “sudo modprobe <module name>” (depending on which one depends on the other it might or might not matter which you modprobe first). Incidentally, this is another reason why one uses the configuration editor and would not normally hand edit the .config file: Dependencies which are mandatory should automatically be taken care of if using nconfig or menuconfig, although in this case it might not be true. Perhaps the module is busy because it is waiting for xattrs function triggered by the existence of SElinux labels, but otherwise might not be a dependency.
Well what do you suggest me to do now? Also as I remember I don’t think CONFIG_SQUASHFS_XATTR can be enabled as module
Just adding a note here, I simply opened the squashfs.ko file in a text editor and I could see the host pc location in many places, I’m attaching the file if you would like to have a look into it.
Normally one would examine a kernel module or library with something like “objdump” (or the cross-objdump). I see it is an aarch64 file, which is correct.
Are you sure CONFIG_SQUASHFS_XATTR is not available as a module? If you’ve set up all other configuration, and you go to that in “nconfig” or “menuconfig” (I suggest nconfig since it can search for symbol “squashfs_xattr”), does the “m” key not toggle the feature? If it does, then it is simple to add this as a module. If not, then we can go through setting up a new full kernel and modules.
