Bug 51001

is this in the traditional util-linux fdisk?  if so, this bug should be moved to
be against util-linux.

This defect is considered SHOULD-FIX for Fairfax.

This is the traditional util-linux fdisk.

Does the disk already have GPT partitions on it?

I am checking with my engineering to find the answer to your question.  Here is 
another statement from our cpqarray and cciss driver maintainer.

According to Charles White, a disk call "HDIO_GETGEO" returns correct value 
from driver.

We've reproduced this in the test lab with re0830.0 on the Compaq Proliant DL380.

Also, fdisk misreads pre-existing partition tables, showing only a single
partition starting and ending on 1.  Consider the following session, looking at
a freshly partitioned drive (done with disk druid).

[root@test95 root]# fdisk /dev/cciss/c0d2

Command (m for help): p

Disk /dev/cciss/c0d2: 1 heads, 17756160 sectors, 1 cylinders
Units = cylinders of 17756160 * 512 bytes

           Device Boot    Start       End    Blocks   Id  System
/dev/cciss/c0d2p1   *         1         1   1048544   82  Linux swap
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(0, 1, 1) logical=(0, 0, 33)
Partition 1 has different physical/logical endings:
     phys=(256, 254, 32) logical=(0, 0, 2097120)
Partition 1 does not end on cylinder boundary:
     phys=(256, 254, 32) should be (256, 0, 17756160)

The same behavior occurs both in the fdisk during install (re0830.0) and with
the fdisk in util-linux after install.

No, I see the exactly the same problem on RH IA-32 7.2. This is not a GPT 
issue. 

Following is the returned disk geomery from fdisk:

root@localhost]# fdisk /dev/ida/c0d0
Command (m for help): p

Disk /dev/ida/c0d0: 1 heads, 25108320 sectors, 1 cylinders
Units = cylinders of 25108320 * 512 bytes

         Device Boot    Start       End    Blocks   Id  System
/dev/ida/c0d0p1   *         1         1   4079984   8e  Linux LVM
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(0, 1, 1) logical=(0, 0, 33)
Partition 1 has different physical/logical endings:
     phys=(999, 254, 32) logical=(0, 0, 8160000)
Partition 1 does not end on cylinder boundary:
     phys=(999, 254, 32) should be (999, 0, 25108320)
/dev/ida/c0d0p2             1         1   4080000   8e  Linux LVM
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(1000, 0, 1) logical=(0, 0, 8160001)
Partition 2 has different physical/logical endings:
     phys=(1023, 254, 32) logical=(0, 0, 16320000)
Partition 2 does not end on cylinder boundary:
     phys=(1023, 254, 32) should be (1023, 0, 25108320)
/dev/ida/c0d0p3             1         1   4394160    5  Extended
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(1023, 254, 32) logical=(0, 0, 16320001)
Partition 3 has different physical/logical endings:
     phys=(1023, 254, 32) logical=(0, 0, 25108320)
Partition 3 does not end on cylinder boundary:
     phys=(1023, 254, 32) should be (1023, 0, 25108320)
/dev/ida/c0d0p5             1         1   4079984   83  Linux
/dev/ida/c0d0p6             1         1    314144   83  Linux

Command (m for help):         

This is a driver bug. Note the geometry.

I wrote a test program that does the "HDIO_GETGEO" ioctl, and the geometry 
returns correct value from the driver.  We have never seen this problem before 
with the driver.  Is there another IOCTL that your version of fdisk might be 
calling to get the geometry from the driver? 

I just had my QA run a test... Durring install, Disk Druid shows the correct 
geometry, FDISK does not...  

Is FDISK using a new IOCTL to get the geometry?

HDIO_GETGEO_BIG appears to be missing in the cciss driver.......

This has never been in the driver.  When did this change?  This change was 
never communicated to us.  We can make the change in the driver and I would 
like to see the updated driver in the enterprise release.

Created attachment 32878 [details]
patch to add IOCTL

HDIO_GETGEO_BIG is the kernel 2.4 style ioctl....
I don't know when fdisk started using it, I'd expect it to fall back to the
other ioctl if the new one isn't available... somehow it doesn't.

After checking the fdisk source: Definite bug in fdisk; patch with fix is passed
to our fdisk package maintainer.

(Note: it would be *nice* to support the BIG ioctl as well, because it has a
bigger datastructure -> can use a bigger disk, but this is not strictly required)

We will add this new ioctl to future versions of our array drivers.  

But what is the plan for RH 7.2?  Fdisk not working is a BIG issue. 

Was this patch that was created to add the IOCTL included in the enigma 
release?  I just need to know so that we can document to our customers.

No, it's not fixed in enigma... It is fixed in pensacola and the ia64 tree, though.

This is fixed in the QA1009 iso images that we received.