Being too big is not a huge problem in terms of accessing partitions… but the GPT will still be technically invalid because the duplicate partition table at then end of the disk won’t actually be at the end of the disk.
We’ve long assumed that the reason for the problems you observe is because your partition table is corrupt (taking as evidence that the initramfs can’t access them by name). However we’ve never really know how it is corrupt since the study you did with buildroot revealed no problems. However we can also guess from your July logs that when you workaround the first problem a second problem emerges, namely a systemd component that parses the GPT starts crashing. Thus the theory continues that somehow your partition table isn’t right.
So I can’t, in all honesty, be sure if you need to change your partition table because we never really understood why it didn’t work for you in the first place.
I wonder if going back to work in buildroot might be useful. In particular experimenting with sfdisk to create a new partition table.
Basically if you run the following then what you get is an script that sfdisk can read to restore the partition table:
sfdisk --dump /dev/mmcblk0 > parts
The partition table is restored using the following:
sfdisk /dev/mmcblk0 < parts
I would recommend removing the
last-lba: stanzas from
parts before restoring although I confess this is absolute paranoia on my side. When it is restored then the partitions themselves will be the same as before but the partition table will be rebuilt from scratch. Nothing “weird” should survive this.