mkimg used to create gpt image, problem booting

[Marcel Moolenaar]

On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov <bu7cher at yandex.ru> wrote:

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

It already does. There's s difference between behaving
like something else or behaving exactly identical to
that something. The same applies to compatible. It is
not the same as identical.

There is no compatibility issue. mkimg follows the GPT
specification (modulo bugs) and gpart happily groks the
partition table.

> Some users may want to copy the partition layout
> from the image to real hardware and they will not be able to do it.

I'm inclined to say that generally speaking this is not
possible. The GPT has metadata in the first few sectors
*and* the last few sectors and LBAs of these sectors are
part of the metadata. You cannot blindly copy an image
onto a physical medium unless the image and the physical
medium are of exactly the same size. Odds are they are
not.

To reliably transfer or convert an image (e.g. RAW->VHD)
one must modify the image as part of the process. Not a
hard rule, but best to assume as a rule of thumb. This
seems to warrant a utility all by itself.

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

It sounds restore is broken then. The restore command
cannot ever assume anything about the GPT. Including
the tool that created the GPT. In order to restore a
GPT, it must be properly backed-up. The backup header
and table should suffice most of the time for that
purpose as it's a replica, but as soon as meta-data is
missing and the restore command has to guess, things
will go wrong.

-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140825/7c395b01/attachment.sig>