fix: add compatibility flag to unalign first LBA

[davejbax]

Relates to siderolabs/talos#13209

When the starting LBA of the partition entries table isn't 32 blocks before the first usable LBA, Windows tries to relocate the partition entry array to 32 blocks before the first usable LBA. However, it seems to fail to relocate this entirely, instead only changing the starting LBA of partition entries in the GPT header while leaving the actual partition entries in their original location.

Some systems are resilient to this and look explicitly at LBA 2 for the partition entries. However, some are not: in particular, the Raspberry Pi 4 with the latest EEPROM image fails to boot in this case.

This commit adds a flag which will skip the aligning of the first usable LBA to a megabyte boundary. In this case, Windows doesn't seem to try an relocate the partition entries.

[smira]

I'm not sure I get the explanation here. The first usable LBA is the start of the first partition, the GPT header and partition entries location is fixed anyways.

[davejbax]

Thanks for taking a look at this!

I'm not sure I get the explanation here. The first usable LBA is the start of the first partition, the GPT header and partition entries location is fixed anyways.

So, as I understand it, right now this library is generating a first usable LBA of 2048 and a partition entries start of 2, which is perfectly fine and correct. And, as you say the GPT have and entries are fixed in location anyway.

But Windows seemingly is seeing that 2 != 2048-32 and 'helpfully' overwrites the starting LBA for partition entries on the physical disk itself to 2016. Hence, this PR sets the first usable LBA to 34 effectively, because 34 = 32+2.

I've included a lot more detail in the linked issue which might explain things further

[smira]

Ok, fine, but this setting would create misaligned partitions (for optimal I/O), and it would have to be propagated all the way through the chain of image building pipeline to make it useable.

I have no problem with this PR as it is, but I wonder is it worth the trouble to keep it vs. reporting the issue to Microsoft?

[davejbax]

I can (and will) report the issue to Microsoft, but I'm somewhat less optimistic about the chance of it being fixed there, particularly as this is quite an obscure bug.

Regarding partition alignment, I think it's still possible to align partitions on a 1MB boundary - I'd need to read the code in more depth, but I think go-blockdevice already does some alignment regardless of what the first usable LBA is? That is, the first partition doesn't necessarily have to use the first usable LBA.

It may also be worth noting that there does seem to be prior art here. For instance, I believe sgdisk sets the first usable LBA to 34 (but aligns the partitions on an actual boundary). See also this commit which was created to fix this same issue elsewhere: home-assistant/operating-system@d51a0d3

[smira]

If this changes just first usable LBA, I'm more fine with that (but it should pass the tests), but in that case we should change the default behavior.