rootfsAB and test kernel/dtb

Some updates. I have an NVME disk for data only (PCIe). Apparently there are some changes in how bootloader works. In 4.3, it reads /boot/extlinux/extlinux.conf from mmc, but in 4.6, it tries to read from my nvme data disk. Since I don’t have a /boot on my nvme data disk, bootloader doesn’t try to use /boot on mmc and directly boots using kernel/dtb partitions.

Regarding my other questions, I see Linux_for_Tegra/bootloader/flash.xml has below:

        <partition name="UDA" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 0x808 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <align_boundary> 4096 </align_boundary>
            <description> **Required.** Automatically takes all remaining space on the device except space
              occupied by `secondary_gpt`. Allocation attribute must be set to 0x808. This
              partition may be mounted and used to store user data. </description>
        </partition>

Does that mean I can freely mkfs.ext4 on this partition and use it in /etc/fstab for both my rootA/B? I assume future flash.sh will still clear it, but other than that, will nvidia tools/scripts/system ever delete my data on UDA partition?

hello user100090,

please see-also Topic 210011. you should “see” the same data exists in both rootfs-A and rootfs-B if you saves some data to UDA partition, and mounts it automatically.

hello user100090,

we cannot reproduce issue by adding a new entry with a test kernel (LINUX) and test dtb (FDT) with r32.7.1 on Xavier. (this is test with/without enable rootfsAB).
could you please check the path definition, how about having test kernel image under /boot/ instead of /boot/test/..
thanks

You can ONLY reproduce if you have NVME drive (PCIe) that is mounted as data. My /boot directory is on the mmc, but in JP 4.6/4.6.1, bootloader tries to read /boot from NVME. Since my NVME is just data disk and doesn’t have /boot, bootloader fails to find /boot and decides to boot from kernel/dtb partitions. It never bother to try mmcblk0. In JP 4.3, bootloader reads mmcblk0 first and can find /boot.

I see this other user reported the same issue.

hello user100090,

FYI, we’re able to reproduce this.
we’ve arrange resources for investigation.

Thanks for the investigation!
BTW, I tried to modify Linux_for_Tegra/bootloader/cbo.dts and change the line:
boot-order = "sd", "usb", "nvme", "emmc", "net";

to

boot-order = "sd", "usb", "emmc", "nvme", "net";

to swap the order of emmc and nvme. After re-flash the board, it won’t boot up anymore. Reverting the change and reflashing, the board boots again.

I saw the new 32.7.2 just released, and tried it. It is even worse now. The bootloader is neither reading the /boot/extlinux/extlinux.conf from nvme, nor emmc. In the last release, as mentioned above, bootloader at least reads the one from nvme.

Could you check the boot log from UART to check it.

I need to capture and post later, but what I did yesterday was to put a long TIMEOUT in the /boot/extlinux/extlinux.conf on emmc and nvme, I watched the booting fly through without any pause. I also added something in APPEND, but didn’t see it in /proc/cmdline after system boots up.

Here are the lines from uart logs:

[0005.376] I> Look for boot partition
[0005.377] I> Fallback: assuming 0th partition is boot partition
[0005.383] I> Detect filesystem
[0005.410] I> Loading extlinux.conf …
[0005.410] I> Loading extlinux.conf binary from rootfs …
[0005.410] I> rootfs path: /sdmmc_user/boot/extlinux/extlinux.conf
[0005.447] I> ext4_read_data_from_extent:298: Total file read should not be larger than file stat size
[0005.448] E> file /sdmmc_user/boot/extlinux/extlinux.conf read failed!!
[0005.448] W> Failed to load extlinux.conf binary from rootfs (err=202113305)
[0005.449] E> Failed to find/load /boot/extlinux/extlinux.conf
[0005.450] I> Loading kernel …
[0005.453] I> No kernel binary path
[0005.456] I> Continue to load from partition …

Based on this security bulletin, 32.7.2 is a security patch with cboot fixes. It seems the cboot fixes accidentally break the read of extlinux.conf, as shown in my uart logs.

Has anybody else tried 32.7.2 and noticed extlinux.conf is no longer being read, with the same error in the uart log as I mentioned above?

Hi,

If you find some new issue, please open a new topic. I am not sure what is happened here. The first one was on jp4.6.1 and now you have something else in 32.7.2.

The issue has nothing to do with 32.6.1.

Originally the issue was reported for 32.7.1 (JP4.6.1), and was told to be fixed in next release. When the next release (32.7.2) was released, I was just testing the fix and report back the finding. That’s why you see them in the same thread.

There is no fix for anything based on what I saw. At least for this topic, we don’t have any fix.

Better sharing new log again to clarify the issue.

ok, opened a new thread.

There two conversations. Maybe you don’t consider them bugs:

  1. If there is a data nvme disk without OS files or /boot, the emmc will boot but the /boot on the emmc will be ignored. See attached boot.1.txt. Bootloader attempted to find extlinux.conf from nvme but there is none, so it moves on to boot the kernel partitions from emmc. Even though boot order says nvme, emmc, it never moves on to the extlinux on the emmc.
    boot.1.txt (31.6 KB)
  1. I pulled out the nvme drive, now the extlinux.conf on the emmc is being read, but there is an compatibility issue. Now it is mandated to have an APPEND line to define root device or else boot will HALT.

HI @user100090 ,

As our previous comment, we need you to switch the boot order in cbo.

Your log indicates you didn’t successfully update that or you didn’t update it at all, which we don’t know.

The key problem is just this one. There is no other “bug” so we don’t have any fix here.
Please try your cbo update again and share us the log and the steps you are using to update cbo.dtb.

Also, when you see " This topic will close 14 days after the last reply." in the forum, just file a new topic. Otherwise, we actually won’t get informed by any of this kind of topic.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.