El vie, 04-07-2008 a las 02:08 +0200, Robert Millan escribió: > 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. Indeed, grub-probe should adopt the most conservative stance possible so that real GRUB works on minimum assurances. However, I meant reliability was compromised because grub-probe, as currently used by grub-install on i386-pc, only checks the availability of the filesystem GRUB will boot from. Thus, if GRUB is installed on a normal ext2/fat/whatever partition and the OS kernel we will boot (or another file we want to use) is stored in an ext4 partition, the most likely output of our current scheme is an error from the ext2 driver (ranging from an error message to a crash), because in its current best-effort policy it ignored the "forbidden" signs in the superblock and tried to read the ext4 partition as ext2.
> > > 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. As I said, there are setups in which (the current use of) grub-probe does not add any reliability, because it just checks the GRUB boot partition, not those with the kernels we might load (and I'm not proposing instituting such checks). > > 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. It is both a temporary limitation and a permanent one: the limitation of not being able to read ext4 extents and such is temporary indeed, but I already said why we cannot just ignore the "incompat" field. Today is ext4, tomorrow it will be something else. As I mentioned above, such flags are huge warning signs telling us not to dare enter the partition if we don't know what to do with them. > > > 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. As I said before, we can fix the "ext4 compatibility not implemented" bug, we WILL eventually encounter _another_ "incompatible" feature, and then another... We can't be in par with the evolution of extN filesystems! > > > > 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. Fine, then. Let's _not_ worry about automatically trying to read what we cannot, violating standards and such. After all, GRUB _is_ better than Internet Explorer. It _does_ make a difference because we can avoid it being our fault if we just obey the huge warning signs in the superblock! If the user specifically requests us to try and read the partition even though the superblock tells us not to, then we proceed and whatever happens is, at least in part, his fault, even though this does not completely exonerate us for not having a completely up-to-date filesystem driver. > > I'm finding this discussion increasingly unproductive > > Hey, at least we agree on something :-) > As I threatened in my last post, here is the full patch, with the incompatible features detection and the user override option, for a total of +168 bytes in i386. It works like this (test was on a QEMU VM, with GRUB booting from floppy and hda1 being an ext2 part turned ext4): grub> ls (hd0,1)/ error: unknown filesystem grub> set ext2_options=ignore_incompatible grub> ls (hd0,1)/ lost+found/ grub/ Godfather.wav vmlinuz-2.6.24-16-server (&more) grub> linux (hd0,1)/vmlinuz-2.6.24-16-server [Linux-bzImage, setup=0x2a00, size=0x1e26d8] grub> hexdump (hd0,1)/Godfather.wav (shows 256 bytes of zeros instead of the actual contents) Of course, the new file (with extents) was the Godfather tune, while the kernel was an old extentless file. Trying to "play" the file crashed QEMU (I suspect that meant a triple fault happened in the simulation?) That was it. I will post no more in this thread. Do whatever you please with the patch - I'll just request some more people from the GRUB dev team to review the thing, instead of the tennis match we've had here (and I appreciate all matches, even the ones I lose).
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel