1. Detail of this BUG
This bug is caused by the combination with fdisk and kernel-2.4.x.
The reason of it is the output format of /proc/partitions.
The output of /proc/partitions in kernel-2.4.x is like:
major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse
running use aveq
3 0 58605120 ide/host0/bus0/target0/lun0/disc 12652 30169 341554
133540 12047 36338 387360 621390 -2 9057990 25561902
3 1 14999008 ide/host0/bus0/target0/lun0/part1 0 0 0 0 0 0 0 0 0 0 0
3 2 1224720 ide/host0/bus0/target0/lun0/part2 0 0 0 0 0 0 0 0 0 0 0
3 3 14999040 ide/host0/bus0/target0/lun0/part3 12647 30130 341466
133440 12047 36338 387360 621390 0 106210 754830
3 4 27382320 ide/host0/bus0/target0/lun0/part4 0 0 0 0 0 0 0 0 0 0 0
on the other hand, the one in kernel-2.6.x is like:
major minor #blocks name
3 0 58605120 hda
3 1 14999008 hda1
3 2 1224720 hda2
3 3 14999040 hda3
3 4 27382320 hda4
The most important difference is the output of "name" column.
According to the result of "strace fdisk -l"(with 2.4.x kernel), it
tries
open("/dev/ide/host0/bus0/target0/lun0/disc", ...)
that results in "ENOENT", finally there is no output.
# The reason of the #192871 is the same maybe, id est, it is
# duplicated entry, IMHO.
2. Suggestion of solution
IMHO, it is hard to translate "ide/host0/...." to "hda". So, it is
suggested to use major/minor device number alternatively.
Those device numbers are able to be obtained from /proc/partitions.
If open("<device">) results in "ENOENT",
mknod("/tmp/<temporary(ungessable) device_name>",
... , <major/minor obtained /proc/partitions>)
can be done after that and then try open() again.
Needless to say, after all, the temporary device special file
must be unlink()ed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
