Hello.
I asked a question in the link below and opened a new topic.
I added CONFIG_PRINTK_INDEX=y in the kernel/kernel-jammy-src/arch/arm64/configs/defconfig file and built the kernel. After building the kernel, I copied the generated Image file to the /boot directory on my Jetson Orin NX, which is running Jetson Linux 36.3. However, after rebooting, the system failed to boot and displayed the following error.
mount: /mnt/: can’t find PARTUUID=3e305796-4d5f-44f5-9c8c-283822a1659b.
/mnt/ is not a mountpoint
[ T1] ERROR: PARTUUID=3e305796-4d5f-44f5-9c8c-283822a1659b mount fail…
[ T1] ttyTCU0: Press [ENTER] to start bash in 30 seconds …
Just in case, I’ve also attached a screenshot for reference.
Could you please assist me in resolving this issue?
I have another question. If the size of the Image file changes after modifying and building the kernel, can the new Image file still be applied successfully?
I would appreciate a prompt response. Thank you for your attention to this matter.
After you upate the kernel, you didn’t update the rest of kernel moduels (.ko)
nvme and pcie drivers are ko files and they are still the default one. Default one is not compatible with your new kernel image. Probably hits something like invalid symbol layout error.
You need to rebuild and replace the kernel modules in rootfs/lib/modules too and also possible to update kernel modules in initrd too.
When are the nvme and pcie driver .ko files installed, and where are they located?
Also, when the kernel is modified, does the initrd also get updated?
In my case, I am building the kernel on the host PC (Linux) and copying it to the Jetson.
When performing an update, should I execute the provided documentation on the Jetson?
I apologize for having many questions as I am still a beginner. I would appreciate your response. Thank you.
I will add some trivia regarding kernels and modules and initrd. I did not follow any original post, but it seems like this applies. Here are some URLs you might find regarding kernel configuration and installation (not using flash); beware that some are from older 4.x kernels, but the concepts and commands are the same:
Regarding the initrd, you can think of this as an “adapter” between boot stages and handing over control to the Linux kernel. If the bootloader understands the filesystem type being mounted, and if the “integrated” kernel Image file (or one of the modules which the kernel has access to) understands the filesystem being mounted, then one does not necessarily need an initrd. Restated, if both kernel and bootloader understand everything needed to pass to the kernel and for the kernel to run, then it is a trivial hand-off. That’s somewhat simplified, because it implies also that the hardware drivers are present. For example, if the device is a USB external device, and either the bootloader or the Linux kernel do not have the correct USB driver, then this too would require an initrd. Anything needed for the kernel to take ownership of execution, but missing, can be added into the initrd. For the case of kernel features, those would be in the form of modules.
Sometimes an initrd is used even if technically it is not needed. This might lead to a simplified installation. If that initrd has a module which needs to load into the kernel, and if you’ve changed the kernel Image such that this module cannot load, then the boot will fail. The URLs above show a lot of ways modules might fail to load.
The l4t_update_initrd.sh script is just a wrapper to create an initrd. There are multiple ways to view and edit an initrd. The real trick is that the correct modules for that Image file currently being used must be compatible, and they must be in the correct location of the initrd.
Note that an initrd is just a filesystem type. It is very simplified compared to ext4. The initrd filesystem is just a tree structure of files with simplified permissions, and it lives entirely in RAM. The initrd contains a full operating system, other than the Image (which is outside of the initrd), but is cut down to be as tiny as possible. Once the kernel loads the modules it needs to continue boot, a pivot root operation occurs. What this does is to transplant the “/” directory of the RAM disk to instead point at the true storage device (such as eMMC or NVMe). The RAM disk is discarded. Because the kernel Image itself is not on the initrd, and only modules are on this, there is a continuity of service where the Image itself does not change. However, now that one is on a new root filesystem, the kernel can continue loading modules and operating from the full filesystem.
