> Seems to only be consistent now with the definition of GENHD_FL_NO_PART. Your real issue is
> commit f5b4d71f72c5 ("mmc: card: Prevent partition scan for the eMMC boot areas")
The commit you mention stopped the partition /dev/mmcblk2boot0p1 from being visible at boot. At this time, the disk flag was GENHD_FL_NO_PART_SCAN.
But we where able to make it appear after this commit by using the partx utility:
* partx -a /dev/mmcblk2boot0
After the patch a33df75c6328 / "
block: don't add or resize partition on the disk with GENHD_FL_NO_PART" was released (and then moved in patch 1a721de8489f / "block: Move checking GENHD_FL_NO_PART to bdev_add_partition()" ), the partx command described above fails.
I can provide the strace output of the partx command for kernel 5.10 and 6.6 if you want to have a look at it.
> It was just deemed unlikely to be useful since most systems use eMMC boot partition
> feature very early in the boot process to read blobs essentially.
> What does yours do?
Our system uses this partition to store 2 things:
* A file containing the block disk to use to boot. Indeed, the eMMC contains 2 partitions containing the operating system.
When performing an OS update, the new OS is copied to the unused partition. At the end of this phase, the file contained
inside /dev/mmcblk2boot0p1 is modified to point to the other partition.
* The logo displayed as a splash-screen during u-boot
Having these data in a separate block disk and partition is a way to protect them from a reliability point of view.
Using a file system is a way to simplify the editing and replacement of these files compared to a situation where this data was stored in a raw format, without a file system.
> If you know the offset the partition is at you can pass that to mount.
Using the offset of the partition we were able to mount the partition with kernel 6.6. Thanks for your help. I appreciate it !
