Bug 51001 - IDA and CCISS fdisk does not have the selection for the "last cylinder"
IDA and CCISS fdisk does not have the selection for the "last cylinder"
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
7.3
i386 Linux
high Severity high
: ---
: ---
Assigned To: Elliot Lee
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-06 10:05 EDT by Bryan Leopard
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-17 11:21:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to add IOCTL (1.21 KB, patch)
2001-09-28 11:09 EDT, Arjan van de Ven
no flags Details | Diff

  None (edit)
Description Bryan Leopard 2001-08-06 10:05:52 EDT
RH ia64 7.2 Roswell.
when running fdisk /dev/ida/c...or /dev/cciss/c....
fdisk asks for first cylinder (default 1) but does not ask for the last 
cylinder.. and the partion will show both start and end on first 
cylinder...
Comment 1 Matt Wilson 2001-08-06 13:38:41 EDT
is this in the traditional util-linux fdisk?  if so, this bug should be moved to
be against util-linux.
Comment 2 Glen Foster 2001-08-06 18:28:55 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 3 Preston Brown 2001-08-15 10:17:27 EDT
This is the traditional util-linux fdisk.
Comment 4 Bill Nottingham 2001-08-15 13:04:56 EDT
Does the disk already have GPT partitions on it?
Comment 5 Bryan Leopard 2001-09-05 10:02:45 EDT
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.
Comment 6 Michael A. McLean 2001-09-05 15:58:31 EDT
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)
Comment 7 Michael A. McLean 2001-09-05 15:59:48 EDT
The same behavior occurs both in the fdisk during install (re0830.0) and with
the fdisk in util-linux after install.
Comment 8 Bryan Leopard 2001-09-05 16:05:27 EDT
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):         
Comment 9 Bill Nottingham 2001-09-26 17:35:27 EDT
This is a driver bug. Note the geometry.
Comment 10 charles.white 2001-09-26 17:51:20 EDT
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? 
Comment 11 charles.white 2001-09-27 10:04:22 EDT
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?
Comment 12 Arjan van de Ven 2001-09-28 10:34:43 EDT
HDIO_GETGEO_BIG appears to be missing in the cciss driver.......
Comment 13 Bryan Leopard 2001-09-28 11:06:06 EDT
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.
Comment 14 Arjan van de Ven 2001-09-28 11:09:51 EDT
Created attachment 32878 [details]
patch to add IOCTL
Comment 15 Arjan van de Ven 2001-09-28 11:13:29 EDT
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.
Comment 16 Arjan van de Ven 2001-09-28 12:05:58 EDT
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)
Comment 17 charles.white 2001-09-28 12:31:10 EDT
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. 
Comment 18 Bryan Leopard 2001-10-01 16:04:28 EDT
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.
Comment 19 Elliot Lee 2001-10-01 16:28:19 EDT
No, it's not fixed in enigma... It is fixed in pensacola and the ia64 tree, though.
Comment 20 Bryan Leopard 2001-10-17 11:21:24 EDT
This is fixed in the QA1009 iso images that we received.

Note You need to log in before you can comment on or make changes to this bug.