On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar <mar...@xcllnt.net> wrote:
> On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov <bu7c...@yandex.ru> 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/Makefile.inc
>>>  -> 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?

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to