Bug 52013 - sfdisk needs to be rebuilt
Summary: sfdisk needs to be rebuilt
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: util-linux
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-18 18:44 UTC by Need Real Name
Modified: 2007-04-18 16:36 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-11-16 02:37:34 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-08-18 18:44:06 UTC
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

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 

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-
ock/xd.o: init_module: Operation not permitted
Aug 18 14:45:43 h0020781271b0 insmod: Hint: insmod errors can be caused by 
rect module parameters, including invalid IO or IRQ parameters
Aug 18 14:45:43 h0020781271b0 insmod: /lib/modules/2.4.3-
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 

Expected Results:

Additional Information:

Comment 1 Bob Staaf 2001-11-16 00:32:16 UTC
This appears to still be a problem in 7.2.  Any resolution in site?


Bob Staaf
Southern Web Services
Orlando, Fl

Comment 2 Elliot Lee 2001-11-16 02:37:27 UTC
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-16 02:45:30 UTC
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.



Comment 4 Elliot Lee 2001-11-16 02:54:28 UTC
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

Thanks much.

Comment 5 Bob Staaf 2001-11-16 14:10:10 UTC
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?


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