Torsten,
I indeed stumbled into the same problem, and it seems to be 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. 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 ;)
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 ? ;-)
>
> Torsten
>
> -
> 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/
>
-- Daniel Stone Kernel Hacker (or at least has aspirations to be) daniel@dustpuppy.ods.org http://dustpuppy.ods.org- 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 08 2000 - 09:17:45 EDT