Re: [patch] grub incorrectly identifies ext3 as fat

[Andrew Clausen]

Hi Robert,

2009/10/31 Robert Millan <address@hidden>:
>> 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.

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.

> 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.)

> 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...

> 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.)

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.

I think this is very important: I spent hours trying to get my
computer to boot.  The error messages ("error: file not found", and ls
coming up empty, etc.) were uninformative, and I really had to think
hard to figure out the problem.  Realistically, I think almost all
users would never have figured out the problem without reporting a
bug.  Being unable to boot Linux is quite a show-stopper.

Cheers,
Andrew