Re: mkimg used to create gpt image, problem booting

On 24.08.2014 06:14, Craig Rodrigues wrote:
> Hi,
> 
> I did some more experiments, and found that after /boot/loader runs,
> if I break into the loader prompt and type "lsdev", I would get this:
> 
> (1)  GPT Disk image which boots under QEMU, made by bsdinstall
> ==================================================
> View from loader
> ============
> OK lsdev
> cd devices:
> disk devices:
>       disk0:    BIOS drive A:
>       disk1:    BIOS drive C:
>          disk1p1: FreeBSD boot
>          disk1p2: FreeBSD UFS
>          disk1p3: FreeBSD swap
> pxe devices:
> 
> 
> View from gpart, after we mdconfig the disk image
> ====================================
> =>      34  10485693  md0  GPT  (5.0G)
>         34       128    1  freebsd-boot  (64K)
>        162   9959296    2  freebsd-ufs  (4.7G)
>    9959458    524288    3  freebsd-swap  (256M)
>   10483746      1981       - free -  (991K)
> 
> 
> (2)  GPT Disk image which fails to boot under QEMU, made by mkimg
> ===================================================
> View from loader
> ============
> OK lsdev
> cd devices:
> disk devices:
>       disk0:    BIOS drive A:
>       disk1:    BIOS drive C:
> pxe devices:
> 
> View from gpart, after we mdconfig the disk image
> ====================================
> 
> =>      3  1784944  md1  GPT  (872M)
>         3       32    1  freebsd-boot  (16K)
>        35  1784912    2  freebsd-ufs  (872M)
> 
> 
> 
> This leads me to believe that there is logic in /boot/loader,
> which is not in GEOM, that fails to parse the GPT produced by mkimg.
> 
> 
> 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.
> 
> I'm not familiar with the GPT format, nor am I familiar with the
> gpt code inside the loader, and how it differs from GEOM.
> 
> Do you have any further ideas of where to hunt for the root cause of
> the problem?

Yes, the problem is in the ptable_gptread() function. I'll commit the fix.

-- 
WBR, Andrey V. Elsukov