Re: grub-probe detects ext4 wronly as ext2

[Robert Millan <rmh@aybabtu.com>]

On Thu, Jul 03, 2008 at 07:07:55PM +0200, Javier Martín wrote:
> > The question here is whether we should increase complexity with interfaces
> > that don't provide any usefulness to the user, just to make it easier to
> > do potentially dangerous things.  If a user understands the implications
> > and really doesn't mind making her system bootability unreliable, then she
> > should have no problem modifiing the source to do it.
> The system bootability is already unreliable with the current code,

You mean because grub-probe is not conservative enough when determining whether
a filesystem can be accessed?  I think we agreed that this needs fixing.

> and
> as I already explained, it will be unreliable as long as the filesystem
> drivers use the "best-effort" politics you support.

If grub-probe says "you can't rely on this filesystem being readable by
GRUB", then we're bound to that.  You don't make it any more reliable by
adding user input into the equation.

However, you can avoid the problem by refusing to access that filesystem
(perhaps by disabling font loading, or whatever we needed from it).  It's
at that point you can rely on GRUB being able to boot.

When I talk about real GRUB being "best-effort", it's not reliability that
is at stake here;  we already got that from grub-probe.  This is a minor
problem IMHO;  it's just about having read access to as many filesystems
as possible (other than the one we need for booting) vs not risking
corruption during data read.  I seriously think we're wasting our time
here.  Really, it's not worth it.  This whole discussion is not about how
we engineer a new feature or solve a bug, but about how we deal with a
_temporary_ limitation in our code.

> I'm just proposing
> that we change the default politics in the bootloader to "nearly
> conservative" and then having an user-controllable option to enable
> "best-effort" behaviour. I've had GRUB since at least 2004, and I've
> done a few nasty things in its command line from the start; but only now
> I feel comfortable enough to modify its source, so don't assume that a
> knowledgeable/advanced user will be brave enough to modify the source of
> his _bootloader_ just like that. I don't understand why you're so
> adamant against sensible defaults AND the possibility of a rational,
> free choice.

Because it's a gratuitous increase in complexity of the user interface.  It's
a choice about a bug, which is due to be fixed, and for which an informed
answer will always be the same.

> > This looks like a more general problem.  I wonder if we should really address
> > it at the filesystem level.  e.g. the filesystem could be perfectly fine but
> > the files in it went corrupt;  if the data you're reading is corrupt, does it
> > matter at which point it was corrupted?
> It does, if the data on disk is not corrupted and our filesystem driver
> reads wrong data because in its "best-effort" trials to read the data it
> forfeits the "specification"-mandated behaviour of aborting on finding
> incompatible feature flags. We would be INTRODUCING errors in the data,
> instead of just reading erroneous data because of a crash or something
> like that.

When the problem is you've read corrupt data, and you have to handle this
gracefuly, it doesn't make any difference that it was your fault because
you violated a spec, it's still the same problem.

> This is fine for update-grub, but the GRUB2 scripting language is
> complex enough that detecting every file access without missing any can
> get quite complex, and we'd need to embed even more code in the kernel
> (the hash verifier). I've implemented MD5 and SHA1 in various
> programming languages as a simple challenge and I can tell you that,
> while not the toughest thing in the world, it's not simple to get right
> and it means even less space in an already big core.img.

Why in the kernel?  It's essential that during install time you can rely on
/boot/grub being readable (otherwise I don't think we should support
install at all).

> I'm finding this discussion increasingly unproductive

Hey, at least we agree on something :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)