Hi,
I think we don’t have experience dealing with it, and you may need to search here on the forum to see if others have done that before.
You might find this useful:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-enabling_and_disabling_selinux-dracut-parameters
One can enable with a command line option to the kernel, or I think also in “/etc/sysctl.conf” (which passes some arguments to a kernel). Just be very very careful to have a selectable boot entry which does not enforce until you know it is working correctly.
Note that if the filesystem (or the software or kernel features needed) does not have the SElinux labels, that it can’t work until labeled. I have not worked on that in a long time so I can’t give details.
Hi, I attempted to configure the .config file through Linux_for_Tegra/source/public/kernel/kernel-5.10, and doing make menuconfig, and enable AppArmor as the preferred LVM. Attached is generated .config file.
theconfigoutput.txt (218.3 KB)
Next I
mkdir kernel_out
./nvbuild.sh -o $PWD/kernel_out
After creating a Image.backup in /boot, I execute the following command:
ubu@ubu-desktop:~/Downloads/Linux_for_Tegra/source/public/kernel/kernel-5.10/arch/arm64/boot$ mv Image /boot
reboot
However, the kernel loaded still do not contain the configuration I specify in the .config file.
For the kernel I did not see “CONFIG_LOCALVERSION” set. I can’t go through all of the .config, but was the “tegra_defconfig” target run prior to the “menuconfig” target? Incidentally, nconfig adds symbol search, but is otherwise the same as menuconfig.
Did you set CONFIG_LOCALVERSION some other way? When booted, what do you see from “uname -r”? Do you see files if you go here:
cd /lib/modules/$(uname -r)/kernel
…and then:
ls
Do note that on Orin the extlinux.conf nvidia-kernel package can overwrite this. See:
https://forums.developer.nvidia.com/t/sometimes-extlinux-conf-seems-to-be-overwritten/257985/4
Also, under some circumstances with eMMC models, a kernel will be loaded from a signed partition instead of from “/boot”. Normally the “/boot” content would take precedence, but if there is some sort of error in the configuration, the partition will be the fallback Image. Also, if security fuses are burned (not available on SD card models), then only the partition Image can be used.
I don’t have the NX, but there is probably a way in UEFI to manually load the Image.backup.
Hi,
I do not see which part of the instruction (Kernel Customization — Jetson Linux Developer Guide documentation) stated anything about setting CONFIG_LOCALVERSION; where and what should I set it to?
Where can I find the “tegra_defconfig”?
This is my output for the following:
ubu@ubu-desktop:~/Downloads/Linux_for_Tegra/source/public/kernel_out/usr$ uname -r
5.10.104-tegra
ubu@ubu-desktop:/lib/modules/5.10.104-tegra/kernel$ ls
arch crypto drivers fs lib net sound
Also I would like to add on for
Replace Linux_for_Tegra/rootfs/usr/lib/modules/$(uname -r)/kernel/drivers/gpu/nvgpu/nvgpu.ko with a copy of this file:
$kernel_out/drivers/gpu/nvgpu/nvgpu.ko
For the device tree, replace the files in Linux_for_Tegra/kernel/dtb/ with a copy from:
$kernel_out/arch/arm64/boot/dts/nvidia/
Does this mean I have to have the drivers for Driver Package and Sample Root Filesystem from https://developer.nvidia.com/embedded/jetson-linux-r3521 ? Because currently I only download the sources for it and did not complete step 5 and 6 because there was only Linux_for_Tegra/source .
Here is a short bit on “CONFIG_LOCALVERSION”:
https://forums.developer.nvidia.com/t/how-to-fix-xorg-conf-in-jetson-orin/229155/12
I am not including the cross compile options. If cross compiling, what follows is still correct, but you’d also need to cross compile setup.
Before I add other information, it is good to be aware that there is an optional “O=/some/where” argument in kernel compile. This is for temporary external locations such that you can keep the original kernel source clean. I like to make the kernel source owned by root, readable by everyone, but writable only by root (with sudo). Then, for the original source, I do this to make sure it is pristine (the exception is if I’m making this my kernel headers link…a different topic):
sudo make mrproper
(the source itself is now “pristine”)
Then, for all builds, I use a regular user. That user should not be able to write in the source directory. You would create an empty directory, and all configuration and output would go there. As an example, you could “mkdir ~/kernel”. Then you set an environment variable to that location for consistency and ease of use. Example:
mkdir ~/kernel
cd ~/kernel
export TEGRA_KERNEL_OUT=`pwd`
# verify:
echo $TEGRA_KERNEL_OUT
Now go back to the kernel source. You can set basic configuration via:
make O=$TEGRA_KERNEL_OUT tegra_defconfig
Then you can use an application such as menuconfig or nconfig (my favorite, it has a symbol search, but otherwise is the same as menuconfig). Example:
make O=$TEGRA_KERNEL_OUT nconfig
(note that from now on all make commands include “O=$TEGRA_KERNEL_OUT”)
You can edit CONFIG_LOCALVERSION either in the editor or on command line with a regular ehttps://forums.developer.nvidia.com/t/how-to-fix-xorg-conf-in-jetson-orin/229155/12ditor. The only reason you can do this with a regular editor is because CONFIG_LOCALVERSION has no dependencies. Unless you absolutely know a feature has no dependencies, you should never edit the “.config” file manually.
For manual edit, you would edit “$TEGRA_KERNEL_OUT/.config”, search for CONFIG_LOCALVERSION, and set it like this (I am assuming you use “-tegra”, the default, but this is not always the case):
CONFIG_LOCALVERSION="-tegra"
(quotes are optional)
If your kernel source is version 5.10.104, and if your CONFIG_LOCALVERSION is “-tegra”, then the output of “uname -r” will be “5.10.104-tegra”. This is the source code version, plus append of CONFIG_LOCALVERSION. The reason this matters is because this is part of where the kernel looks for loadable modules. Modules are found at:
/lib/modules/$(uname -r)/kernel
Regarding build targets “menuconfig” and “nconfig”: These are very much the same thing, and are how you change configuration. This is used because they understand dependencies. Every feature and driver has a “symbol”, and you are editing symbols. One symbol can depend on another, or it might be incompatible with some other symbol. In the editor, if you add or change something with the “y” key, then it is a change to the integrated kernel (the “Image”). If you add or change something withttps://forums.developer.nvidia.com/t/how-to-fix-xorg-conf-in-jetson-orin/229155/12h the “m” key, then it is in the form of a module.
You probably should stick to module format when possible. Because of how modules are found and loaded, this means you’d also need to have a matching CONFIG_LOCALVERSION (in this case “-tegra”). On the other hand, if you are changing a feature with the integrated kernel (the Image file), then you need to change CONFIG_LOCALVERSION and build and install all modules again (but to the new location caused by change in “uname -r”).
“tegra_defconfig” is just a build target. Assuming you are starting with clean source, and no configuration, you might start with that as a build target. Then you can use an editor, e.g., nconfig, to make edits. Edits can include CONFIG_LOCALVERSION if desired. Example, building from the original. I will call the top of the kernel source “$TOP”, and the temporary output location “TEGRA_KERNEL_OUT” (you could use a different name, it is arbitrary, picked because it is used with much documentation).
mkdir ~/kernel
cd ~/kernel
export TEGRA_KERNEL_OUT=`pwd`
# I assume you already set TOP to the location of the kernel source.
cd $TOP
https://forums.developer.nvidia.com/t/how-to-fix-xorg-conf-in-jetson-orin/229155/12
# This is your only use of sudo in build:
sudo make mrproper
https://forums.developer.nvidia.com/t/topic/193640/11
# From now on we use O=$TEGRA_KERNEL_OUT.
make O=$TEGRA_KERNEL_OUT tegra_defconfig
make O=$TEGRA_KERNEL_OUT nconfig
# Symbol search is case insensitive, and does not need the leading "CONFIG_", althoughhttps://forums.developer.nvidia.com/t/topic/193640/11
# you can use that if you want. Look at the key bindings shown at the bottom. Now
# perform a symbol search for "localversion". Or simply go there if you know where it is.
# Set this up, hit the enter key, then enter the string (assumes you're going to reuse the
# original kernel Image, and work only on modules):
-tegra
# So now base configuration is the default, and module search is to the original module
# location. Kind of nice that any module build only needs to be copied as a file. Make
# whatever edits you need from now on in the nconfig editor. Search by symbol name
# if you need. Use the "m" key to enable. If the "m" key is not allowed, then you must
# change CONFIG_LOCALVERSION, e.g., it could be:
-custom
Now save and exit nconfig. If you are using a script, then things are ready to go. If you are manually building (which is what I trust), and if you are only building modules:
make O=$TEGRA_KERNEL_OUT modules_prepare
# I am assuming 12 CPU cores, but adjust "-j number" to the number of cores.
make O=$TEGRA_KERNEL_OUT -j 12 modules
If you want more information on manual build, just ask. On the other hand, here is some more information:
- https://forums.developer.nvidia.com/t/agx-xavier-fpd-link-d3-engineering-board-bsp/231272/2
- https://forums.developer.nvidia.com/t/topic/193640/11
Important note: There are different ways to install kernels and modules. Things have changed somewhat in Orin. Probably you will run into official docs whereby kernels are added via flash, but often you don’t need to flash. If installing only new modules, then no flash will ever be needed (well, an exception occurs if you need an initrd to contain a module for an alternate filesystem type). Most of the details are in installing the entire kernel (which in turn means also installing all new modules). I will advise you to always leave the original kernel, device tree, and modules in place. Then create an alternate boot entry if the kernel Image is changing such that you have a fallback boot option. If it is just a module, then it is quite simple.
Hi, I am just trying to enable APPARMOR as a LSM and ISCSI Initiator support (Jetson nano and iscsi module support). However it appears that I also need to modify kernel-4.9/drivers/scsi/libiscsi_tcp.c . May you assist me in providing the commands I need to execute to do all this? I understand that after saving and exiting nconfig, I need to execute make O=$TEGRA_KERNEL_OUT -j 8 Image, and copy it to Image? Because current after copying Image only, I cannot boot up at all.
Also, where exactly do I add in -terga? CONFIG_LOCALVERSION ?
I can’t give you all of the information, but I can give you somewhere to start. First of all, if you are editing libiscsi_tcp.c, are the changes for editing also from a 5.x series kernel? If you try a 4.x series code on 5.x, then it gets a lot messier rather quickly. Sometimes it gets messy even on the same series if you need to back port a feature. So what I’m going to mention is about file editing, and not whether or not your edits will work.
You want to make sure your source code is pristine before you ever start. I will refer to the directory containing the source as TOP or $TOP. All of your build attempts should start from an empty output location. The docs usually say TEGRA_KERNEL_OUT, but I’ll just say OUT or $OUT (same thing, shorter word). Example starting info:
cd $TOP
sudo make mrproper
# If the temp output already exists, wipe it out, but be VERY careful your
# environment variable is correctly set, and is for a location not owned by root.
# Verify once:
echo $OUT
rm -Rf $OUT
mkdir $OUT
# Now edit $TOP drivers/scsi/libiscsi_tcp.c
# After edit, configure:
make O=$OUT tegra_defconfig
# Now set up your config customizations:
make O=$OUT nconfig
# Use a custom CONFIG_LOCALVERSION. This has no dependencies, so you could
# manually edit the CONFIG_LOCALVERSION in $OUT/.config to be something like
# "-custom" or "-apparmor". Name your final Image after this, e.g., rename it as
# Image-apparmor. Don't remove your old Image.
Since you are changing source code you very likely need to rebuild both the kernel and all modules, although it is possible the module will still work without replacing the kernel (if and only if no feature changes in “=y”). Even if you are not working with anything other than modules, you really need to test if the integrated Image builds, so build that. If it works, then move on to modules. Example:
make O=$OUT -j 12 Image
make O=$OUT -j 12 modules
Note that I am not using cross compile flags, but this would still be accurate for cross compile (only you’d need to add cross tool and ARCH setup).
If you are only working on modules, and if Image builds, then you can try setting CONFIG_LOCALVERSION back to “-tegra”. This would allow you to test adding this module as a replacement to any existing module at:
/lib/modules/$(uname -r)/kernel/drivers/scsi/
Should this not be just a module install, or should the module not work correctly by itself, change “CONFIG_LOCALVERSION” back to something custom, e.g., “-apparmor”. Install Image as “/boot/Image-apparmor”, and install all modules to “/lib/modules/$(uname -r)/kernel” (please note this is what the new uname -r will be, not the old one). Add an alternate boot entry so the original is still present as backup. You can always remove the old kernel if the new one works, but one reason to not do this is if a package update wants to overwrite Image.
I do not have an Orin NX. You’ll probably want to start a new thread on adding alternate boot entries for your release if you require changing the Image file. For a module, it is just a simple file copy.
Hi, do I need to copy any other files other than Image if I am modifying the modules too? If yes may you clarify from where to where? Also would a make install solve the issue? I am currently still copying the Image after complying, and it is still not booting up if I boot from the new kernel.
If you modify the Image, then you need to install everything again, including modules. I would highly recommend modifying CONFIG_LOCALVERSION as well if you modify the Image, which implies the original kernel and modules can be kept while testing (if you do something wrong with the Image, then boot can fail and you might need to flash from scratch; working on only a module is much much safer). If you’ve set up an alternate boot to a new kernel with a new CONFIG_LOCALVERSION (which changes “uname -r” and thus the location modules are searched for), then the original kernel is still in place while testing possible failed kernels.
If you did install kernel and modules, and it fails, then you should post these two additional notes:
- What the
CONFIG_LOCALVERSIONwas. - The serial console boot log.
- Possibly what you added or changed in the configuration.
I still boot into the original kernel:
bu@ubu-desktop:~/Downloads/test/Linux_for_Tegra/source/public/kernel/kernel-5.10$ uname -a
Linux ubu-desktop 5.10.104-tegra #1 SMP PREEMPT Tue Jan 24 15:09:44 PST 2023 aarch64 aarch64 aarch64 GNU/Linux
`
As for the custom kernel, I changed nothing except CONFIG_LOCALVERSION. for controlled set purposes Upon adding the new Image and new FDT as shown in /boot/extlinux/extlinux.conf
LABEL primary5
MENU LABEL primary5 kernel
LINUX /boot/Image-another
FDT /boot/dtb/tegra234-p3767-0000-p3509-a02.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=6ff2294c-fb67-43fc-b6eb-bc07a575ae9a rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0
I used your commands, followed by make modules_install too, and make install.
It leads to a symbolic link alreadly:
ubu@ubu-desktop:/boot$ ls -la
total 757072
drwxr-xr-x 5 root root 12288 Aug 21 16:09 .
drwxr-xr-x 19 root root 4096 Aug 17 16:40 ..
-rw-r--r-- 1 root root 341416 Aug 21 16:09 atb
drwxr-xr-x 2 root root 12288 Aug 21 14:18 backup
-rw-r--r-- 1 root root 223409 Aug 21 15:57 config-5.10.104-terga-another
-rw-r--r-- 1 root root 223410 Aug 21 14:27 config-5.10.104-terga-CUSTOMYO-tegra
-rw-r--r-- 1 root root 223410 Aug 21 14:25 config-5.10.104-terga-CUSTOMYO-tegra.old
drwxr-xr-x 2 root root 4096 Aug 21 16:09 dtb
drwxr-xr-x 2 root root 4096 Aug 21 16:11 extlinux
-rw-r--r-- 1 root root 33653248 Aug 17 16:25 Image
-rw-r--r-- 1 root root 33323520 Aug 21 16:08 Image-another
-rw-r--r-- 1 root root 33653248 Aug 18 16:11 Image.backup
-rw-r--r-- 1 root root 33657344 Aug 18 16:12 Image-customa
-rw-r--r-- 1 root root 33323520 Aug 21 13:58 Imagecustomyo
-rw-r--r-- 1 root root 33323520 Aug 21 11:10 ImageNew1
-rw-r--r-- 1 root root 33653248 Jan 25 2023 Image.t19x
-rw-r--r-- 1 root root 4096 Jan 25 2023 Image.t19x.sig
-rw-r--r-- 1 root root 33323520 Aug 18 17:38 Image-terga-customb
-rw-r--r-- 1 root root 8408490 Aug 17 16:25 initrd
lrwxrwxrwx 1 root root 33 Aug 21 15:58 initrd.img -> initrd.img-5.10.104-terga-another
-rw-r--r-- 1 root root 31324998 Aug 18 17:52 initrd.img-5.10.104-tegra
-rw-r--r-- 1 root root 287662827 Aug 21 15:58 initrd.img-5.10.104-terga-another
-rw-r--r-- 1 root root 33284444 Aug 21 14:27 initrd.img-5.10.104-terga-CUSTOMYO-tegra
lrwxrwxrwx 1 root root 40 Aug 21 15:58 initrd.img.old -> initrd.img-5.10.104-terga-CUSTOMYO-tegra
-rw-r--r-- 1 root root 8408496 Jan 25 2023 initrd.t19x
-rw-r--r-- 1 root root 4096 Jan 25 2023 initrd.t19x.sig
-rw-r--r-- 1 root root 341468 Aug 17 16:25 kernel_tegra234-p3767-0000-p3509-a02.dtb
-rw-r--r-- 1 root root 6475539 Aug 21 15:57 System.map-5.10.104-terga-another
-rw-r--r-- 1 root root 6475539 Aug 21 14:27 System.map-5.10.104-terga-CUSTOMYO-tegra
-rw-r--r-- 1 root root 6475539 Aug 21 14:25 System.map-5.10.104-terga-CUSTOMYO-tegra.old
-rw-r--r-- 1 root root 13523 Aug 21 14:18 tegra194-p2822-camera-dual-imx274-overlay.dtbo
-rw-r--r-- 1 root root 3234 Aug 21 14:18 tegra194-p2822-camera-e2832-overlay.dtbo
-rw-r--r-- 1 root root 4354 Aug 21 14:18 tegra194-p2822-camera-e3326-overlay.dtbo
-rw-r--r-- 1 root root 4167 Aug 21 14:18 tegra194-p2822-camera-e3331-overlay.dtbo
-rw-r--r-- 1 root root 18595 Aug 21 14:18 tegra194-p2822-camera-e3333-overlay.dtbo
-rw-r--r-- 1 root root 8320 Aug 21 14:18 tegra194-p2822-camera-eCAM130A_CUXVR-overlay.dtbo
-rw-r--r-- 1 root root 8690 Aug 21 14:18 tegra194-p2822-camera-imx185-overlay.dtbo
-rw-r--r-- 1 root root 7086 Aug 21 14:18 tegra194-p2822-camera-imx390-overlay.dtbo
-rw-r--r-- 1 root root 303066 Aug 21 14:18 tegra194-p2888-0001-e3366-1199.dtb
-rw-r--r-- 1 root root 1087 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-adafruit-sph0645lm4h.dtbo
-rw-r--r-- 1 root root 1083 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-adafruit-uda1334a.dtbo
-rw-r--r-- 1 root root 1297 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-csi.dtbo
-rw-r--r-- 1 root root 391087 Aug 21 14:18 tegra194-p2888-0001-p2822-0000.dtb
-rw-r--r-- 1 root root 3987 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-fe-pi-audio.dtbo
-rw-r--r-- 1 root root 4585 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-hdr40.dtbo
-rw-r--r-- 1 root root 321607 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-imx185_v1.dtb
-rw-r--r-- 1 root root 320385 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-imx274-hdmi.dtb
-rw-r--r-- 1 root root 1833 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-m2ke.dtbo
-rw-r--r-- 1 root root 391124 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-maxn.dtb
-rw-r--r-- 1 root root 1059 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-overlay.dtbo
-rw-r--r-- 1 root root 3183 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-respeaker-4-mic-array.dtbo
-rw-r--r-- 1 root root 3219 Aug 21 14:18 tegra194-p2888-0001-p2822-0000-respeaker-4-mic-lin-array.dtbo
-rw-r--r-- 1 root root 1055 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-adafruit-sph0645lm4h.dtbo
-rw-r--r-- 1 root root 1051 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-adafruit-uda1334a.dtbo
-rw-r--r-- 1 root root 1817 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-csi.dtbo
-rw-r--r-- 1 root root 402513 Aug 21 14:18 tegra194-p2888-0004-e3900-0000.dtb
-rw-r--r-- 1 root root 4874 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-dual-imx274.dtbo
-rw-r--r-- 1 root root 3955 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-fe-pi-audio.dtbo
-rw-r--r-- 1 root root 4389 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-hdr40.dtbo
-rw-r--r-- 1 root root 3035 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-imx274.dtbo
-rw-r--r-- 1 root root 3151 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-respeaker-4-mic-array.dtbo
-rw-r--r-- 1 root root 3187 Aug 21 14:18 tegra194-p2888-0004-e3900-0000-respeaker-4-mic-lin-array.dtbo
-rw-r--r-- 1 root root 439 Aug 21 14:18 tegra194-p2888-0005-overlay.dtbo
-rw-r--r-- 1 root root 303002 Aug 21 14:18 tegra194-p2888-0006-e3366-1199.dtb
-rw-r--r-- 1 root root 304013 Aug 21 14:18 tegra194-p2888-0008-e3366-1199.dtb
-rw-r--r-- 1 root root 392173 Aug 21 14:18 tegra194-p2888-0008-p2822-0000.dtb
-rw-r--r-- 1 root root 392143 Aug 21 14:18 tegra194-p2888-0008-p2822-0000-maxn.dtb
-rw-r--r-- 1 root root 392139 Aug 21 14:18 tegra194-p2888-0008-p2822-0000-noecc.dtb
-rw-r--r-- 1 root root 907 Aug 21 14:18 tegra194-p2888-0008-p2822-0000-overlay.dtbo
-rw-r--r-- 1 root root 392249 Aug 21 14:18 tegra194-p2888-0008-p2822-0000-safety.dtb
-rw-r--r-- 1 root root 418342 Aug 21 14:18 tegra194-p2888-as-0006-p2822-0000.dtb
-rw-r--r-- 1 root root 418342 Aug 21 14:18 tegra194-p2888-as-p3668-p2822-0000.dtb
-rw-r--r-- 1 root root 323852 Aug 21 14:18 tegra194-p3668-0000-p3509-0000.dtb
-rw-r--r-- 1 root root 323885 Aug 21 14:18 tegra194-p3668-0001-p3509-0000.dtb
-rw-r--r-- 1 root root 1083 Aug 21 14:18 tegra194-p3668-all-p3509-0000-adafruit-sph0645lm4h.dtbo
-rw-r--r-- 1 root root 1079 Aug 21 14:18 tegra194-p3668-all-p3509-0000-adafruit-uda1334a.dtbo
-rw-r--r-- 1 root root 2815 Aug 21 14:18 tegra194-p3668-all-p3509-0000-camera-imx219-dual.dtbo
-rw-r--r-- 1 root root 3071 Aug 21 14:18 tegra194-p3668-all-p3509-0000-camera-imx477-dual.dtbo
-rw-r--r-- 1 root root 2994 Aug 21 14:18 tegra194-p3668-all-p3509-0000-camera-imx477-imx219.dtbo
-rw-r--r-- 1 root root 323937 Aug 21 14:18 tegra194-p3668-all-p3509-0000.dtb
-rw-r--r-- 1 root root 3983 Aug 21 14:18 tegra194-p3668-all-p3509-0000-fe-pi-audio.dtbo
-rw-r--r-- 1 root root 5605 Aug 21 14:18 tegra194-p3668-all-p3509-0000-hdr40.dtbo
-rw-r--r-- 1 root root 2109 Aug 21 14:18 tegra194-p3668-all-p3509-0000-m2ke.dtbo
-rw-r--r-- 1 root root 3179 Aug 21 14:18 tegra194-p3668-all-p3509-0000-respeaker-4-mic-array.dtbo
-rw-r--r-- 1 root root 3215 Aug 21 14:18 tegra194-p3668-all-p3509-0000-respeaker-4-mic-lin-array.dtbo
-rw-r--r-- 1 root root 2187 Aug 21 14:18 tegra194-p3668-p3509-overlay.dtbo
-rw-r--r-- 1 root root 342737 Aug 21 14:18 tegra234-p3701-0000-as-p3701-0004-p3737-0000.dtb
-rw-r--r-- 1 root root 335035 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0000-p3737-0000.dtb
-rw-r--r-- 1 root root 333337 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0001-p3737-0000.dtb
-rw-r--r-- 1 root root 336928 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-a1-cphy.dtb
-rw-r--r-- 1 root root 337505 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-c1-dphy.dtb
-rw-r--r-- 1 root root 337331 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-c1-dsc-dphy.dtb
-rw-r--r-- 1 root root 337144 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-tianma-a-dphy.dtb
-rw-r--r-- 1 root root 336800 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-tianma-b-dphy.dtb
-rw-r--r-- 1 root root 333369 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0003-p3737-0000.dtb
-rw-r--r-- 1 root root 333369 Aug 21 14:18 tegra234-p3701-0000-as-p3767-0004-p3737-0000.dtb
-rw-r--r-- 1 root root 337093 Aug 21 14:18 tegra234-p3701-0000-as-pxxxx-p3737-0000.dtb
-rw-r--r-- 1 root root 418747 Aug 21 14:18 tegra234-p3701-0000-p3737-0000.dtb
-rw-r--r-- 1 root root 419136 Aug 21 14:18 tegra234-p3701-0000-p3737-0000-kexec.dtb
-rw-r--r-- 1 root root 284143 Aug 21 14:18 tegra234-p3701-0000-p3740-0000.dtb
-rw-r--r-- 1 root root 248894 Aug 21 14:18 tegra234-p3701-0002-p3711-0000.dtb
-rw-r--r-- 1 root root 272686 Aug 21 14:18 tegra234-p3701-0002-p3740-0002-b01.dtb
-rw-r--r-- 1 root root 272698 Aug 21 14:18 tegra234-p3701-0002-p3740-0002.dtb
-rw-r--r-- 1 root root 272702 Aug 21 14:18 tegra234-p3701-0002-p3740-0002-safety.dtb
-rw-r--r-- 1 root root 418742 Aug 21 14:18 tegra234-p3701-0004-p3737-0000.dtb
-rw-r--r-- 1 root root 838 Aug 21 14:18 tegra234-p3701-overlay.dtbo
-rw-r--r-- 1 root root 1087 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-adafruit-sph0645lm4h.dtbo
-rw-r--r-- 1 root root 1083 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-adafruit-uda1334a.dtbo
-rw-r--r-- 1 root root 1989 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-csi.dtbo
-rw-r--r-- 1 root root 3987 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-fe-pi-audio.dtbo
-rw-r--r-- 1 root root 3906 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-hdr40.dtbo
-rw-r--r-- 1 root root 1477 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-m2ke.dtbo
-rw-r--r-- 1 root root 3183 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-respeaker-4-mic-array.dtbo
-rw-r--r-- 1 root root 3219 Aug 21 14:18 tegra234-p3737-0000-p3701-0000-respeaker-4-mic-lin-array.dtbo
-rw-r--r-- 1 root root 3202 Aug 21 14:18 tegra234-p3737-audio-codec-rt5640.dtbo
-rw-r--r-- 1 root root 4398 Aug 21 14:18 tegra234-p3737-audio-codec-rt5658-40pin.dtbo
-rw-r--r-- 1 root root 3318 Aug 21 14:18 tegra234-p3737-audio-codec-rt5658.dtbo
-rw-r--r-- 1 root root 10222 Aug 21 14:18 tegra234-p3737-camera-dual-hawk-ar0234-e3653-overlay.dtbo
-rw-r--r-- 1 root root 12915 Aug 21 14:18 tegra234-p3737-camera-dual-imx274-overlay.dtbo
-rw-r--r-- 1 root root 4135 Aug 21 14:18 tegra234-p3737-camera-e3331-overlay.dtbo
-rw-r--r-- 1 root root 18563 Aug 21 14:18 tegra234-p3737-camera-e3333-overlay.dtbo
-rw-r--r-- 1 root root 17986 Aug 21 14:18 tegra234-p3737-camera-hawk-owl-overlay.dtbo
-rw-r--r-- 1 root root 8114 Aug 21 14:18 tegra234-p3737-camera-imx185-overlay.dtbo
-rw-r--r-- 1 root root 7054 Aug 21 14:18 tegra234-p3737-camera-imx390-overlay.dtbo
-rw-r--r-- 1 root root 3274 Aug 21 14:18 tegra234-p3737-overlay.dtbo
-rw-r--r-- 1 root root 17842 Aug 21 14:18 tegra234-p3740-camera-hawk-owl-overlay.dtbo
-rw-r--r-- 1 root root 3268 Aug 21 14:18 tegra234-p3740-camera-p3785-overlay.dtbo
-rw-r--r-- 1 root root 895 Aug 21 14:18 tegra234-p3740-overlay-pcie.dtbo
-rw-r--r-- 1 root root 341536 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0001-p3509-a02.dtb
-rw-r--r-- 1 root root 341778 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0001-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 341568 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0003-p3509-a02.dtb
-rw-r--r-- 1 root root 341802 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0003-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 341560 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0004-p3509-a02.dtb
-rw-r--r-- 1 root root 341802 Aug 21 14:18 tegra234-p3767-0000-as-p3767-0004-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 1087 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-adafruit-sph0645lm4h.dtbo
-rw-r--r-- 1 root root 1083 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-adafruit-uda1334a.dtbo
-rw-r--r-- 1 root root 696 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-csi.dtbo
-rw-r--r-- 1 root root 341492 Aug 21 14:18 tegra234-p3767-0000-p3509-a02.dtb
-rw-r--r-- 1 root root 3987 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-fe-pi-audio.dtbo
-rw-r--r-- 1 root root 3158 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-hdr40.dtbo
-rw-r--r-- 1 root root 1477 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-m2ke.dtbo
-rw-r--r-- 1 root root 3183 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-respeaker-4-mic-array.dtbo
-rw-r--r-- 1 root root 3219 Aug 21 14:18 tegra234-p3767-0000-p3509-a02-respeaker-4-mic-lin-array.dtbo
-rw-r--r-- 1 root root 341734 Aug 21 14:18 tegra234-p3767-0000-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 696 Aug 21 14:18 tegra234-p3767-0000-p3768-0000-csi.dtbo
-rw-r--r-- 1 root root 341492 Aug 21 14:18 tegra234-p3767-0001-p3509-a02.dtb
-rw-r--r-- 1 root root 341734 Aug 21 14:18 tegra234-p3767-0001-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 341540 Aug 21 14:18 tegra234-p3767-0003-p3509-a02.dtb
-rw-r--r-- 1 root root 341782 Aug 21 14:18 tegra234-p3767-0003-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 341492 Aug 21 14:18 tegra234-p3767-0004-p3509-a02.dtb
-rw-r--r-- 1 root root 341734 Aug 21 14:18 tegra234-p3767-0004-p3768-0000-a0.dtb
-rw-r--r-- 1 root root 2731 Aug 21 14:18 tegra234-p3767-camera-imx219-dual.dtbo
-rw-r--r-- 1 root root 2987 Aug 21 14:18 tegra234-p3767-camera-imx477-dual.dtbo
-rw-r--r-- 1 root root 2910 Aug 21 14:18 tegra234-p3767-camera-imx477-imx219.dtbo
-rw-r--r-- 1 root root 2731 Aug 21 14:18 tegra234-p3767-camera-p3768-imx219-dual.dtbo
-rw-r--r-- 1 root root 3352 Aug 21 14:18 tegra234-p3767-camera-p3768-imx477-dual-4lane.dtbo
-rw-r--r-- 1 root root 2987 Aug 21 14:18 tegra234-p3767-camera-p3768-imx477-dual.dtbo
-rw-r--r-- 1 root root 2910 Aug 21 14:18 tegra234-p3767-camera-p3768-imx477-imx219.dtbo
lrwxrwxrwx 1 root root 30 Aug 21 15:57 vmlinuz -> vmlinuz-5.10.104-terga-another
-rw-r--r-- 1 root root 33323520 Aug 21 15:57 vmlinuz-5.10.104-terga-another
-rw-r--r-- 1 root root 33323520 Aug 21 14:27 vmlinuz-5.10.104-terga-CUSTOMYO-tegra
-rw-r--r-- 1 root root 33323520 Aug 21 14:25 vmlinuz-5.10.104-terga-CUSTOMYO-tegra.old
lrwxrwxrwx 1 root root 37 Aug 21 14:27 vmlinuz.old -> vmlinuz-5.10.104-terga-CUSTOMYO-tegra
However:
ubu@ubu-desktop:/boot$ sudo update-initramfs -c -k 5.10.104-terga-another
update-initramfs: Generating /boot/initrd.img-5.10.104-terga-another
W: Couldn't identify type of root file system for fsck hook
W: Couldn't identify type of root file system for fsck hook
The error also appear during make install.
Hi, would like to add on, after I managed to boot into custom kernel now. The screen is detected and apply to display bios and kernel selection. However, after booting it is not showing anything. I ssh inside, and check the uname -a, it is the selected custom kernel.
I don’t know if this is because of the initrd (initial ramdisk, which is related to the update-initramfs command).
So as background (in case it is related), the simplest boot is if the bootloader sees the kernel on a partition which has a filesystem type the bootloader understands. Then the kernel loads, and as the kernel loads, so do the modules at “/lib/modules/$(uname -r)/kernel”.
Now consider that one filesystem type all bootloaders understand is an initial ramdisk. This is just a simple filesystem tree without permissions or special function. This is essentially a filesystem with no filesystem. One can put the kernel in “/boot” of ext4, and put the bare necessity modules in the initial ramdisk, and mount that initrd. The result is that the kernel still looks for modules at “/lib/modules/$(uname -r)/kernel/”, but this is not ext4…it is a generic tree of files in RAM. Almost the same thing.
Now let’s say that you are using a filesystem type which the bootloader does not understand, e.g., XFS. You could use a custom kernel with XFS built in to it (integrated, not a module format). Then your system will take considerable updates or modifications to find the new kernel in many cases. After an update it might break. Or you could just put the XFS in a module. Now if the kernel Image is in “/boot” on ext4, then this part is easy for the bootloader to deal with. But what about the modules? If the initrd creation tools worked right, then the XFS module is added to the initrd in the correct “/lib/modules/$(uname -r)/kernel/” tree, and that tree is mounted on “/” (the kernel itself with an ext4 partition is mounted on “/boot” after the initrd is mounted on “/”).
Suddenly, the generic kernel an understand XFS in that case. You don’t have the XFS module on XFS being used to read XFS; you have the XFS module on initrd. So it works. The initrd is a kind of “adapter” between things needed to boot on a system which cannot “self read” due to some paradox.
However, this is not the end because we cannot put an entire system in RAM. The only program the kernel runs is init (which is systemd on recent systems; used to be a bash script). The minimal init in the initrd loads modules, and performs a pivot_root (or something similar), and two things happen simultaneously: (A) The initrd goes away, and (B) the actual filesystem on disk assumes the initird’s place. So the actual filesystem could then be XFS even though the boot software does not understand XFS, and the kernel itself is unmodified. The modules have allowed the adaptation.
What I suspect if there is an issue as you have shown is that the most probably point of failure is in the creation of the initrd (via the update-initramfs not understanding what must go into the initrd). Now maybe if nothing had gone wrong it would have booted, but what I see is a failure of fsck. Perhaps the initrd needed something for fsck to work, and something is in need of filesystem repair, so it would make sense that it would fail to boot. If fsck cannot succeed on a system with a failure in the filesystem, then there is a refusal to continue to boot since that would likely result in complete loss of the filesystem.
I don’t know what is in the update-initramfs. I do wonder though about this name:
5.10.104-terga-another
That would imply CONFIG_LOCALVERSION is “-tegra-another” (I assume “-terga” is a typographic error). In reality it should just be “-another” if it was set up correctly. If the kernel wants files in “/lib/modules/5.10.104-tegra/kernel/”, or in “/lib/modules/5.10.104-another/kernel/”, but something has mistaken a location as “/lib/modules/5.10.104-tegra-another/kernel/”, the modules used in boot (and for fsck since the kernel is providing the system calls which fsck uses) will not be found.
I can’t answer what is missing. I just highly suspect it is an issue with what the update-initramfs creation parameters.
Hi, I managed solve the issue of display not show with DP port not work when flash orin agx use custom build kernel - #9 by mmcly .
My next issue is will there be any potential issue with the W: Couldn't identify type of root file system for fsck hook error?
Also, I am planning to cross-compile the custom kernel on a more powerful machine and move it to an existing Jetson machine. I am currently seeing that cross-compile can only be done if I am doing a full flash. Is there anyway for me to cross-compile and just install the custom kernel on the Jetson device? @DaveYYY @linuxdev
Kernel image is by default read from the rootfs as specified in /boot/extlinux/extlinux.conf, so you should be able to do that by just replacing the image.
Just a note on why one might flash for kernel update: On an eMMC model it is possible to read a kernel from both a signed partition and from the file named in extlinux.conf. The file takes precedence most of the time. If the file is missing, or not specified, the partition would be used instead. eMMC models have a security fuse which can be burned, in which case only the signed partition can be read, and any separate file is ignored. SD card dev kit models don’t have a security fuse.
1 Like
Hi, I attempted to replace the Image already, but it does not boot up upon selection of kernel.
I cross-compiled using ./nvbuild.sh -o $PWD/kernel_out, and copy the Image over, copy the primary kernel entry, and enter the path of the new Image. on /boot/extlinux/extlinux.conf
What does that mean?
You mean the kernel does not take effect or the device fails to boot up?
Device fails to boot up.
Any serial console log to show?