On Sat, 8 Jul 2000, Khimenko Victor wrote:
> In <E13AuLe-0005dX-00@dustpuppy.ods.org> Daniel Stone (daniel@dustpuppy.ods.org) wrote:
> > Torsten,
> > I indeed stumbled into the same problem, and it seems to be GRUB's fault.
>
> No. It's NOT GRUB's fault.
>
> > 0.5.93.1 was working *flawlessly* for me, and then 0.5.94 stuffed up - it
> > reported installing fine, but on boot, it did not do a thing.
>
> Yes. Since you are using 2.4.0 with described bug. GRUB 0.5.94 works
No, since you are using the functionality that was never promised to be
there. Example: fs has a perfect right to copy superblock out of the
buffer cache and slam it back whenever it wants, completely ignoring any
changes you've done to buffer cache. Or to keep it in pagecache and don't
have buffer heads hashed. You are _not_ supposed to bypass r/w filesystem
- it has absolute access to the device and that's the end of the story. So
the problem is not just partition vs. disk caches. You have no right to
expect any sort of behaviour from write access to fs mounted read/write.
It's on the mercy of _many_ things, starting with fs itself.
> *flawlessly* with 2.2.x kernel but not with 2.4.0. If GRUB 0.5.93
And dereferncing NULL "flawlessly" gives you zero on some systems. So?
> using less correct but more compatible with buggy kernel technique
> ans thus works with 2.4.0 it's not proof that kernel do not suffer
> from said bug.
"Your C compiler is buggy, I've upgraded to new release and my program
segfaults now. It used to work! It's very simple:
main() {
int i = 10;
printf("%d\n", 100/(i - --i));
}
Waddya mean, 'undefined behaviour'?!?!"
Urgh... What does GRUB actually need from a filesystem?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:09 EST