Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image-hd: enforce no GPT partition before the primary Partition Entry Array #125

Closed
wants to merge 1 commit into from

Conversation

Villemoes
Copy link

A Wandboard (and other iMX platforms) is one of those where the
first stage bootloader is loaded from a hard-coded offset of 1K,
i.e. immediately after the GPT header. So the partition table itself
needs to be moved.

I wanted to get rid of updating the bootloader involving writing to
the raw disk rather than some well-defined partition. Both to reduce
risk of stray writes, and to be able to just use
/dev/disk/by-partlabel/SPL rather than some error-prone "dd
seek=...". Defining a partition at 1K with the GPT moved far out of
the way to 1M actually worked (at least produced an image file that
the linux kernel would happily mount via losetup).

But then I stumbled on the text that says that partitions in the table
must start after the partition table. It wasn't immediately clear if
this was a (historical, as evidently it worked now) limitation of the
genimage implementation or actually mandated. So I looked it up, and
unfortunately, it's the latter:

The GPT Header defines the range of LBAs that are usable by GPT
Partition Entries. This range is defined to be inclusive of First
Usable LBA through Last Usable LBA on the logical device. All data
stored on the volume must be stored between the First Usable LBA
through Last Usable LBA, [...]

The primary GPT Partition Entry Array must be located after the
primary GPT Header and end before the First Usable LBA.

So update the README to state where that requirement comes from, and
enforce it in the implementation. Since it does seem to work on linux,
we might later add an I-know-what-I'm-doing option to allow such a use
case, but the default should be to generate images according to the spec.

Signed-off-by: Rasmus Villemoes rasmus.villemoes@prevas.dk

…on Entry Array

A Wandboard (and other iMX platforms) is one of those where the
first stage bootloader is loaded from a hard-coded offset of 1K,
i.e. immediately after the GPT header. So the partition table itself
needs to be moved.

I wanted to get rid of updating the bootloader involving writing to
the raw disk rather than some well-defined partition. Both to reduce
risk of stray writes, and to be able to just use
/dev/disk/by-partlabel/SPL rather than some error-prone "dd
seek=...". Defining a partition at 1K with the GPT moved far out of
the way to 1M actually worked (at least produced an image file that
the linux kernel would happily mount via losetup).

But then I stumbled on the text that says that partitions in the table
must start after the partition table. It wasn't immediately clear if
this was a (historical, as evidently it worked now) limitation of the
genimage implementation or actually mandated. So I looked it up, and
unfortunately, it's the latter:

  The GPT Header defines the range of LBAs that are usable by GPT
  Partition Entries. This range is defined to be inclusive of First
  Usable LBA through Last Usable LBA on the logical device. All data
  stored on the volume must be stored between the First Usable LBA
  through Last Usable LBA, [...]

  The primary GPT Partition Entry Array must be located after the
  primary GPT Header and end before the First Usable LBA.

So update the README to state where that requirement comes from, and
enforce it in the implementation. Since it does seem to work on linux,
we might later add an I-know-what-I'm-doing option to allow such a use
case, but the default should be to generate images according to the spec.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
@michaelolbrich
Copy link
Member

Closing, see #126.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants