On Sun, 2 Jan 2005, at 7:52pm, [EMAIL PROTECTED] wrote: >> Programs (like parted) which previously depended on the kernel to provide >> good answers got hosed. This could easily render a legacy OS unbootable. > > That's a good reminder to check versions of code you depend on before you > do something potentially destructive. ... The parted guys may not have > expected kernel 2.6 to change much, but certainly kernel 5.2 might treat > partition tables differently.
Well, in this case, it's not a simple case of obsolete software on a much more modern system. It's modern software (parted) on a modern system (Linux), dealing with a bad hardware design layered with horribly broken extensions. Really, the whole geometry thing was a mess before. This latest complication has only made things worse. But it *did* make things worse, and I feel we could have done without that. The specific problem stems from the fact that a given individual drive can have more then one "geometry". IDE drives report a geometry to the host when asked. This geometry is invented by the drive's onboard electronics, since the actual, internal, *physical* geometry is non-uniform. I will call this the "IDE geometry". Now, to work around certain esoteric limits, the IDE geometry will often be translated by the host (mainboard or IDE adapter BIOS, generally) into a *different* invented geometry. It mainly involves decreasing the number of cylinders while increasing the number of heads, IIRC. I will call this the "translated geometry". The partition table generally uses the translated geometry. Prior to kernel 2.6.something, the Linux kernel generally reported the translated geometry when asked. Then, in kernel 2.6.mumble, it was changed to report the "IDE geometry" instead. (The actual situation is even worse, but the above will do.) This meant that the kernel effectively scrambled the disk for anything trying to work both within and outside of Linux, and that trusted the kernel to give consistent answers. I, along with many others, feel that (1) a function that has such a critical impact should not be changed without a lot of prior warning, (2) rather then changing the answer given, the kernel should return an error (such as ENOSYS). I also question the validity of the basic assumption that the problem is somebody else's. I also dislike the attitude that "We're the only OS that matters". That's something I usually get from a legacy OS, not Linux. These are subjective, non-technical opinions, however. The ideas in the previous paragraph are general best practices. -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | _______________________________________________ gnhlug-discuss mailing list [email protected] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
