Not able to find `var-lib-tee.mount` in rootfs and `/dev/disk/by-partlabel/persist` on device

[harshaldev27]

After merger of PR: #1484 I tried to build qcom-multimedia-image using the following build commands for rb3gen2:

git clone https://github.com/qualcomm-linux/meta-qcom.git
git clone https://github.com/qualcomm-linux/meta-qcom-distro
kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml

But after flashing the image on device, I do not find var-lib-tee.mount in /lib/systemd/system/. Perhaps this is because the recipe recipes-bsp/partition/mount-tee-partition_1.0.bb is not yet installed in qcom-multimedia-image?

Also, I do not find the persist partition under /dev/disk/by-partlabel/. Has some change in meta-qcom broken the partition visibility?

[ricardosalveti]

Perhaps this is because the recipe recipes-bsp/partition/mount-tee-partition_1.0.bb is not yet installed in qcom-multimedia-image?

It needs to be included in the image.

[harshaldev27]

Perhaps this is because the recipe recipes-bsp/partition/mount-tee-partition_1.0.bb is not yet installed in qcom-multimedia-image?

It needs to be included in the image.

I don't mind raising a PR to fix this, can you tell me which particular packagegroup should I add this recipe to ensure it is part of qcom-console-image? Or perhaps I believe it should be part of the qcom-minimal-image? Since all images should mount this partition.

[lumag]

@harshaldev27 make the packages which depend on the presence of the persist location depend on the package, providing the systems unit .

[harshaldev27]

Got it, I will make minkicp-qteesupplicant RDEPENDS on mount-tee-partition. I will add mount-tee-partition to qcom-minimal-image.

[harshaldev27]

But before I can do that, I need to be able to see the persist partition under /dev/disk/by-partlabel/, so I can validate that everything's working fine. I do not see that right now on meta-qcom-distro tip. Need someone to check this please.

[lumag]

I will add mount-tee-partition to qcom-minimal-image.

Don't.

[lumag]

But before I can do that, I need to be able to see the persist partition under /dev/disk/by-partlabel/, so I can validate that everything's working fine. I do not see that right now on meta-qcom-distro tip. Need someone to check this please.

Check that qcom-ptool lists persist partition for the platform. Check that meta-qcom uses corresponding revision of the qcom-ptool. Submit necessary patches.

[harshaldev27]

Updated this commit to add mount-tee-partition as RDEPENDS for minkipc-qteesupplicant. So that resolves for the first issue. #1539

[harshaldev27]

I am also notice that there is no entry in fstab to initialize /dev/disk/by-partlabel/persist as an ext4 file system. I am thinking of adding a .bbappend recipe that adds this entry to fstab, let me know if this approach is fine:

/dev/disk/by-partlabel/persist   /var/lib/tee   ext4   defaults,x-systemd.makefs   0  2

[lumag]

There should be no need for the fstab entry if you have the unit file.

[harshaldev27]

But I can see that on older builds where /dev/disk/by-partlabel/persist is visible, the var-lib-tee.mount unit file fails to mount it with the following error unless I manually initialize the raw persist partition as an ext4 file system:

Jan 01 00:12:38 rb3gen2-core-kit systemd[1]: var-lib-tee.mount: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The unit var-lib-tee.mount has entered the 'failed' state with result 'exit-code'.
Jan 01 00:12:38 rb3gen2-core-kit kernel: EXT4-fs (sda2): VFS: Can't find ext4 filesystem
Jan 01 00:12:38 rb3gen2-core-kit systemd[1]: Failed to mount Mount persist partition at /var/lib/tee.

[lumag]

But I can see that on older builds where /dev/disk/by-partlabel/persist is visible, the var-lib-tee.mount unit file fails to mount it with the following error unless I manually initialize the raw persist partition as an ext4 file system:

The entry in fstab can't help with this issue. I'm not sure what is the expected way to initialize the partition.

[harshaldev27]

@vkraleti can you comment on the ext4 filesystem initialization part? Is there supposed to be an explicit init using some mechanism or has something else gone wrong?

[ricardosalveti]

We should investigate if this can be done via systemd-repart (but it needs to create only the fs, not the actual partition), or we will require a custom service job that checks if the file system is valid and creates a new one if not (I believe this is how it was done in qli 1.x).