From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1P0tSj-0008WB-8L for mharc-grub-devel@gnu.org; Wed, 29 Sep 2010 06:00:33 -0400 Received: from [140.186.70.92] (port=58532 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0tSa-0008RI-ED for grub-devel@gnu.org; Wed, 29 Sep 2010 06:00:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0tST-00079z-J3 for grub-devel@gnu.org; Wed, 29 Sep 2010 06:00:24 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:59959) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0tST-00079p-Ev for grub-devel@gnu.org; Wed, 29 Sep 2010 06:00:17 -0400 Received: by wwb24 with SMTP id 24so646870wwb.30 for ; Wed, 29 Sep 2010 03:00:16 -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=d5Z5LdlkkNa+XkImmtMdlGog0n5LZNdpkOcIYOt6cGc=; b=RkXOvwMMQGzgTgPKswMNDbxA6A8D1iKO0b5nEz35ifX+Hg6eKb9f2m5cpIUqOXV4E/ u3TSR8MEywkD+L6LdaVeaOdRYtusH5haGtIm+lv2uP9ZbVVRvj2ccbVvx35bWeNNyrJK La6vSaSxH98BV7GyjYjnAvXfREqJKWCsYhYj0= 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=h6VE7asCPizRYGU9fVzDv10ockhWZSMIhaS8KEmZ5cRdZxvLkSrd760XURSGsct3g5 dK5VJWq3d9AbhPqsc5qlzpq9+ntzXmHLXfpMKn/vmAO2xKJ2tJZzuUyGQUbvk+QjJIX/ 2H2+ctT7oR2ZNkDjE75YiM7C5DC7LqsqzxP90= Received: by 10.216.144.22 with SMTP id m22mr2341194wej.0.1285754416448; Wed, 29 Sep 2010 03:00:16 -0700 (PDT) Received: from [147.210.129.4] (laptop-147-210-129-4.labri.fr [147.210.129.4]) by mx.google.com with ESMTPS id u11sm5233441weq.7.2010.09.29.03.00.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 03:00:15 -0700 (PDT) Message-ID: <4CA30E2D.2010801@gmail.com> Date: Wed, 29 Sep 2010 12:00:13 +0200 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9.2.9) Gecko/20100927 Lightning/1.0b3pre Lanikai/3.1.3 MIME-Version: 1.0 To: grub-devel@gnu.org 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> <4CA2621D.9070800@gmail.com> <4CA267F4.6000402@gmail.com> In-Reply-To: <4CA267F4.6000402@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: Wed, 29 Sep 2010 10:00:31 -0000 On 09/29/2010 00:11, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Let me try to explain more clearly what I have in mind. In the GPT case, we have a dedicated partition ID for bootloader software. This makes things simpler. If we had such a dedicated partition ID in the MSDOS case, then a lot of embedding problems would (a priori) go away. So it's worth trying to ``establish'' such a partition ID for MSDOS partitions. And good candidates are partition IDs that are already (almost exclusively) used by some bootloader software(s), because - those partitions are very likely to only contain bootloader code and configuration, so the risk of data loss when installing GRUB is minimized. - OSes and partitioning software may already know about them, which would limit the risk of losing the embedded GRUB code. >> 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. > OS/2 used type 0x0a. If someone wants to install the OS/2 on his > computer (I wouldn't attempt it on anything newer than Pentium 3) > then he probably wants to chainload it (direct loading OS/2 would > require much work and has no point, adapting ntldr would be possible > though, but I wouldn't spend any time on it). So he needs 2 boot > managers. Probably there are other similar cases as well. I didn't mean that we only need one partition for bootloaders. What I mean is that we only need one partition type. Such as, if you install two Linux distributions, you would have the same ID for all your Linux partitions. But I agree that, if we had two MSDOS partitions with the same ``bootloader'' type, then grub-install shouldn't blindly take the first one. Still, isn't this what happens in GPT case, when there are two BIOS Boot partitions? Or maybe, in the GPT case, there is no point in having several BIOS Boot partitions? Anyway, I'm sure that we can find solutions to make sure that, in a non-interactive mode, a new GRUB installation only overwrites a previous GRUB installation. > Deleting some other bootloader may also appear unfair and lead to > data loss if its partition contained anything useful. In the GPT case, doesn't grub-install delete existing data in the GPT BIOS Boot partition? > I don't mind sharing the embedding partition on the rule "who gets > MBR gets this bonus, I didn't see it this way. I assumed we could have different bootloader software in different partitions of the ``bootloader type''. > all possible occupants have to implement multiboot to be chainloaded > if necessary" but former users of partition type may disagree. Yes, of course, if we try to go this route, we would have to discuss it with former users of the partition type. Grégoire