Anaconda, parted, and geometry

[Robert L Cochran]

I wonder -- if this is an IDE hard drive, do the jumpers on the drive
allow you to change the default geometry? It seems to me that BIOS
interrupt 13h would need to know this same information and it may be
there is a BIOS setting for it too. But I bet the hard drive itself may
let you set the geometry with a jumper or two. So I'm suggesting you
first check the BIOS settings and if need be de-install the hard drive
check for this and see if you can rearrange the jumpering to allow a
more vanilla 255/63/63 CHS arrangement.

Be real careful to remember exactly where pin 1 is if this is an IDE
drive. And be real tender with those drive pins. Don't bend one into a
noodle shape. That has happened to me.

Bob Cochran



Chuck Anderson wrote:
> For reasons known only to IBM, Thinkpads have been shipping with hard 
> disks partitioned with a geometry of 240 heads, 63 sectors.  Even my 
> brand shiny new T61 does this.  However, since Linux has stopped 
> asking the BIOS what geometry to use, it now defaults to 255 heads, 63 
> sectors.  Further, it isn't clear to me how to override Linux's choice 
> of hdd geometry in the new world order of libata, nor should that be 
> necessary in the normal case to get a sane partition table IMO.
>
> Why should I care, you ask?  Isn't disk geometry an anachronism from 
> the days of DOS?  Well, yes, but the problem is for whatever reason, 
> not everything ignores geometry...
>
> For example, Anaconda/parted likes to force cylinder alignment.  
> Windows uses the BIOS/partition table geometry which may have a 
> different idea about where cylinders begin and end.  The reasons for 
> these behaviors aren't entirely clear to me.
>
> This leads to /really/ weird partitioning when different programs with 
> different ideas of the geometry add/delete partitions from the disk, 
> such as strange gaps of free space when you create a new partition in 
> Anaconda, or situations where some partition table entries are stored 
> using one set of C,H,S values, and others are using a different set. 
> This of course also causes programs like "fdisk" and "sfdisk" to 
> complain about cylinder boundaries and C,H,S values being incorrect.
>
> What to do about it?  Can't we all agree to use the same geometry when 
> dealing with the partition table?  When Anaconda/parted reads the 
> table, shouldn't it deduce the most fitting C,H,S values to use for 
> cylinder alignment and writing out new entries?  Or shouldn't it ask 
> the BIOS what to use, since that seems to be what Windows does?
>
> I used to work around issues like this by using fdisk in VT2 to 
> partition things how I like, and then let Anaconda install to those.  
> However, it now seems impossible to create a new encrypted LVM PV 
> unless you let Anaconda's parted create the PV partition too.  Perhaps 
> that could be improved upon.
>
> I remember a bit of the fiasco of "I can't boot Windows anymore" that 
> happened a few years ago, but I don't know what the outcome/solution 
> was.  Did the Linux kernel and Anaconda just punt the whole issue of 
> trying to match geometries and let things fall as they may?
>
> Whatever was done, it just seems wrong and dirty to end up with a disk 
> that has a schizophrenic idea of what geometry to use for its 
> different partitions.
>
> --Chuck, who had to create a spreadsheet just to figure out what 
> happend to his partition table...
>
>