You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Windows (at least starting with version 10) contain logic that alters the GPT table of a drive connected to it in some cases. More specifically it's been found it relocates the backup GPT table to the end of the drive and the partition array to LBA address equal to first_usable_lba - 32. There is no (easy) way to prevent this behavior in Genimage-created images because first_usable_lba is always set to the start of the first partition. Although this is rather a Windows bug/misfeature, images created using other utilities (like sgdisk) are not affected by this, as they generally set first_usable_lba to LBA 34, so it should be possible to achieve the same with Genimage.
These issues show a real world regression triggered by the fact that Genimage works slightly different compared to other utilities. In theory I can imagine this relocation might also overwrite data located between the GPT header and the first actual partition if this area of the disk contained for example some bootloader data - although this is purely hypothetical.
I'd like to discuss the potential ways to mitigate this issue. Should we add a flag for setting first_usable_lba to the lowest possible value, or an arbitrary one, or even set it always to 34 like sgdisk does? Currently it's correlated to the align value but setting it to a one-sector size and juggling with offset values afterwards feels rather clumsy to me.
The text was updated successfully, but these errors were encountered:
So my understanding was that first_usable_lba is the first LBA that can be used for partitions, and anything before that is off limits. That's why it is implemented as it is right now: There are real use-cases where bootloader data is placed between the partition table and the first partition.
But my understanding is clearly mistaken, or at least windows has a different understanding of what should happen here. So we should probably always do:
That's 2 + 32 = 34 for the default partition table location. If the partition table is moved to make room for a bootloader, then that should still be acceptable based on you're description above.
Windows (at least starting with version 10) contain logic that alters the GPT table of a drive connected to it in some cases. More specifically it's been found it relocates the backup GPT table to the end of the drive and the partition array to LBA address equal to
first_usable_lba - 32
. There is no (easy) way to prevent this behavior in Genimage-created images becausefirst_usable_lba
is always set to the start of the first partition. Although this is rather a Windows bug/misfeature, images created using other utilities (likesgdisk
) are not affected by this, as they generally setfirst_usable_lba
to LBA 34, so it should be possible to achieve the same with Genimage.For details see:
These issues show a real world regression triggered by the fact that Genimage works slightly different compared to other utilities. In theory I can imagine this relocation might also overwrite data located between the GPT header and the first actual partition if this area of the disk contained for example some bootloader data - although this is purely hypothetical.
I'd like to discuss the potential ways to mitigate this issue. Should we add a flag for setting
first_usable_lba
to the lowest possible value, or an arbitrary one, or even set it always to 34 likesgdisk
does? Currently it's correlated to thealign
value but setting it to a one-sector size and juggling with offset values afterwards feels rather clumsy to me.The text was updated successfully, but these errors were encountered: