/proc/partitions showing wrong partitions
 

2.6.9 kernel.
Grub boot loader.

System boots fine, but when I cat /proc/partitions it only shows:

22 0 hdc


When you do an /sbin/sfdisk -l /dev/hdc it shows:

/dev/hdc1
/dev/hdc2
/dev/hdc3
/dev/hdc4

with all the other stuff sfdisk shows about cyl, head, sect.. etc..., I just didn't want to type it in.....

The problem. I try to mount /dev/hdc2 i get no such device or address.

Thinking that maybe the /dev/hdc2 wasn't there, but nope.. it's there.

So I think what my problem is has to do with kernel not seeing the paritition table right or something like that.

Any ideas on how to debug this would be great!!!

Thanks :cool:

netstv

Obviously this is ancient, but google pulled it up when I had this problem last week. So I'll put this here for the next sap.

Possible cause:
In my case the machines these disks were in were part of a managed cluster, an ugly script was mdadm -C 'ing a raid0 array on each boot. I don't know that this caused the problem, but I've never seen this problem anywhere else, and I've never seen another set-up that recreated the same raid array so often. :shrug:

Symptom:
Userspace seems mostly happy, believing the partitions exist. (fdisk behaves as described by OP, and will happily delete and recreate partitions.)
Kernel appears unaware of partions. /proc/partitions shows main device but no partitions, per the OP's description. blockdev, mount, raidstart report:
/dev/hdc1: No such device or address

Ugly data destroying solution:
I got these drives working again by overwriting the boot record and the first several hundred MB's with zeros:
$ dd if=/dev/zero of=/dev/hdc
(I killed this process after 3 or 4 minutes, you could certainly be more precise if it pleases you, eg:
$ dd if=/dev/zero of=/dev/hdc bs=1024 count=300 or some such.)

After that, I of course needed to repartition the disk, as it's part tables were nicely wiped clean. But at least the disk was usable again.