[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] grub incorrectly identifies ext3 as fat
From: |
Vladimir 'phcoder' Serbinenko |
Subject: |
Re: [patch] grub incorrectly identifies ext3 as fat |
Date: |
Sat, 31 Oct 2009 19:52:50 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20090701) |
Andrew Clausen wrote:
> 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.
>
>
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
- [patch] grub incorrectly identifies ext3 as fat, Andrew Clausen, 2009/10/29
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/30
- Re: [patch] grub incorrectly identifies ext3 as fat, Felix Zielcke, 2009/10/30
- Re: [patch] grub incorrectly identifies ext3 as fat, Andrew Clausen, 2009/10/30
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/30
- Re: [patch] grub incorrectly identifies ext3 as fat, Andrew Clausen, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Felix Zielcke, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Andrew Clausen, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Andrew Clausen, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat,
Vladimir 'phcoder' Serbinenko <=
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, rubisher, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Felix Zielcke, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Felix Zielcke, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Felix Zielcke, 2009/10/31
- Re: [patch] grub incorrectly identifies ext3 as fat, Robert Millan, 2009/10/31