Re: mkimg used to create gpt image, problem booting

Craig Rodrigues wrote this message on Sun, Aug 24, 2014 at 15:37 -0700:
> 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.

Though, w/ people dd'ing images onto disks, and using growfs to grow
as necessary, we might want to allocate a few more more than the
minimum...  I do agree that we want to keep sizes to a minimum...

> 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.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."