From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1P0cI8-0000GX-0b for mharc-grub-devel@gnu.org; Tue, 28 Sep 2010 11:40:28 -0400 Received: from [140.186.70.92] (port=56886 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0cI5-0000FQ-0a for grub-devel@gnu.org; Tue, 28 Sep 2010 11:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0cHy-0003ce-Kg for grub-devel@gnu.org; Tue, 28 Sep 2010 11:40:24 -0400 Received: from exhub016-4.exch016.msoutlookonline.net ([207.5.72.225]:41606) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0cHy-0003cI-Ei for grub-devel@gnu.org; Tue, 28 Sep 2010 11:40:18 -0400 Received: from [10.1.1.235] (72.242.190.170) by smtpx16.msoutlookonline.net (207.5.72.190) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 28 Sep 2010 08:40:16 -0700 Message-ID: <4CA20C5D.1080302@cfl.rr.com> Date: Tue, 28 Sep 2010 11:40:13 -0400 From: Phillip Susi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 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> In-Reply-To: <20100928080423.GN21862@riva.ucam.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP4, XP SP1+ Cc: Colin Watson 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 15:40:26 -0000 On 9/28/2010 4:04 AM, Colin Watson wrote: > * The BIOS can often only read from relatively near the start of the > disk, and core.img must be readable by the BIOS. If some other > operating system is already installed - the common dual-boot case, > and the case where this problem is overwhelmingly most likely to > matter - it's likely to occupy a large stretch of partitioned space > right after the boot track. If int13 can't access the whole disk then it does not really matter where the grub core image is since it still has to use int13 to load the kernel. If the bios is broken, then grub might load, but can't load your kernel. Worse yet, it might all work fine when you install, then you later upgrade something that rebuilds your initrd, and it happens to get allocated further down the disk and suddenly you can't boot. The only sane way to deal with such a broken bios is to put all of /boot near the start of the disk. > * The MBR format has so many irritating restrictions on primary > partitions that the more partitions an operating system needs to > create by default, the more stress we put on partitioning > algorithms. (Most people don't notice any of this until they try to > install on a machine whose OEM helpfully created three or four > primary partitions already.) With 3 partitions you should be fine since you only need one for the extended partition. What does the installer do now when all 4 are used? Doesn't it just bail out? As long as you are creating an extended partition to hold the root and swap logical partitions anyhow, you may as well make one more for grub.