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 strengths.
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:09 EST