Messages in this thread | | | Subject | Re: linux-2.4.0 breaks grub install into partition | Date | Sat, 08 Jul 2000 23:08:20 +1000 | From | Daniel Stone <> |
| |
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/
| |