Can someone at least show us what is the exact error you got when you change the boot order and with the extlinux.conf patch?
My purpose here is only “if your nvme is not a boot disk, then please move it out from the boot order”
My point is that if the boot-order was worked through without giving up at the first device found, there wouldn’t be a problem. Even if there was an option to edit the boot order as part of the Jetpack installer then that wouldn’t be a problem. Ok it is quite easy to edit the boot order once you know what to do, but starting from a position of not even knowing what a dtb was then that involved quite a bit of reading. My interpretation of this thread is that user100090 has successfully recompiled cboot after editing one of the makefiles and I presume that their system is now booting correctly. If you are interested in another log from when it does not read extlinux.conf correctly without recompiling cboot but after changing the boot order then see below:
[0002.449] I> boot-dev-order :-
[0002.452] I> 1.emmc
[0002.454] I> 2.sd
[0002.456] I> 3.usb
[0002.458] I> 4.nvme
[0002.460] I> 5.net
[0002.461] I> Hit any key to stop autoboot: 4 3 2 1
[0004.469] initializing target
[0004.469] calling apps_init()
[0004.470] starting app kernel_boot_app
[0004.489] I> found decompressor handler: lz4-legacy
[0004.490] I> decompressing BMP blob ...
[0004.501] I> Kernel type = Normal
[0004.501] I> ########## Fixed storage boot ##########
[0004.501] I> Loading kernel-bootctrl from partition
[0004.502] I> Loading partition kernel-bootctrl at 0xa42d0000 from device(0x1)
[0004.508] W> tegrabl_get_kernel_bootctrl: magic number(0x00000000) is invalid
[0004.509] W> tegrabl_get_kernel_bootctrl: use default dummy boot control data
[0004.516] I> Already published: 00010003
[0004.516] I> Look for boot partition
[0004.517] I> Fallback: assuming 0th partition is boot partition
[0004.523] I> Detect filesystem
[0004.550] I> Loading extlinux.conf ...
[0004.550] I> Loading extlinux.conf binary from rootfs ...
[0004.550] I> rootfs path: /sdmmc_user/boot/extlinux/extlinux.conf
[0004.611] I> ext4_read_data_from_extent:298: Total file read should not be larger than file stat size
[0004.612] E> file /sdmmc_user/boot/extlinux/extlinux.conf read failed!!
[0004.612] W> Failed to load extlinux.conf binary from rootfs (err=202113305)
[0004.613] E> Failed to find/load /boot/extlinux/extlinux.conf
[0004.614] I> Loading kernel ...
[0004.617] I> No kernel binary path
[0004.620] I> Continue to load from partition ...
Hi,
The error you posted is just the patch we shared out. If you don’t want to compile the cboot, then you can only wait for the next release.
My point here was user100090 seems telling us he still has a bug on his side with the boot-order issue. So I would like to know what is that.
I have replied in the original thread in this post. Maybe it is not clear. Let me re-state here. The boot-order issue is not really a boot-order issue, but when boot-order was changed and the extlinux.conf on the emmc is finally being read, a different problem in extlinux.conf caused the boot failed. At the time I didn’t have the uart console access so thought the boot-order change caused the boot failed. But in reality, the boot-order change revealed a different compatibility issue in extlinux.conf
The extlinux.conf had the default entry:
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet
# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
# sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot
# LABEL backup
# MENU LABEL backup kernel
# LINUX /boot/Image.backup
# INITRD /boot/initrd
# APPEND ${cbootargs}
It worked fine in JP 4.3, but now it failed the boot, because ${cbootargs} in the APPEND line no longer includes root=/dev/... so I have to explicitly specify the root device. After I change APPEND ${cbootargs} quiet to APPEND ${cbootargs} quiet root=/dev/mmcblk0p1. It started to boot.
Hi,
Do you still need to do that after you enable our extlinux patch in cboot?
Could you tell me if there is any error on your side if you don’t do any other change except the extlinux cboot patch we provided?
I don’t think it is normal that you need to append the root=xxxx to your extlinux.conf manually.
If there is any problem, could you share me the log?
See attached boot log, and the system get into recovery shell.
boot-fail.txt (28.2 KB)
Here is how to reproduce:
- use the patched cboot from above
- update cbo.dts to remove nvme from the boot-order list.
- flash 32.7.2
- system boots properly, and now update /boot/extlinux/extlinux.conf to use the default
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet
reboot and the system will drop in the failed shell, see attached uart log.
What is your method to flash 32.7.2? Could you share your command?
Also, could you remove “quite” from your extlinux.conf and dump log again?
Flash command used:
sudo ./flash.sh jetson-xavier mmcblk0p1
There is nothing special.
Were you able to follow my steps to reproduce?
For your second question, I added below to /boot/extlinux/extlinux.conf
LABEL test-no-root
MENU LABEL test-no-root
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs}
So “quiet” is removed. During boot, I selected this entry, and system again boots into recovery bash prompt.
See attach
flash-boot-no-root.txt (78.5 KB)
I will try to totally align the boot flow as yours and see if I can reproduce. But this may take time.
Are you able to try the case that if you don’t change the dtbo, and only remove the nvme from the m.2 slot?
This was the case that we validated the extlinux patch. And during that time, there is no error.
No I didn’t try physically removing the nvme drive.
1 Like
hi ,if you have the good cboot bin,provide one for me.thanks.
According to this, the problem was successfully solved.
thanks.
打了这个补丁之后，编译成功cboot，并替换，烧写。成功解决了这个bug。
the cboot_t194.bin is here.
cboot_t194.bin (456.8 KB)
1 Like
Hi @user100090 ,
I tried to follow the setup from your steps. But my root=root=/dev/mmcblk0p1 is still in the kernel cmdline and extlinux.conf. It does not disappear.
Which means I cannot reproduce your issue.
Please help clarify what is the exact method to reproduce on your side if you keep hitting this issue. Looks like the issue is somehow the parameters are not able to append to extlinux.conf but how to trigger that is unknown.
It seems the previous 32.7.1 packages are still in repo so you can run this to revert back to 32.7.1 to avoid this bug.
sudo apt install \
nvidia-l4t-3d-core=32.7.1-20220219090344 \
nvidia-l4t-apt-source=32.7.1-20220219090344 \
nvidia-l4t-bootloader=32.7.1-20220219090344 \
nvidia-l4t-camera=32.7.1-20220219090344 \
nvidia-l4t-configs=32.7.1-20220219090344 \
nvidia-l4t-core=32.7.1-20220219090344 \
nvidia-l4t-cuda=32.7.1-20220219090344 \
nvidia-l4t-firmware=32.7.1-20220219090344 \
nvidia-l4t-gputools=32.7.1-20220219090344 \
nvidia-l4t-graphics-demos=32.7.1-20220219090344 \
nvidia-l4t-gstreamer=32.7.1-20220219090344 \
nvidia-l4t-init=32.7.1-20220219090344 \
nvidia-l4t-initrd=32.7.1-20220219090344 \
nvidia-l4t-jetson-io=32.7.1-20220219090344 \
nvidia-l4t-jetson-multimedia-api=32.7.1-20220219090344 \
nvidia-l4t-kernel=4.9.253-tegra-32.7.1-20220219090344 \
nvidia-l4t-kernel-dtbs=4.9.253-tegra-32.7.1-20220219090344 \
nvidia-l4t-kernel-headers=4.9.253-tegra-32.7.1-20220219090344 \
nvidia-l4t-libvulkan=32.7.1-20220219090344 \
nvidia-l4t-multimedia=32.7.1-20220219090344 \
nvidia-l4t-multimedia-utils=32.7.1-20220219090344 \
nvidia-l4t-oem-config=32.7.1-20220219090344 \
nvidia-l4t-tools=32.7.1-20220219090344 \
nvidia-l4t-wayland=32.7.1-20220219090344 \
nvidia-l4t-weston=32.7.1-20220219090344 \
nvidia-l4t-x11=32.7.1-20220219090344 \
nvidia-l4t-xusb-firmware=32.7.1-20220219090344
1 Like
The original bug of this topic is already resolved. @user100090 is talking about separate issue.
Please add a new test entry in your extlinux.conf
LABEL test-no-root
MENU LABEL test-no-root
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs}
then select it during boot, and you will see it.
Some histories: I had to compile new kernel, and update extlinux.conf to add new entry to boot the new kernel.
Now that I know why, I can just add root=/dev/mmcblk0p1 to APPEND, and that solves my boot problem. We can close this ticket.
Ok, so the issue is the new entry does not have full kernel cmdline appended.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.