Re: mkimg used to create gpt image, problem booting

On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov <bu7cher_at_yandex.ru> wrote:
>
> Yes, the problem is in the ptable_gptread() function. I'll commit the fix.

Index: head/sys/boot/common/part.c
===================================================================
--- head/sys/boot/common/part.c (revision 270444)
+++ head/sys/boot/common/part.c (revision 270445)
_at__at_ -254,8 +254,8 _at__at_
            table->sectorsize);
        if (phdr != NULL) {
                /* Read the primary GPT table. */
-               size = MIN(MAXTBLSZ,
-                   phdr->hdr_entries * phdr->hdr_entsz / table->sectorsize);
+               size = MIN(MAXTBLSZ, (phdr->hdr_entries * phdr->hdr_entsz +
+                   table->sectorsize - 1) / table->sectorsize);
                if (dread(dev, tbl, size, phdr->hdr_lba_table) == 0 &&
                    gpt_checktbl(phdr, tbl, size * table->sectorsize,
                    table->sectors - 1) == 0) {

I can confirm that r270445 fixes the problem for me, where I can
now QEMU boot a GPT partitioned image created with mkimg.

I put some more debugging in the code, and found this:


(1)  GPT IMAGE CREATED WITH MKIMG
===============================

phdr->hdr_entries = 2, phdr->hdr_entsz = 128, table->sectorsize = 512

(2)  GPT IMAGE CREATED WITH BSDINSTALL
===================================

phdr->hdr_entries = 128, phdr->hdr_entsz = 128, table->sectorsize = 512


Does gpart  create a fixed partition table with 128 entries?
That would explain a lot.

Also, in the gptboot man page, it mentions that gptboot can only boot
on systems with 128 partitions or less.  This seems like an artificial
restriction.
Does the gptboot code really enforce this?  Not that I have a system with more
than 128 partitions. :)

Should mkimg be changed to create a partition table with 128 entries
by default, to match older versions of FreeBSD which do not have this fix?

Thanks for the fix!

--
Craig