Can't find PARTUUID when replacing kernel on a custom board

Hello,

I have a custom board from a vendor with JP6 BSP (provided by the vendor).
I am trying to know to recompile the kernel. I have now an error on boot:

Here is the extlinux.conf :

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} pcie_aspm=off root=PARTUUID=918f1337-c589-44f0-9b1d-de9b40932aa0 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0

Here is blkid output:

sudo blkid
/dev/nvme0n1p1: UUID="69a4fc87-0ff3-4afe-8b91-0e5e72eed756" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="APP" PARTUUID="918f1337-c589-44f0-9b1d-de9b40932aa0"
/dev/nvme0n1p9: PARTLABEL="recovery-dtb" PARTUUID="6d7f8a11-5ce4-494e-9aaf-490bd6cb6f16"
/dev/nvme0n1p11: PARTLABEL="recovery_alt" PARTUUID="1bb21bd0-80bb-4bfa-8bd4-a02927b8f42f"
/dev/nvme0n1p7: PARTLABEL="B_reserved_on_user" PARTUUID="042c02d8-04d8-4d7d-912a-8d20fa0b0013"
/dev/nvme0n1p5: PARTLABEL="B_kernel" PARTUUID="085683a3-207b-4834-b146-68024f57196b"
/dev/nvme0n1p3: PARTLABEL="A_kernel-dtb" PARTUUID="7fcda5f9-404e-4aa7-b48e-4d42c8f7e119"
/dev/nvme0n1p14: PARTLABEL="UDA" PARTUUID="0e1863e5-b82b-4c7c-8228-4579bd664412"
/dev/nvme0n1p12: PARTLABEL="recovery-dtb_alt" PARTUUID="72e5a452-2741-4cd2-8d1d-ae29f5273c7b"
/dev/nvme0n1p8: PARTLABEL="recovery" PARTUUID="72dec48d-310b-4e25-aab9-a06ae52ce27e"
/dev/nvme0n1p10: UUID="C080-8AC6" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="esp" PARTUUID="0ff1368a-db82-410a-87f1-ac6983dcbe0f"
/dev/nvme0n1p6: PARTLABEL="B_kernel-dtb" PARTUUID="5bd3a63e-ffa7-4201-a638-2756883a6b28"
/dev/nvme0n1p4: PARTLABEL="A_reserved_on_user" PARTUUID="14429c57-2397-46eb-b552-31636665b979"
/dev/nvme0n1p2: PARTLABEL="A_kernel" PARTUUID="28f041c5-d9a6-46a2-a72c-c165f1253d53"
/dev/nvme0n1p15: PARTLABEL="reserved" PARTUUID="59f9bd03-5314-49d2-b772-44259081d84c"
/dev/nvme0n1p13: PARTLABEL="esp_alt" PARTUUID="750647bc-643e-4c16-857f-5566faedd950"
/dev/zram3: UUID="e6b677d8-6e1f-4615-ba92-5a933b489cfe" TYPE="swap"
/dev/zram1: UUID="5ddf7d69-8962-471d-b378-1fe8fa060872" TYPE="swap"
/dev/loop0: SEC_TYPE="msdos" LABEL_FATBOOT="L4T-README" LABEL="L4T-README" UUID="1234-ABCD" BLOCK_SIZE="512" TYPE="vfat"
/dev/zram2: UUID="1bebcb38-e3be-486e-a521-33e11bac8fa6" TYPE="swap"
/dev/zram0: UUID="e1b2b1fc-c234-4199-9af5-bf8a6afd59ea" TYPE="swap"

It seems that it’s not finding the partition where the rootfs is located.

Any idea why this is happenning ?

Hi younes.khadraoui,

Could your board boot up with the original JP6 BSP from your vendor w/o any modification?

Have you requested the kernel source from your vendor?

This one should be where your rootfs locates.

Hello @KevinFFF ,

Yes the device was able to boot with JP6 BSP from the vendor.

It’s just with my custom compiled kernel that it does not.

In the logs, it says that it was not able to load the nvme-code.ko module, because of mismatch with the version.

However, I compiled the modules alongside the kernel.

Any idea ?

By the way, I did not replace the dtbs. Is there a direct relationship between the dtbs and the module ?

This means that I am using the dtbs provided by the vendor for their provided kernel, while I am using a module that I compiled. Can this be causing the mismatch printed in the logs ?

How did you build the kernel image?
Have you gotten the kernel source from your vendor or you just use the official source from us?

It’s a known bug in the kernel compilation process, and will be fixed in JetPack 6 GA.
rootfs fails to be mounted because NVMe drivers in initrd is still the stock one from the vendor/NVIDIA, and it doesn’t match your current kernel.

You need to unpack Linux_for_Tegra/bootloader/initrd following this method, replace /lib/modules/($uname -r) in the unpacked folder with the one you build, pack it back into initrd, and flash again.
https://docs.nvidia.com/jetson/archives/r36.2/DeveloperGuide/SD/FlashingSupport.html#skipping-oem-config

2 Likes

@DaveYYY

But if I do that, the kernel Image won’t match with the vendor one.
Is there a way to flash with MY custom kernel ?

I don’t know what you are talking about.
You are building your own kernel, then what does it have to do with the kernel from the vendor?

I am saying that you have to update both kernel image and initrd at the same time, so they match each other.

Maybe I was’nt clear enough on the process I follow:

  • Flash the device with JP6 BSPs from vendor
  • Compile kernel + modules
  • replace /boot/Image & /lib/modules/(uname -r) with new compiled ones.

If I understand correctly, even if I replace the modules with the new ones, it keeps using the vendor one. Right ? so just replacing the folder is not enough, and I have to FLASH it again with the new compiled Image + modules. Is that right ?

You need to update all of kernel image + kernel modules + initrd, and whether you are doing it live on the device or re-flashing does not matter.

You have to reboot the device for the new kernel to take effect…

1 Like

Thank you @DaveYYY .

How can I replace initrd live without reflashing ?

You just replace /boot/initrd on your device.

Thanks !

I’m trying and getting back.

@DaveYYY

I did what you suggested. I don’t have the issue I had before, but now the device is unable to start, and hangs forever. Here are the logs:

Any suggestions ? I don’t really understand what’s happening.

Always dump the log. Don’t put screenshots/photoes.

I don’t know what you changed in the kernel config, but if the previous PARTUUID error is gone, then it means something else.
Maybe you mess up with the kernel config.

You should make sure it works with the default setting before making any customization.

What do you mean by mess up ?
I changed kernel config and recompiled as usual.

Is there anything else do on the initrd file except frm adding the modules folder ?

p.s. that’s a vendor device and don’t have access to UART port.

Little we can do without serial console log.

Then please do this first.

1 Like

Thank you @DaveYYY .

The flash worked with the original BSPs.

I will reach out to vendor and let know.

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