From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1N4J4Q-0001PY-08 for mharc-grub-devel@gnu.org; Sat, 31 Oct 2009 14:53:02 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4J4N-0001Ms-D9 for grub-devel@gnu.org; Sat, 31 Oct 2009 14:52:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4J4J-0001LG-QH for grub-devel@gnu.org; Sat, 31 Oct 2009 14:52:59 -0400 Received: from [199.232.76.173] (port=39921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4J4J-0001LD-Nb for grub-devel@gnu.org; Sat, 31 Oct 2009 14:52:55 -0400 Received: from mail-bw0-f215.google.com ([209.85.218.215]:54943) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N4J4I-0003nb-S4 for grub-devel@gnu.org; Sat, 31 Oct 2009 14:52:55 -0400 Received: by bwz7 with SMTP id 7so4853921bwz.26 for ; Sat, 31 Oct 2009 11:52:54 -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=+cqv0vKIjWhNTe5n9n4aSjbDc7UhvsPUgtuR+eS1g+o=; b=qNNEjBWcscQRjUqnKGPcrckpRiu4fDfx0w7wC9Tom4RF3vzKFJhS1YYd7VJVCDxlgp q0dPo78/N3IkX16wAgIu3T11yzzL7eM8gFMcWpAL5ejmIiiqu3H4iW1BfXeX5JYY0/SY vJHEw3Jb5xD+BeqI+2+V36+ti3Aw1qxHwYsis= 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=TijUBRnjta3vY4asJIPO10LcnoSKtIUZ/95XcWkLiwQOZg2Qwq3671eDxaXFLzpY9X 5jjEuf6odJdz22prqHnDCGULO4zTjGUf+ryq+/FiTkOj+n1mS2HFDn0c0jEHEJldCUcG KdvAENiTF8iD3DoVE2wOS2zi8o7r7wjeLzkJQ= Received: by 10.204.25.5 with SMTP id x5mr2232303bkb.166.1257015173095; Sat, 31 Oct 2009 11:52:53 -0700 (PDT) Received: from debian.bg45.phnet (vpn-global-dhcp1-71.ethz.ch [129.132.208.71]) by mx.google.com with ESMTPS id 21sm2426817fks.39.2009.10.31.11.52.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 11:52:52 -0700 (PDT) Message-ID: <4AEC8782.1060708@gmail.com> Date: Sat, 31 Oct 2009 19:52:50 +0100 From: Vladimir 'phcoder' Serbinenko User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: The development of GRUB 2 References: <57a6d2110910290758i23de79c1y2b87513f674023b@mail.gmail.com> <20091030185759.GA30150@thorin> <57a6d2110910301219w236e2472oa28e726d7876e4ae@mail.gmail.com> <20091030224639.GA32482@thorin> <57a6d2110910302344x4209dcb4mb745e30487ad7428@mail.gmail.com> <1256983491.3186.2.camel@fz.local> <57a6d2110910310839p7324bb59vf9184c2c29db3dbb@mail.gmail.com> <20091031160641.GA24642@thorin> <57a6d2110910311143rde5335ascf3895b9fc3c0745@mail.gmail.com> In-Reply-To: <57a6d2110910311143rde5335ascf3895b9fc3c0745@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [patch] grub incorrectly identifies ext3 as fat 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: Sat, 31 Oct 2009 18:52:59 -0000 Andrew Clausen wrote: > Hi Robert, > > 2009/10/31 Robert Millan : > >>> What if you have a dual boot setup, with say ntfs and ext3? >>> >> The filesystem module that is embedded in core.img is only for bootstrap >> purposes. Once GRUB can access /boot/grub/, it automatically loads the >> modules required for menu entries. >> > > OK, here's a realistic use case that could hit lots of users: > * grub is installed on an ext3 partition > * the user has OSX installed on an HFS file system (or whatever they > use now) that has stale ext3 signatures > * when grub tries to load the OSX kernel, it has two filesystem > modules loaded: ext2 and hfs. > * the stale signature causes it to misdetect it as hfs, and it fails. > > hfs+ and ext2 use same sector as superblock so it's not a problem > I suppose you could solve this problem by unloading all filesystem > modules except the ones you need at that moment? But Grub doesn't do > that now, right? > > >>> Isn't it easy to just fix the bug? >>> >> First of all, it's not a bug. Filesystems weren't designed to be identifiable >> reliably. They could have been, but they weren't, and now we're stuck with >> that. Everything GRUB does to archieve filesystem detection is on a BEST >> EFFORT basis. >> > > I think this is where we disagree... I think that with good > heuristics, you can cover all use cases without any problems. > > (For instance, GNU Parted has a fairly short list of heuristics that > seem to be very reliable -- or they were when I maintained it. The > relevant function is ped_file_system_probe().) > > Alternatively, you could allow the user to specify the file system? > > Or, you could warn when multiple file systems have matching signatures. > > Or you can modify the tools to clear first and last MiB on mkfs which solves problem at the root >> With that in mind, we can find ways in which GRUB will be more succesful at >> identifiing them. For example (and we already do this), the search command >> gives priority to filesystem modules that are already loaded. >> > > This heuristic could have a lot of problems. (See my example above.) > > Any heuristic means that something is wrong. >> Or we can attempt to read a given file when we expect it's there. For >> example, if we're looking for /boot/grub/, we can tell "/boot/grub" to the >> filesystem layer, so that it will require it as a precondition. >> > > I can see that that would work will for some use cases... > > It breaks encapsulation and makes code a lot less maintainable. And just offset clear bug to a lot of strange and weird bugs >> There are many ways to improve this, but making arbitrary assumptions about >> the content of a filesystem (e.g. non-emptyness) doesn't sound like the best >> solution. In this particular case, you can be hit by both false positives >> and false negatives. >> > > Huh? I can't see any way to get "hit" by either for this particular > heuristic. It reduces the number of false positives, and the false > negatives are irrelevant (because an undetected filesystem is > equivalent to an empty one.) > Many filesystems would look having some weird filenames but still having a directory if they are false positives. > Big picture: I'm sorry for being irritating... I know that odd > heuristics are an unpleasant technology to determine whether or not a > computer can boot or not. > We both have similar approaches: try to pick something that works well > under difficult circumstances. I think we differ in the way we think > about use cases. You don't like my heuristic because it has false > positives and false negatives; but I claim that there is no use case > (realistic or unrealistic) in which my heuristic makes things worse. > Some of your proposed heuristics seem reasonable in addition to my own > one, but I think it's clear that adding my heuristic will always make > Grub work better. > Every heurisitic makes code less clear and more prone to bugs and in long run results only in more heurisitc failures. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git