Re: [patch] grub incorrectly identifies ext3 as fat

[Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>]

Andrew Clausen wrote:
> Hi Robert,
>
> 2009/10/31 Robert Millan <rmh@aybabtu.com>:
>   
>>> 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