From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 14:41:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 186245DD; Mon, 25 Aug 2014 14:41:01 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8372333D; Mon, 25 Aug 2014 14:41:00 +0000 (UTC) Received: from [172.23.227.91] ([66.129.246.4]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7PEeuGv008784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 07:40:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: <53FAEA31.1070108@yandex.ru> Date: Mon, 25 Aug 2014 07:40:50 -0700 Message-Id: References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> <53FAEA31.1070108@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , John-Mark Gurney , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:41:01 -0000 --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov 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@xcllnt.net --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP7SvIACgkQpgWlLWHuifZl5wCeOzKi+goy+G3DWYgpyaYHX+Mp nOcAmwQXh+tDRxxUcw+vWkCvlSgB5jij =/jUa -----END PGP SIGNATURE----- --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6--