mkimg used to create gpt image, problem booting
Andrey V. Elsukov
bu7cher at yandex.ru
Mon Aug 25 07:01:29 UTC 2014
On 24.08.2014 19:23, Marcel Moolenaar 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 right. I'll fix this. Thanks.
> I don't see how the loader is responsible for *the*
> problem. All I see in qemu is that the loader, when
> it reads a sector, isn't getting the actual sector
> data that's in the image.
>
> Just do a ktrace on qemu and you'll see what I mean.
> YMMV of course,
Also there is bootparttest utility in the tools/tools/bootparttest. I
think it can be useful for debugging.
--
WBR, Andrey V. Elsukov
More information about the freebsd-current
mailing list