Cboot in 32.7.2 fails to read extlinux.conf

I mean we need the log for this status.

But turns out you come back and tell us the rel-32.7.2 extlinux.conf issue. That was different case.

The original problem that we had 209345 was that we could not turn the SPI on using JetsonIO. That was a bug. After some considerable time looking at this we discovered that it was because the boot procedure was not properly checking all the available boot options in the boot-order and was giving up at nvme when one was present. Having remedied (ie not fixed) that by changing the boot order, the next machine we tried to set up we could no longer boot with our custom dtb that was turning SPI on and after some more considerable time we discovered that it was because extlinux.conf was not not being read and thus found this thread.

So I am inclined to agree with user100090 that these are all related and part of the same issue. Recompiling cboot is clearly raising more bugs and I am not inclined to try it and will rather stick with 32.7.1 and change to boot-order.

So when will the combined boot-order + extlinux.conf bugs be fixed?

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 ...


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:

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.


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:

  1. use the patched cboot from above
  1. update cbo.dts to remove nvme from the boot-order list.
  2. flash 32.7.2
  3. system boots properly, and now update /boot/extlinux/extlinux.conf to use the default
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.

I met the same bug.
flashed jetpack32.7.2 into Xarvier NX 16GB core board .

hi ,if you have the good cboot bin,provide one for me.thanks.

According to this, the problem was successfully solved.

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 \
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.