hello,i follow nvidia Jetson Orin nano Developer Guid to flash my device after finish it, i open file named “extLinux.conf” and add a Lable to develop something.When I change extLinux.conf and I try to switch to my own kernel in the boot screen, I get stuck in the boot screen, and when I power off and power back on the default kernel I get an error about a file not being found, and then it reboots automatically, and then I get a black screen.
is there any solution ?thanks!
It is actually “/boot/extlinux/extlinux.conf”. Can you post a copy of extlinux.conf, and a copy of:
ls -d /boot/*
1 Like
The firmware version of my Orin Nano is: 36.4.3
/boot/extlinux/extlinux.conf ：
TIMEOUT 300
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=710c1971-20a7-4931-8e4d-90738ffcbe19 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0
LABEL rvbust
MENU LABEL rvbust kernel
LINUX /boot/rvbust/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=710c1971-20a7-4931-8e4d-90738ffcbe19 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0
Then I placed the Kernel Image of version 36.4.3 that I compiled myself into the /boot/rvbust/Image directory.
here is ls -d /boot/*
root@rvbust-desktop:~# ls -d /boot/rvbust/*
/boot/rvbust/Image
root@rvbust-desktop:~# ls -d /boot/*
/boot/dtb /boot/tegra234-p3737-0000+p3701-0005-nv.dtb /boot/tegra234-p3767-0000+p3509-a02-m2ke.dtbo
/boot/efi /boot/tegra234-p3737-0000+p3701-0008.dtb /boot/tegra234-p3767-0000+p3768-0000-csi.dtbo
/boot/extlinux /boot/tegra234-p3737-0000+p3701-0008-nv.dtb /boot/tegra234-p3767-camera-p3768-imx219-A.dtbo
/boot/Image /boot/tegra234-p3737-camera-dual-hawk-ar0234-e3653-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx219-C.dtbo
/boot/initrd /boot/tegra234-p3737-camera-dual-imx274-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx219-dual.dtbo
/boot/initrd.img /boot/tegra234-p3737-camera-e3331-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx219-imx477.dtbo
/boot/initrd.img-5.15.148-tegra /boot/tegra234-p3737-camera-e3333-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx477-A.dtbo
/boot/kernel_tegra234-p3768-0000+p3767-0003-nv.dtb /boot/tegra234-p3737-camera-eCAM130A-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx477-C.dtbo
/boot/oot-stub /boot/tegra234-p3737-camera-imx185-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx477-dual-4lane.dtbo
/boot/rvbust /boot/tegra234-p3737-camera-imx390-addr-0x21-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx477-dual.dtbo
/boot/tegra234-carveouts.dtbo /boot/tegra234-p3737-camera-imx390-overlay.dtbo /boot/tegra234-p3767-camera-p3768-imx477-imx219.dtbo
/boot/tegra234-p3737-0000+p3701-0000-as-p3701-0004.dtbo /boot/tegra234-p3737-camera-p3762-a00-1Hawk-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0000.dtb
/boot/tegra234-p3737-0000+p3701-0000-as-p3767-0000.dtbo /boot/tegra234-p3737-camera-p3762-a00-2Hawk-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0000-dynamic.dtbo
/boot/tegra234-p3737-0000+p3701-0000-as-p3767-0001.dtbo /boot/tegra234-p3737-camera-p3762-a00-3Hawk-3Owl-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0000-nv.dtb
/boot/tegra234-p3737-0000+p3701-0000-as-p3767-0003.dtbo /boot/tegra234-p3737-camera-p3762-a00-4Hawk-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0000-nv-super.dtb
/boot/tegra234-p3737-0000+p3701-0000-as-p3767-0004.dtbo /boot/tegra234-p3737-camera-p3762-a00-4Owl-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0001.dtb
/boot/tegra234-p3737-0000+p3701-0000-audio-adafruit-sph0645lm4h.dtbo /boot/tegra234-p3737-camera-p3762-a00-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0001-nv.dtb
/boot/tegra234-p3737-0000+p3701-0000-audio-adafruit-uda1334a.dtbo /boot/tegra234-p3740-0002+p3701-0008.dtb /boot/tegra234-p3768-0000+p3767-0001-nv-super.dtb
/boot/tegra234-p3737-0000+p3701-0000-audio-fe-pi.dtbo /boot/tegra234-p3740-0002+p3701-0008-hdr20.dtbo /boot/tegra234-p3768-0000+p3767-0003.dtb
/boot/tegra234-p3737-0000+p3701-0000-audio-respeaker-4-mic-array.dtbo /boot/tegra234-p3740-0002+p3701-0008-m2kb.dtbo /boot/tegra234-p3768-0000+p3767-0003-nv.dtb
/boot/tegra234-p3737-0000+p3701-0000-audio-respeaker-4-mic-lin-array.dtbo /boot/tegra234-p3740-0002+p3701-0008-m2ke.dtbo /boot/tegra234-p3768-0000+p3767-0003-nv-super.dtb
/boot/tegra234-p3737-0000+p3701-0000-csi.dtbo /boot/tegra234-p3740-0002+p3701-0008-nv.dtb /boot/tegra234-p3768-0000+p3767-0004.dtb
/boot/tegra234-p3737-0000+p3701-0000.dtb /boot/tegra234-p3740-camera-p3783-a00-overlay.dtbo /boot/tegra234-p3768-0000+p3767-0004-nv.dtb
/boot/tegra234-p3737-0000+p3701-0000-dynamic.dtbo /boot/tegra234-p3767-0000+p3509-a02-audio-adafruit-sph0645lm4h.dtbo /boot/tegra234-p3768-0000+p3767-0004-nv-super.dtb
/boot/tegra234-p3737-0000+p3701-0000-hdr40.dtbo /boot/tegra234-p3767-0000+p3509-a02-audio-adafruit-uda1334a.dtbo /boot/tegra234-p3768-0000+p3767-0005.dtb
/boot/tegra234-p3737-0000+p3701-0000-m2ke.dtbo /boot/tegra234-p3767-0000+p3509-a02-audio-fe-pi.dtbo /boot/tegra234-p3768-0000+p3767-0005-nv.dtb
/boot/tegra234-p3737-0000+p3701-0000-nv.dtb /boot/tegra234-p3767-0000+p3509-a02-audio-respeaker-4-mic-array.dtbo /boot/tegra234-p3768-0000+p3767-0005-nv-super.dtb
/boot/tegra234-p3737-0000+p3701-0004.dtb /boot/tegra234-p3767-0000+p3509-a02-audio-respeaker-4-mic-lin-array.dtbo /boot/tegra-optee.dtbo
/boot/tegra234-p3737-0000+p3701-0004-nv.dtb /boot/tegra234-p3767-0000+p3509-a02-csi.dtbo
/boot/tegra234-p3737-0000+p3701-0005.dtb /boot/tegra234-p3767-0000+p3509-a02-hdr40.dtbo
When switching the kernel and starting up, my log is like this.
error.txt (25.6 KB)
I’d like to emphasize the error in the last paragraph to you.
[ 14.062701] ERROR: mounting PARTUUID=e712b858-f7a3-403c-9787-3e1239c5daf3 as /mnt fail...
[ 14.064518] ERROR: PARTUUID=e712b858-f7a3-403c-9787-3e1239c5daf3 mount fail...
[ 14.066247] ttyTCU0: Press [ENTER] to start bash in 30 seconds...
[ 17.067039] ttyTCU0: Press [ENTER] to start bash in 27 seconds...
[ 20.067703] ttyTCU0: Press [ENTER] to start bash in 24 seconds...
[ 23.068344] ttyTCU0: Press [ENTER] to start bash in 21 seconds...
hi,I was just building the kernel according to the guide,Modify the code in this step to disable.
./generic_rt_build.sh "enable"
And then switching to a different kernel succeeded. Why is that
I think someone else may need to answer, but I’m going to go through this and see what I notice. This is just in the order I see things as I go through, so it may not end with any conclusion and the order of noticing things is the order of writing it down here.
I’ll say more below, but is this using a custom carrier board? Is the module an eMMC model?
In the serial console log, is this from picking kernel choice “1”? They both have a label of “primary kernel”, which does not match the extlinux.conf:
0: primary kernel
1: primary kernel
Is there any external boot device? If the model is eMMC, then SD card would be external, but if a developer’s kit, which has no eMMC, then SD card is not external. In all cases NVMe or SSD would be external. One reason for asking is that this appears to not be booting the extlinux.conf, and external device booting can end up using a different extlinux.conf than is expected. Burning security fuses can remove the use of “/boot” content and force use of binary partitions.
Your extlinux.conf seems mostly valid, but some suggestions:
- Instead of “
/boot/rvbust/Image” (which should work) I would instead rename theImagefile:
“/boot/Image.rvbust”. - You’re using the same
initrdfor both. There’s a pretty big discussion possible on this, but the shorter answer is that if you’ve rebuilt theImageto some new configuration, and if theCONFIG_LOCALVERSIONor any integrated feature (something “=y”, which non-module) changes, then you need to update the initrd as well with some modules. I don’t know your kernel changes, nor do I know your device tree requirements, so it is hard to say. You can ask more about this since this is possibly the cause (not necessarily though; it depends on the modules required to boot, e.g., a module for networking failing won’t hurt unless you are network booting). The gist is that the initrd is for the original kernel’s modules, so maybe it is module problem. - If you were to adjust the initrd, then I would also use renaming to “
/boot/initrd.rvbust”. This lets you keep them in the default location, although moving them should also work. If moving, then I would still use the renaming.
I do see this in the serial boot log, but someone from NVIDIA may need to look at this:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...
The point about the above snippet of log is that I don’t know what is in LINUX_EFI_INITRD_MEDIA_GUID. I was hoping the log would show the initrd path, but it is only an indirect indication. Someone from NVIDIA might be able to say what the LINUX_EFI_INITRD_MEDIA_GUID variable is and how to see the exact initrd loaded. This might even be from a partition, I don’t know (please mention if this has any security fuses burned, although only applicable with an eMMC model of module).
Is this using a custom carrier board? Or is this a stock developer’s kit? If so, then it needs a custom device tree. Changing the kernel is not likely to require a device tree change, but it can if one of the related drivers are for a non-plug-n-play component of the carrier board. Knowing the exact carrier board information would be useful. We could match the list of the device trees to what is actually being loaded.
The very end of the serial console boot log appears to be because it can’t mount the partition. It is basically trying to drop you into a bash shell. A number of issues named above might be the cause.
Also, the UUID mentioned in the extlinux.conf is this:
710c1971-20a7-4931-8e4d-90738ffcbe19
…but the UUID missing for mount in serial boot log is this:
[ 14.062701] ERROR: mounting PARTUUID=e712b858-f7a3-403c-9787-3e1239c5daf3 as /mnt fail...
[ 14.064518] ERROR: PARTUUID=e712b858-f7a3-403c-9787-3e1239c5daf3 mount fail...
The latter is another reason for wondering if it is really using the partition you think it is using since there is a mismatch to the extlinux.conf.
Hello, my latest discovery is that when building a real-time kernel, it must be configured to “disable” like this: "./generic_rt_build.sh “disable”. Otherwise, the kernel won’t run. Why is this?
I did not know this was the RT kernel. The earlier comments still apply, but this kernel was unable to find a root filesystem to mount. That failure might be unrelated to the fact that this is an RT kernel, but there is a lot which can go wrong when you completely replace the kernel. The configuration must still be set up correctly prior to editing any changes to the kernel, but there will be additional differences for the RT kernel.
I don’t know what the additional differences are, and I’ve not used the generic_rt_build.sh shell script.
Do keep in mind that often the initrd (initial ramdisk) is used as an adapter between the kernel and the first filesystem to be mounted. Combine that with the fact that if you replace the kernel in any way, then the modules would normally also require replacement (the exception being if you configured the new kernel to have exactly the same integrated feature set and only modified modules) and any modules used inside of the initrd are now invalid unless you’ve added the new modules. If no module is related to mounting the filesystem, then this won’t hurt anything. Examples of required modules might be if a disk controller is a module or if the ext4 filesystem support is in the form of a module. I have no way of knowing what your case is, but I now suspect both the configuration and addition of modules (especially in the initrd) are likely part of the reason the filesystem cannot be found.
The original possibilities related to things like needing a correct partition or disk UID still apply. Those are on top of the new issues to consider.
Questions:
- Where did you download the RT kernel, and where did you get the
generic_rt_build.shscript? - Did you create an updated
initrd? - What were the exact configuration steps for configuring the kernel?
- Is there any external boot device used, e.g., NVMe?
- Is this Orin Nano a developer’s kit which does not have eMMC, or is it a third party carrier board and use eMMC?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.