On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar <marcel_at_xcllnt.net> wrote: > > On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov <bu7cher_at_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: http://en.wikipedia.org/wiki/GUID_Partition_Table 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? -- CraigReceived on Sun Aug 24 2014 - 15:08:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC