Bug 52013 - sfdisk needs to be rebuilt
sfdisk needs to be rebuilt
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-18 14:44 EDT by Need Real Name
Modified: 2007-04-18 12:36 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-08-18 14:44:06 EDT
Description of Problem:
sfdisk -l doesn't work with the 2.4 kernel.  It seems to be trying to
open xd.o from the old location at
/lib/modules/2.4.3-12smp/kernel/drivers/block/xd.o

Version-Release number of selected component (if applicable):
RedHat 7.1, kernel-smp-2.4.3-12, util-linux-2.10s-13.7

How Reproducible:
100% (bad printout and errors in /var/log/messages

Steps to Reproduce:
1. sfdisk -l 
2. 
3. 

Actual Results:
                start: (c,h,s) expected (1023,254,63) found (1023,1,1)

and (in /var/log/messages)

Aug 18 14:45:43 h0020781271b0 insmod: /lib/modules/2.4.3-
12smp/kernel/drivers/bl
ock/xd.o: init_module: Operation not permitted
Aug 18 14:45:43 h0020781271b0 insmod: Hint: insmod errors can be caused by 
incor
rect module parameters, including invalid IO or IRQ parameters
Aug 18 14:45:43 h0020781271b0 insmod: /lib/modules/2.4.3-
12smp/kernel/drivers/bl
ock/xd.o: insmod block-major-13 failed
Aug 18 14:45:43 h0020781271b0 kernel: XD: Loaded as a module.
Aug 18 14:45:43 h0020781271b0 kernel: Trying to free nonexistent resource 
<00000
320-00000323>

Expected Results:


Additional Information:
Comment 1 Bob Staaf 2001-11-15 19:32:16 EST
This appears to still be a problem in 7.2.  Any resolution in site?

Thanks

Bob Staaf
Southern Web Services
Orlando, Fl
Comment 2 Elliot Lee 2001-11-15 21:37:27 EST
This appears to be just sfdisk trying to open all the possible block devices to
find out if they have any partition tables to be read. Unfortunately sfdisk is
not as bright enough to read /proc/partitions, unlike fdisk, and so when it is
trying to open all these devices the kernel loads the 'xd' module to try and
satisfy one of the attempts. There is no real error here as far as I can see.

I suggest using 'fdisk -l' instead if 'sfdisk -l' causes actual problems (and if
sfdisk -l causes actual problems, it's probably because of a bug in the kernel...)

Hope this explains what is being seen...
Comment 3 Bob Staaf 2001-11-15 21:45:30 EST
The reason I am using sfdisk is that "fdisk -l" does not return anything.  It 
doesn't appear to work with my scsi raid array whereas sfdisk does.

Thanks

Bob
Comment 4 Elliot Lee 2001-11-15 21:54:28 EST
Hmm, can you check for an existing bug against util-linux/fdisk in this regards,
and either add to that bug or file a new bug with the contents of your
/proc/partitions?

Thanks much.
Comment 5 Bob Staaf 2001-11-16 09:10:10 EST
I have looked at fdisk closer and it appears I was assuming it functioned the 
same way as sfidsk.  It looks now as though fdisk does not probe for devices as 
sfdisk does?  On the other servers I have there is only one volume that my 
partitions are on and fdisk -l works fine but, on the VA box there are 3 
volumes and in that case it seems you have to specify which volume you want 
partition information from.  If you specify a volume by using "fdisk -l -
u /dev/rd/c0d0" it works fine.  Is this normal behavior for fdisk?

Thanks

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