mkimg used to create gpt image, problem booting

[Marcel Moolenaar]

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.

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,

-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140824/0cf18e53/attachment.sig>