From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 07:48:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D03EAEAE; Mon, 25 Aug 2014 07:48:45 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 627223B04; Mon, 25 Aug 2014 07:48:45 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward7l.mail.yandex.net (Yandex) with ESMTP id E94FBBC118C; Mon, 25 Aug 2014 11:48:41 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 363FF1B44EC1; Mon, 25 Aug 2014 11:48:41 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id OfuJFoxDWM-meUitK4r; Mon, 25 Aug 2014 11:48:40 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: b1060a7f-a0c1-4c1f-b0fa-8bd88b795716 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408952920; bh=aS+yhRxigrW4ZIbwdktGpuuj9WszxJ1V8rhsBusdZF4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=QFuIBU+ZwiKAkCfGEYMOvmWARgU1QuOGCfAcZ2xszonKFf9hmmWqaoiZIfb9y+Yik 6FyWOe/Z8mQjQBsxQUnBsxVYxTZrMen+hMepirNPwHl+Dsfv+0L0q7GKb5mGl0x8Jz /h3A+0c7UI+nHLB5qskyldBmcbKLhxgcmK1WWhl8= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FAEA31.1070108@yandex.ru> Date: Mon, 25 Aug 2014 11:48:01 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marcel Moolenaar , John-Mark Gurney Subject: Re: mkimg used to create gpt image, problem booting 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> In-Reply-To: <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , 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 07:48:46 -0000 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