Re: mkimg used to create gpt image, problem booting

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?

Thanks.

--
Craig