From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1P0i05-0003wu-Qg for mharc-grub-devel@gnu.org; Tue, 28 Sep 2010 17:46:13 -0400 Received: from [140.186.70.92] (port=51703 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0i03-0003wB-Iz for grub-devel@gnu.org; Tue, 28 Sep 2010 17:46:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0i02-0004jB-Cc for grub-devel@gnu.org; Tue, 28 Sep 2010 17:46:11 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:57939) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0i02-0004iy-7B for grub-devel@gnu.org; Tue, 28 Sep 2010 17:46:10 -0400 Received: by wwb24 with SMTP id 24so163599wwb.30 for ; Tue, 28 Sep 2010 14:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hXLr+k5vzBMHznvBm/GVwo543DlO+sfSMLrmak8SrsA=; b=RjgGErc2yGB7Ys9Ix1MaBsZmoyua4nrXoeeKLVyrY0i35EILkvnUXbpRJQ24/CKP5A l1VFN+1BvGx3GEByQymyU9XHPoDXnkYi9SIUuqKP2+yftIHRulSSfUO3amVv6t67jM5J oLX9fw7Bv4Y8HOFA721lXG/4nEXTxhNlgddh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=muWfGUGhdpnJ1jaTT4VEqR9cs2Ywlxns2bNIKwWAP4ev1jGuNFtc3IgoLvGJyLvsGF fq/ZlndJKLdqMFsfqt2+7zrAdhBdp3bIEPUdv0wdKmdxP2mGT9zYUTkcTkH0aSI/E8AW EpMvo6bynUnBKhcR8dQvVG38naJTE7CjIzwI0= Received: by 10.216.6.201 with SMTP id 51mr1623332wen.110.1285710369044; Tue, 28 Sep 2010 14:46:09 -0700 (PDT) Received: from [192.168.1.50] (c2433-1-88-160-112-182.fbx.proxad.net [88.160.112.182]) by mx.google.com with ESMTPS id x33sm4867343weq.47.2010.09.28.14.46.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 14:46:07 -0700 (PDT) Message-ID: <4CA2621D.9070800@gmail.com> Date: Tue, 28 Sep 2010 23:46:05 +0200 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100913 Iceowl/1.0b1 Icedove/3.0.7 MIME-Version: 1.0 To: The development of GNU GRUB References: <20100923221923.GA21862@riva.ucam.org> <20100924002753.GE8579@caffeine.csclub.uwaterloo.ca> <197110.28172.qm@web113213.mail.gq1.yahoo.com> <20100928080423.GN21862@riva.ucam.org> <4CA23C71.9040601@gmail.com> In-Reply-To: <4CA23C71.9040601@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Guidance on conflicts between GNU GRUB and proprietary software X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 21:46:12 -0000 On 09/28/2010 09:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Using an embedding partition on msdos as an optional alternative (not as > replacement) to MBR gap is a clear possibility, good idea and was > proposed before but details are very unclear. Like: > - How to create such partition > - How does grub find it and ensures that it's an embedding partition? > Any false positive will result in data loss. Obviously no msdos type is > completely unused by now so it's not a way. We could borrow a partition type that is reliably used only by boot managers (for similar purposes). Ok, we may overwrite some boot manager code sitting in that partition. But would this be different from what happens in the GPT case? Regarding the question of whether such an MSDOS partition type exists, I did not look very hard, but 45h comes to mind. This type is used by the Boot-US boot manager. It is reported as such by NetBSD fdisk. It is not listed in the known types of Linux fdisk. Are you aware of other uses for this partition type? If we really want to embed in an MSDOS partition, selecting a partition type that is already used for similar purposes is IMHO our best option. This would be a step in a direction to set a ``standard'' MSDOS type for boot partitions. We don't need one partition type per boot-loader software anyway. Grégoire