write_mbr_and_gpt_partitions() calls part_init() after writing the GPT to re-detect the partition table, but part_init() takes a fast path when desc->part_type is already cached: it only re-validates the existing driver's test() instead of re-scanning all partition drivers.
On SPI-NOR/MTD block devices, part_type is cached as PART_TYPE_MTD from the initial probe, since the MTD partition driver's test() unconditionally matches. When fastboot subsequently writes a GPT to SPI-NOR (e.g. via 'gpt write'), the post-write part_init() call keeps reusing the stale MTD type instead of detecting EFI, so 'part list mtd 0' reports "Partition Type: MTD" with no partitions until an unrelated full reprobe (e.g. 'sf probe') resets part_type and forces a re-scan. Reset part_type to PART_TYPE_UNKNOWN before the post-write part_init() call only when it was cached as PART_TYPE_MTD, so other block devices' cached partition type is left untouched. Signed-off-by: Vandhiadevan Karunamoorthy <[email protected]> --- disk/part_efi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/disk/part_efi.c b/disk/part_efi.c index d8b17ec2e91..e45fdc5f8ca 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -976,6 +976,8 @@ int write_mbr_and_gpt_partitions(struct blk_desc *desc, void *buf) } /* Update the partition table entries*/ + if (desc->part_type == PART_TYPE_MTD) + desc->part_type = PART_TYPE_UNKNOWN; part_init(desc); return 0; -- 2.34.1
