mkimg used to create gpt image, problem booting

Craig Rodrigues rodrigc at
Sun Aug 24 17:08:52 UTC 2014

On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar <marcel at> wrote:
> On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov <bu7cher at> wrote:
>> On 24.08.2014 06:14, Craig Rodrigues wrote:
>>> I did some further debugging inside the loader by doing the following.
>>>  -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/
>>>  -> I added DEBUG() statements all over sys/boot/common/part.c
>>> I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
>>> that in this section:
>>>    305         ent = (struct gpt_ent *)tbl;
>>>    306         size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
>>>    307             MAXTBLSZ * table->sectorsize);
>>>    308         for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) {
>>>    309                 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL))
>>>    310                         continue;
>>> ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails
>>> out of the loop and never adds the gpt partitions to the list of partitions
>>> that the loader can access.
>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
> Actually, no. There is *a* problem in that function:
> The function does not respect hdr.hdr_entsz when it
> needs the next entry. It simply uses "ent++", which
> is fixed our definition of struct gpt_ent and may
> not match the definition of the writer.

Yes, you are correct.  I looked at the GPT format here:

Although the default size in the specification for a gpt entry is 128 bytes,
which matches the size of our "struct gpt_entry",
technically, the gpt header could specify a gpt entry size that is something
other than 128 bytes.  I guess the only restriction seems to be that
you cannot have variable sized gpt entries.....they have to match the
size of the gpt entry specified in the gpt header.

I guess we haven't hit this yet because there are probably very few
peopel creating gpt tables with entry sizes other than 128, but in the
future, who knows?


More information about the freebsd-current mailing list