root=LABEL not working in bootargs

Technical Support
, , ,
1

Hi,

I am building the reference minimal image for a verdin imx8mp som.
I have been playing with adding the meta-toradex-security layer in yocto.

I know the u-boot hardening is not supported, but I was going to look for a way to support it in my build.
I am able to include the bootargs device-tree-overlay, and include the overlay.

The problem I have is that the default bootargs generated in the boot.scr (which I am already modifying in my layer) use a UUID to identify the rootfs partition.
I have looked at the torizon layer and it seems to be setting root=LABEL=otaroot.
So I thought I might be able to do something similar and use RFS which is the label for the default root partition.
However, this doesn’t seem to work. It just ends in a message about waiting for the partition to be available.

I have been looking through the u-boot code and it appears that PARTLABEL is what is supported, but only for GPT partition tables.
I tried it to be sure, but resulted in the same waiting message.

Is there something you do in the torizon build to make this work properly?
Failing this I may have to just rely on using the device path (/dev/mmcblk2p2 for the imx8mp).

Ideally I would like to use the label if possible as I may need to make my layer support other modules at some point.

Regards,

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

When configuring the boot arguments to use a partition label (e.g., root=LABEL=otaroot) in U-Boot for a Verdin iMX8MP SoM, and you’re encountering issues where the system cannot find the partition by label, there are a few considerations and steps you can take to troubleshoot and potentially resolve the issue.

  1. Ensure the Filesystem Label is Correctly Set: First, verify that the root filesystem’s label is indeed set to what you expect (RFS in your case). You can check and set filesystem labels with tools like e2label for ext2/3/4 filesystems or tune2fs.

  2. U-Boot Version Compatibility: Ensure that the version of U-Boot you are using supports accessing partitions by label. This feature might depend on the specific U-Boot version and configurations. Since you mentioned that PARTLABEL is supported only for GPT, ensure your partition table is GPT and not MBR if you’re trying to use PARTLABEL.

  3. Kernel Support for Root by Label: The Linux kernel also needs to support booting from a label. This usually requires initramfs/initrd that can mount the root filesystem by label before handing control over to the actual root filesystem. Ensure your kernel command line is correctly passed from U-Boot and that the kernel has support for the filesystem label.

  4. Debugging U-Boot: You can add debug prints in your U-Boot environment to ensure that the bootargs are correctly set and passed to the kernel. Use the printenv command in U-Boot to verify the bootargs.

  5. Alternative Approaches: If using the label directly in the bootargs proves to be problematic, consider using an initramfs that can determine the correct root device at boot time and mount it accordingly. This approach is more flexible but adds complexity to your boot process.

  6. U-Boot Environment: Sometimes, the issue might be with how the U-Boot environment is saved or loaded. Ensure that any changes you make to bootargs or other environment variables are properly saved (using the saveenv command) and that there’s no override happening from other scripts or settings.

If after these checks and configurations, using root=LABEL= still does not work, using the explicit device path (e.g., /dev/mmcblk2p2) as a fallback is a reliable approach, though less flexible if you

Please, also check if these links can help you solve your problem:

Torizon OS Reference Minimal Image Technical Overview | Toradex Developer Center.

4

Hi,

Having run various tests on my image, the following does appear to return the correct device:
blkid --label RFS -o device

This tels me that the label is in fact specified and available (unless I am misunderstanding anything here).

However, the boot.scr seems unable to find the device when I specify rootfs=LABLE=RFS in the bootargs.

Regards,
MMG

5

Hi, @izzy_building !

I apologize for the delayed response.

I’ll run some tests and try to reproduce your situation. Once I’ve found something, I’ll let you know.

Best regards.
Lucas Azeituno

6

Greetings @izzycoding,

From what I understand you’re trying to use a filesystem label to define the root partition, correct?

I checked with our team and this action requires support in the ramdisk of the image. In our default Torizon OS image we have a ramdisk naturally. But you said you’re building off our reference image, which does not use a ramdisk. If you modified the build to have a ramdisk, then it might be the case that your ramdisk doesn’t have support for handling the partition label.

Best Regards,
Jeremias