Re: grub-probe detects ext4 wronly as ext2

[Bean]

On Fri, Jul 4, 2008 at 6:34 PM, Javier Martín <address@hidden> wrote:
> I know I promised not to keep posting but... I just cannot xD
>
> El vie, 04-07-2008 a las 14:49 +0800, Bean escribió:
>> Hi,
>>
>> This is an example of good practice,  which check the driver
>> by function, not by flags.
> This will find and check core.img. As my previous post showed, one file
> being readable in a partition with an incompatible flag does not
> guarantee that every file will be. Thus, the conservative policy for
> grub-probe would be to also check that the FS is "theoretically"
> accesible (i.e. the ext2/whatever driver is fine with its flags) in
> addition to the current "practical" check.

Yes, one file can't guarantee the whole fs is accessible, but it's a
good indicator. Nothing can guarantee 100% success. Even without
structure change, grub can still fail if the underlying fs is dirty.

>>
>> The  flags are a little vague, for example,
>> if they change btree structure in the future, this would introduce
>> another flag, but we don't need to worry about it, because we don't
>> use it at all.
> The btree flag (and any of its modifications) is ROCOMPAT, which indeed
> allows us not to worry about it at all, because our driver is read only.
> The proposed patch addresses only INCOMPAT flags, and it even adds a
> mechanism to ignore some of them because we deem them not to create real
> incompatibilities (like needs-recovery).

It's just an example. We only use part of ext's structure, there is
every chance that some part of it has been changed and we're not
affected.

>>
>> If we can ensure the boot partition can be accessed, then the problem
>> is solved. Yes, there may be other partition using ext4 that we can't
>> access, but remember that linux loader will check for signatures as
>> well, a corrupted kernel would not be loaded. So the difference is
>> merely the error message users sees, unknown filesystem or invalid
>> kernel.
> I didn't know the "linux" loader checked signatures. Do the "multiboot",
> "multiboot2" and "bsd" loaders do the same? In the platforms where it is
> able to load a file, does the "chainloader" loader perform any checks?
> So in that cases difference would be between "unknown filesystem" and
> "the FSM knows what".
>

Yes, they all check for signatures. In fact, commands that deal with
input file should always check for it first. If not, we need to fix
that command.

>>
>> And, grub WILL follow the evolution the extN, because it's the primary
>> boot loader for linux. The only reason we don't have ext4 support at
>> present is because it's not stable. If major distro starts to use it
>> as default, we would have to support it as well.
> Please... ReiserFS was used for long in many distros and GRUB2 didn't
> support it until 1.96 - even with GRUB Legacy having implemented it long
> ago. I literally waited years for it to be included! Besides, as I
> already said, we cannot win in a race against the future: new features,
> some of them incompatible, are introduced ""constantly"" (every few
> years) in extN, and until we get to know about them and at least decide
> whether they can be safely ignored, the sane behavior is to obey them
> and reject access (except if the user override is enabled). Yes, we can
> implement ext4 and possibly even before it's released as stable, but
> could you please start implementing ext7 so that we don't have to worry
> about its incompatibilities when it comes?

It's an ongoing process for grub. Besides, compatibility goes both
ways. The developer of extN file system would also consider existing
driver, significant change to the fs structure would not be as
frequent.

-- 
Bean