From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MTfQb-0003P6-CK for mharc-grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:29 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTfQY-0003OC-JF for grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTfQT-0003Nb-Av for grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:25 -0400 Received: from [199.232.76.173] (port=44801 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTfQT-0003NX-3g for grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:21 -0400 Received: from mx20.gnu.org ([199.232.41.8]:45729) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTfQS-0004Sj-MS for grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:20 -0400 Received: from aybabtu.com ([69.60.117.155]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTfQS-0005rJ-52 for grub-devel@gnu.org; Wed, 22 Jul 2009 13:16:20 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1MTeKa-00071J-FC for grub-devel@gnu.org; Wed, 22 Jul 2009 18:06:12 +0200 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1MTfQK-0002Io-9c for grub-devel@gnu.org; Wed, 22 Jul 2009 19:16:12 +0200 Date: Wed, 22 Jul 2009 19:16:12 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090722171612.GC8706@thorin> References: <20090717165140.GN11691@riva.ucam.org> <20090718184555.GH8867@thorin> <20090718191741.GM8867@thorin> <20090719100741.GA12723@riva.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090719100741.GA12723@riva.ucam.org> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: [PATCH] Fix when installing on pationless but partionable medium X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:16:27 -0000 On Sun, Jul 19, 2009 at 11:07:41AM +0100, Colin Watson wrote: > On Sat, Jul 18, 2009 at 09:17:41PM +0200, Robert Millan wrote: > > On Sat, Jul 18, 2009 at 09:01:38PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > > On Sat, Jul 18, 2009 at 8:45 PM, Robert Millan wrote: > > > > I might be missing something about this check, but GRUB doesn't require that > > > > the boot flag is present.  Therefore, its non presence doesn't imply this is > > > > not a real msdos label. > > > > > > He refers to boot flag as a byte in msdos structure which can only be > > > 0x00 (not set) or 0x80 (set) > > > > Yes. GRUB's boot.img doesn't do anything with it AFAICT. > > That's as may be, sure; but checking that that byte is one of the two > permitted values in all four partitions happens to be a good sanity > check for whether it's really an MS-DOS label or in fact something else. As a bootloader, most of the decisions GRUB takes have a critical effect. We can't make GRUB take those decisions based on heuristic. If we determine that something ought to be done, and we do it, we're taking responsibility for it. Bootloader-related breakage tends to be severe, and we can't afford to be blamed for it just because "our heuristic got it wrong". Going down this path, if our heuristic is not good enough, we'll have to improve it. We'd make it more complex and check for more things. But no matter what we do, it can never be completely reliable. Similarly, and as I said before (in this thread or another, I'm not sure), the situation in which someone using a _sane_ MBR label with a sane filesystem in it is our primary use case, and the ability of GRUB to install in it must not depend on heuristic. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."