Re: mkimg used to create gpt image, problem booting

On 25.08.2014 03:55, Marcel Moolenaar wrote:
>> 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...
> 
> One thing I can maybe do is simply fill the empty sectors
> that are there because of alignment. If you add -P 4K to
> mkimg, then the first partition will by 4K aligned and you
> have about 5 sectors unused between the end of the GPT
> table and the first sector of the first partition. I may
> as well extend the table to cover those unued sectors.

IMHO, mkimg should behave like gpart and create images in
gpart-compatible way. Some users may want to copy the partition layout
from the image to real hardware and they will not be able to do it.

Also, now FreeBSD 11.0 uses different first usable LBA. By default it is
4k aligned. And this creates some incompatibility with older versions.
You can't do `gpart restore` and get the same table, as you had on older
system.

> However, this is a pretty side-ways way to end up with a
> GPT table that has some extra room. Maybe having scheme-
> specific options for this kind of thing is not bad. At
> least EBR and APM have the same "problem" and the BSD
> disk label can also be created with more than just 8
> partitions.

I thought about implementing `gpart modify` or `gpart set` -n entries to
change number of entries when it is possible (i.e. disklabel(8) can do
it, but gpart doesn't).
Also in r228076 I changed APM code to calculate maximum number of
entries depending from available free space.

-- 
WBR, Andrey V. Elsukov