Kernel & BIOS return differing head/sector geometries

Kernel & BIOS return differing head/sector geometries

[Luis Miguel Garcia]

hello

I'm getting this while running lilo from kernel 2.5.72mm2. What does it means?

Could it be dangerous?

Thanks.



bash-2.05b# lilo
Warning: Kernel & BIOS return differing head/sector geometries for device 0x80
    Kernel: 13424 cylinders, 15 heads, 63 sectors
      BIOS: 788 cylinders, 255 heads, 63 sectors
Added 2572mm2
Added 2573desktop
Added 2421-ck1 *

Re: Kernel & BIOS return differing head/sector geometries

[Andries Brouwer]

On Tue, Jun 24, 2003 at 01:09:06AM +0200, Luis Miguel Garcia wrote:

> I'm getting this while running lilo from kernel 2.5.72mm2. What does it means?
> bash-2.05b# lilo
> Warning: Kernel & BIOS return differing head/sector geometries for device 0x80
>     Kernel: 13424 cylinders, 15 heads, 63 sectors
>       BIOS: 788 cylinders, 255 heads, 63 sectors

It means that Kernel and BIOS each invent a fake geometry for your disk,
and they did not invent the same fake geometry.

> Could it be dangerous?

No.

Linux does not use the BIOS, and does not use CHS either, so geometry is
totally and completely irrelevant to Linux.

Depending on the precise LILO version, and on whether you give options
like "linear" and "lba32", LILO might or might not be confused.
Test whether you can boot. If booting works all is well. If not
make sure you set at least one of "linear" and "lba32".

If you also have DOS on the same disk the story is more complicated.
All systems on a disk must agree as to where the partitions are,
or corruption will be the result.

Re: Kernel & BIOS return differing head/sector geometries

[Frank Cusack]

On Tue, Jun 24, 2003 at 01:39:08AM +0200, Andries Brouwer wrote:
> Linux does not use the BIOS, and does not use CHS either, so geometry is
> totally and completely irrelevant to Linux.

Is that also true for 2.2?  I've had problems where large drives (60+G)
do these geometry tricks, and if I don't force the geometry to what I
want, fdisk (actually, sfdisk, dunno about fdisk) doesn't see the
entire drive.

Sometimes the BIOS doesn't report the specific geometry that the kernel
detects means "LBA" (I think this depends partly on drive firmware) and 
then the kernel writes out some goofy geometry to the partition table
(I assume kernel geometry info is kept there?) and again I have problems
accessing the entire drive.

Also, if I later change the geometry, the previous partition table seems
to become incorrect.  This one really confuses me, shouldn't the partition
table be indexed by sectors?

Anyway, it's been a very long time since I've worked directly on this
problem, so lots of my characterizations may be wrong.  But I do know
that we force the geometry to specific values in our install, to combat
specific problems we've encountered.

/fc

Re: Kernel & BIOS return differing head/sector geometries

[Andries Brouwer]

On Mon, Jun 23, 2003 at 05:31:24PM -0700, Frank Cusack wrote:
> On Tue, Jun 24, 2003 at 01:39:08AM +0200, Andries Brouwer wrote:
> > Linux does not use the BIOS, and does not use CHS either, so geometry is
> > totally and completely irrelevant to Linux.
> 
> Is that also true for 2.2?

Yes.

> I've had problems where large drives (60+G)
> do these geometry tricks, and if I don't force the geometry to what I
> want, fdisk (actually, sfdisk, dunno about fdisk) doesn't see the
> entire drive.

Most likely you are talking about a disk soft-clipped by jumper.
Some BIOSes cannot handle disks larger than 32GB, so all larger
disks come with a jumper that makes the disk look like a 32GB disk.
The details depend on the disk manufacturer.
A lot of details can be found in
http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html#ss11.3

Re: Kernel & BIOS return differing head/sector geometries

[H. Peter Anvin]

Followup to:  <20030624013908.B1133@pclin040.win.tue.nl>
By author:    Andries Brouwer <aebr@win.tue.nl>
In newsgroup: linux.dev.kernel
> 
> Linux does not use the BIOS, and does not use CHS either, so geometry is
> totally and completely irrelevant to Linux.
> 

Actually, unless you have it "linear" or "lba32", LILO *does* use
CHS.  Unfortunately.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: Kernel & BIOS return differing head/sector geometries

[Werner Almesberger]

H. Peter Anvin wrote:
> Actually, unless you have it "linear" or "lba32", LILO *does* use
> CHS.  Unfortunately.

Distribution makers shouldn't be overly impressed by this default,
and just put "lba32" into any new lilo.conf they generate, or at
least offer the option to do so.

Keeping the old CHS default makes sure that people upgrading LILO
on an already configured (and probably quite ancient) system that
really needs CHS don't get a nasty surprise.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: Kernel & BIOS return differing head/sector geometries

[H. Peter Anvin]

Werner Almesberger wrote:
> H. Peter Anvin wrote:
> 
>>Actually, unless you have it "linear" or "lba32", LILO *does* use
>>CHS.  Unfortunately.
> 
> 
> Distribution makers shouldn't be overly impressed by this default,
> and just put "lba32" into any new lilo.conf they generate, or at
> least offer the option to do so.
> 
> Keeping the old CHS default makes sure that people upgrading LILO
> on an already configured (and probably quite ancient) system that
> really needs CHS don't get a nasty surprise.
> 

Presumably "linear", not "lba32".  I *presume* LILO has enough 
wherewithal to use EBIOS if it's available and fall back to CBIOS 
otherwise for at least one of these options.  I at least thought "lba32" 
would force EBIOS usage.

	-hpa

Re: Kernel & BIOS return differing head/sector geometries

[Werner Almesberger]

H. Peter Anvin wrote:
> Presumably "linear", not "lba32".  I *presume* LILO has enough 
> wherewithal to use EBIOS if it's available and fall back to CBIOS 
> otherwise for at least one of these options.  I at least thought "lba32" 
> would force EBIOS usage.

Yes, that seems to be the case. (All the LBA32 code is from John
Coffman. I've copied him in case he's interested in the thread.)
But you're still betting on the BIOS to either implement EDD
correctly, or at least to report that it doesn't support it.

Call me paranoid, but I wouldn't be at all surprised if there are
some BIOSes out there that get this wrong.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: Kernel & BIOS return differing head/sector geometries

[H. Peter Anvin]

Werner Almesberger wrote:
> H. Peter Anvin wrote:
> 
>>Presumably "linear", not "lba32".  I *presume* LILO has enough 
>>wherewithal to use EBIOS if it's available and fall back to CBIOS 
>>otherwise for at least one of these options.  I at least thought "lba32" 
>>would force EBIOS usage.
> 
> 
> Yes, that seems to be the case. (All the LBA32 code is from John
> Coffman. I've copied him in case he's interested in the thread.)
> But you're still betting on the BIOS to either implement EDD
> correctly, or at least to report that it doesn't support it.
> 
> Call me paranoid, but I wouldn't be at all surprised if there are
> some BIOSes out there that get this wrong.
> 

Well... it's somewhat unlikely given the sheer amount of things that 
would probably break.  The rule these days is that if it works with the 
particular versin of M$ that's currently shipping then it's good, but 
I'm pretty sure NTLOADER uses EDD.

	-hpa

Re: Kernel & BIOS return differing head/sector geometries

[John Coffman]

At 08:29 AM 06/24/2003, H. Peter Anvin wrote:
>Werner Almesberger wrote:
>>H. Peter Anvin wrote:
>>
>>>Presumably "linear", not "lba32".  I *presume* LILO has enough 
>>>wherewithal to use EBIOS if it's available and fall back to CBIOS 
>>>otherwise for at least one of these options.  I at least thought "lba32" 
>>>would force EBIOS usage.
>>
>>Yes, that seems to be the case. (All the LBA32 code is from John
>>Coffman. I've copied him in case he's interested in the thread.)
>>But you're still betting on the BIOS to either implement EDD
>>correctly, or at least to report that it doesn't support it.
>>Call me paranoid, but I wouldn't be at all surprised if there are
>>some BIOSes out there that get this wrong.
>
>Well... it's somewhat unlikely given the sheer amount of things that would 
>probably break.  The rule these days is that if it works with the 
>particular versin of M$ that's currently shipping then it's good, but I'm 
>pretty sure NTLOADER uses EDD.


Likewise GRUB.

Win 95 & 98 require EDD.

Win NT, 2000, and XP use it to boot (NTLDR).

--John



         PGP encrypted e-mail preferred (www.pgpi.com)
         My KeyID: 178A1C6B  (good until 31-Dec-2004)
         Keyserver at ldap://keyserver.pgp.com
         LILO links at http://freshmeat.net/projects/lilo