Date: Sun, 24 Aug 2014 10:08:49 -0700 From: Craig Rodrigues <rodrigc@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <CAG=rPVe0e_WV8uH5S-2aWFcFOT-xNCN0aT82m-cS0DbsLLwtaw@mail.gmail.com> In-Reply-To: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> References: <CAG=rPVeucq%2BsMxe_NPe3Og939o=Sg4WGfYL7PjA1uXGU8uL=8g@mail.gmail.com> <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <CAG=rPVes3Eq87hOE6W135yGvzRiAzHTbCGSxiyd0JBAs2ufqmA@mail.gmail.com> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <CAG=rPVfe6pP08WWaYQ6enk7A6AkT3dBXVxNfK0JgJPaN_rJ_Uw@mail.gmail.com> <CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q@mail.gmail.com> <53F9AC50.1000000@yandex.ru> <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar <marcel@xcllnt.net> wrote:
>
> On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov <bu7cher@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?
--
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG=rPVe0e_WV8uH5S-2aWFcFOT-xNCN0aT82m-cS0DbsLLwtaw>