Re: Support HDIO_GETGEO on device-mapper volumes

[Robert Hancock <hancockr@shaw.ca>]

Molle Bestefich wrote:
> Phillip Susi wrote:
> > Yes, I think this could also be fixed on grub's end.  It seems that
> > fdisk assumes usable default values for the geometry but grub has
> > different defaults that cause it problems.  I think that the defaults
> > could be modified in grub so that it will work when HDIO_GETGEO fails.
>
> It would be better to make the decision once and for all, in one place.
>
> It would be even better for the HDIO_GETGEO call to return the same
> geometry that the BIOS uses, so that Grub is handed numbers that
> actually mean *something*.

The numbers don't really mean anything in any case, it's a matter of 
choosing one fiction over another. I don't know that there would be any 
easy way for the kernel to know which BIOS drive corresponds to the 
device, and the device may be one that's not recognized by the BIOS at 
all and therefore has no BIOS device (ex: Linux software RAID).

There were problems with this that surfaced sometime after the release 
of the 2.6 kernel, where installing Fedora Core 2 on a dual-boot system 
with Windows would render Windows unbootable. As I recall, it seems that 
even though it doesn't really use CHS, the Windows boot loader somehow 
cares that the CHS geometry in the partition table and/or MBR matches 
the BIOS reported geometry and chokes if it doesn't. As I see it, the 
solution to that would be to not touch the existing geometry if there's 
already one there, and if not, then try to find out the BIOS geometry 
for the drive somehow and put that in.

--
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/