public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Support HDIO_GETGEO on device-mapper volumes
Date: Fri, 10 Feb 2006 22:41:08 -0600	[thread overview]
Message-ID: <43ED6AE4.6050302@shaw.ca> (raw)
In-Reply-To: <5EN4d-3ZP-21@gated-at.bofh.it>

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/


       reply	other threads:[~2006-02-11  4:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5Evqz-3kK-9@gated-at.bofh.it>
     [not found] ` <5EHUJ-4sa-1@gated-at.bofh.it>
     [not found]   ` <5EIeb-55n-33@gated-at.bofh.it>
     [not found]     ` <5EN4d-3ZP-21@gated-at.bofh.it>
2006-02-11  4:41       ` Robert Hancock [this message]
2006-02-10  1:35 [PATCH] Support HDIO_GETGEO on device-mapper volumes Darrick J. Wong
2006-02-10 14:53 ` Alasdair G Kergon
2006-02-10 15:12   ` Phillip Susi
2006-02-10 20:27     ` Molle Bestefich
2006-02-10 21:21       ` Phillip Susi
2006-02-20 18:09         ` Molle Bestefich
2006-02-20 21:30           ` Phillip Susi
2006-02-21 13:30             ` Molle Bestefich
2006-02-21 16:02               ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43ED6AE4.6050302@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox