Re: mkimg used to create gpt image, problem booting

On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar <marcel_at_xcllnt.net> wrote:
>
> On Aug 24, 2014, at 9:59 AM, Craig Rodrigues <rodrigc_at_freebsd.org> wrote:
>
>> 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.
>>
>
>> 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?
>
> Maybe. 128 is the suggested default. It's not a hard lower
> limit. Technically speaking, it's perfectly fine to create
> just enough entries to fill a single sector. Then again,
> code makes all kinds of assumptions or has all kinds of
> bugs -- just like the logic in the loader apparently.
>
> By having mkimg create a large table, even if it's knows
> up front that it doesn't have to may prevent broken code
> from tripping over, bit it surely bloats the image for
> no reason.

I see what you are saying.  If you have a new device
and do "gpart create -s GPT", then this value in sys/geom/part/g_part_gpt.c:

     .gps_minent = 128,

causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c
to set the number of partitions to 128, and then it calls g_part_ctl_create()
which creates the partition table with 128 empty entries.

"gpart create" doesn't know how many partitions you want, so it
needs to allocate some space up front for the partition table,
and then you can do "gpart add" to add the partitions later.

With mkimg, you know exactly how many partitions you are creating
, so you don't need to specify 128 as the number of partitions.

Since only gpart was available for creating GPT partitions, the side-effect
of always having 128 partitions hid the bug in the loader.

Hopefully Andrey's fix can be backported to at least stable/9, because
the loader bug seems to have been there since at least 2012.

--
Craig