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?
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.
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.
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.
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.
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.
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.
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 two conversations. Maybe you don’t consider them bugs:
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)
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.
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.