FreeBSD/FDisk geometry problems - SOLVED!

[Robert Eckardt]

Hi,

thank you for this analysis.
I ran into the same problem in that FreeBSD (fdisk) did not accept
the values the BIOS uses. I was able to complete the installation,
but when turning on my raid-1 FreeBSD recognized on next reboot all
of a sudden the BIOS values and was therefore unable to find the
filesystems.
Switching between two geometries depending on whether the raid is
on or off is unacceptable as in case of repair you want to atleast
find your data.

Besides, my MB is an EPoX 4GEA+ w/ HighPoint raid chip 372N and two
Maxtor 120G disks w/ geometries 14946/255/63 (ar1, BIOS) and
238216/16/63 (ad5,ad7).

I will try your workaround.
But I second the recommendation that a developer should have a look
into this problem -- atleast by allowing fdisk to accept manually
provided values.

Bye,
Robert

On Fri, 23 Jan 2004 22:26:59 -0800, Keith Kelly wrote
<...>
> My motherboard (MSI KT4 Ultra) BIOS calculates 19618/16/255 
> (80041440 total sectors).  FreeBSD's FDisk calculates 4982/255/63 
> (80035830 total sectors).  You'll notice that the total sector 
> count is not the same, and you may wonder why.  It's because of 
> rounding error and the fact that the calculations were done in 
> reverse.  In theory, either set of CHS values should work fine, 
> but the problem is that my BIOS picks one set and FDisk chooses 
> another set -- and FDisk refuses to accept and use the set my BIOS
> calculated.
<...>
> So, the problem is that FDisk makes *different* assumptions than my 
> BIOS does about what the sectors and heads values should be.  I ran 
<...>
> In the meantime, the workaround for anyone experiencing this problem 
> is to go into their BIOS and set the hard drive to "User" mode, and 
> manually enter the same C/H/S settings that FDisk calculated for the 
> drive.  Unfortunately, I think this means that if you have to 
> repartition and reformat the entire drive, since the BIOS will now 
> be addressing the drive using different C/H/S settings and will be 
> unable to read any partitions that were formatting using different 
> C/H/S addressing.  So while there is a workaround, it is far from an 
> ideal user experience.
> 
> - Keith F. Kelly