Re: [patch] grub incorrectly identifies ext3 as fat

[Robert Millan <rmh@aybabtu.com>]

On Sat, Oct 31, 2009 at 11:39:16AM -0400, Andrew Clausen wrote:
> Hi Felix,
> 
> 2009/10/31 Felix Zielcke <fzielcke@z-51.de>:
> > 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."