From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1N4GTg-0004AP-7J for mharc-grub-devel@gnu.org; Sat, 31 Oct 2009 12:06:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4GTe-00049m-6X for grub-devel@gnu.org; Sat, 31 Oct 2009 12:06:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4GTZ-00047L-87 for grub-devel@gnu.org; Sat, 31 Oct 2009 12:06:53 -0400 Received: from [199.232.76.173] (port=39814 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4GTZ-00047G-4c for grub-devel@gnu.org; Sat, 31 Oct 2009 12:06:49 -0400 Received: from xvm-190-8.ghst.net ([217.70.190.8]:47423 helo=aybabtu.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N4GTW-0005Ao-85 for grub-devel@gnu.org; Sat, 31 Oct 2009 12:06:46 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1N4GTQ-0005rF-Ie for grub-devel@gnu.org; Sat, 31 Oct 2009 17:06:40 +0100 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1N4GTR-0006Qe-Sg for grub-devel@gnu.org; Sat, 31 Oct 2009 17:06:41 +0100 Date: Sat, 31 Oct 2009 17:06:41 +0100 From: Robert Millan To: The development of GRUB 2 Message-ID: <20091031160641.GA24642@thorin> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57a6d2110910310839p7324bb59vf9184c2c29db3dbb@mail.gmail.com> 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 monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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 16:06:54 -0000 On Sat, Oct 31, 2009 at 11:39:16AM -0400, Andrew Clausen wrote: > Hi Felix, > > 2009/10/31 Felix Zielcke : > > That only happens if you use grub-install with --modules or you directly > > create it with grub-mkimage. > > By default there's just one module and there only needs to be one. > > The one to access /boot/grub. > > It doestn't make sense to include more then one fs module into core.img > > With grub.efi the situation seems to be different though. But IMO it's a > > bug there. > > 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. > 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. 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. 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. 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. -- 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."