Date: Sun, 24 Aug 2014 16:31:43 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Craig Rodrigues <rodrigc@freebsd.org> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <20140824233143.GQ71691@funkthat.com> In-Reply-To: <CAG=rPVeLgOGXx8=S18u03JuNGB9PzYk3uYZS8r=sgu3b_UHOmQ@mail.gmail.com> References: <CAG=rPVeucq%2BsMxe_NPe3Og939o=Sg4WGfYL7PjA1uXGU8uL=8g@mail.gmail.com> <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <CAG=rPVes3Eq87hOE6W135yGvzRiAzHTbCGSxiyd0JBAs2ufqmA@mail.gmail.com> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <CAG=rPVfe6pP08WWaYQ6enk7A6AkT3dBXVxNfK0JgJPaN_rJ_Uw@mail.gmail.com> <CAG=rPVe8Lh=P2MUdycM7%2B2mpSBPhe%2BkTvxR_bjnZfB1EkvK92Q@mail.gmail.com> <53F9AC50.1000000@yandex.ru> <CAG=rPVctN4-UBxRzWhEoEt5e_4d8UXCa0O40LZUHnS5Qj9hFeA@mail.gmail.com> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <CAG=rPVeLgOGXx8=S18u03JuNGB9PzYk3uYZS8r=sgu3b_UHOmQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@xcllnt.net> wrote:
> >
> > On Aug 24, 2014, at 9:59 AM, Craig Rodrigues <rodrigc@freebsd.org> wrote:
> >
> >> On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov <bu7cher@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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140824233143.GQ71691>