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
*flawlessly* with 2.2.x kernel but not with 2.4.0. If GRUB 0.5.93
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. I'd like more simple test case, though: GRUB is far
to complex program to use it like test case (even if bug is indeed in
kernel).
> There was only that cute little Award BIOS bit telling me about my system.
> And then a blinking cursor. It obstinately persisted in doing that. I fell
> back to 0.5.93.1. It worked fine. Bitch at the GNU GRUB people ;)
Oh, yeah.
- PostreSQL does not work reliable with Linux due to strange kernel behaviour
with sockets while works just fine with HP-UX, Solaris, *BSD and so on.
- You are wrong - it's not kernel problem at all since MySQL works just fine.
- Huh ?
What's the difference ?
P.S. BTW what about socket handling. Can ANYONE comment on strange Linux's
behaviour ? When socket is closed by server client will get EPIPE but then
if you'll try to read from socket once more you'll get the rest of data.
Looks like VERY strange logic to me :-/
> d
>> Hi all,
>> here's a problem we've stumbled across testing the 2.4.0 pre-kernels:
>> installing grub (0.5.94 if that should matter) into the boot block of a
>> partition mounted r/w no longer works; it flawlessly used to in 2.2.x .
>>
>> A little investigation using strace and friends shows that grub does its
>> proper job, finds the right spots and writes there. The write to the
>> partition boot block though is somehow discarded, but no error is returned.
>>
>> Linux kernel people be informed that grub uses the whole-disk device
>> (e.g. /dev/hda) to do its job, to always get the most current view of the
>> disk partitioning, in case a re-read partition table ioctl failed. This also
>> makes the boot loader's behaviour consistent with the grub-"shell" running in
>> the unix environment; they both look very alike, which is one of its strength
> s.
>>
>> Digging through the kernel sources Olaf and me have come up with this theory:
>> the buffer hash chains for the whole-disk device and the partition device are
>> totally unrelated; therefore the grub write will allocate a new buffer on the
>> /dev/hda hash and not use the proper in-core buffer of e.g. /dev/hda4's first
>> block, where the mounted superblock resides. That one in turn will become
>> dirty very quickly, and on the next sb sync will effectively undo grub's
>> action.
>>
>> This is backed by the fact that the in-place modification of the stage2
>> loader within the same partition works well and that all is fine when the
>> partition is unmounted or even mounted read-only.
>>
>> What can we do about it ? I don't think it's right to say it is grub's fault
>> -- working on the whole disk is a totally legal operation and should work as
>> expected. My best guess is to associate all buffers with the _real_ disk they
>> reside on, not the partition.
>>
>> Opinions ? Concepts ? (Patches ? ;-)
>>
-
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