WD10EARS linux not creating special devices for partions

WD Internal Drives Desktop & Mobile Drives
1

Mandriva 2010.0 (kernel 2.6.31.12) with a new WD10EARS as disk /dev/sdb.  It was partitioned with fdisk, set “u” to get it to show in blocks, and set up the partitions this way:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xcd895c82

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          64     1044223      522080   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdb2         1044288  1953525167   976240440    5  Extended
/dev/sdb5         1044351     9432958     4194304   82  Linux swap / Solaris
/dev/sdb6         9433022   109433021    50000000   83  Linux
/dev/sdb7       109433085  1953525167   922046041+  83  Linux

wrote the partition table with “w” and it created /dev/sdb1 and so forth.  Put file systems in them with:

mkfs -t ext4 /dev/sdb1

and so forth.  Could read/write files.  Everything looked good.

But it didn’t stay good.

Reboot and - /dev/sdb1 etc. are all gone, only /dev/sdb is there.  No such problem for /dev/sda1 etc. (old Seagate 40GB disk.)  Went into fdisk, “u”, “w”, and bingo, the special devices were created.

So it looks like udev has some issue with this disk.    There is nothing in dmesg to show what went wrong, the lines for sda are equivalent to those for sdb.  Here is sda, for which the special devices are created:

ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-6: ST340014AS, 8.12, max UDMA/133
ata1.00: 78125000 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access     ATA      ST340014AS       8.12 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 78125000 512-byte logical blocks: (40.0 GB/37.2 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
 sda: sda1 sda2 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk

and here is sdb, where they are not:

ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ATA-8: WDC WD10EARS-00Y5B1, 80.00A80, max UDMA/133
ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/100
scsi 1:0:0:0: Direct-Access     ATA      WDC WD10EARS-00Y 80.0 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
 sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 >
sd 1:0:0:0: [sdb] Attached SCSI disk

Nothing jumps out at me to indicate a problem.

Anybody know how to fix this???  I want to make the WD10EARS the system (and only) disk, but this is a bit of a showstopper.

Thanks.

2

Doubt this is it, but somebody may ask - the SATA controller is a SiI 3114 on the motherboard with the 5.4.0.3 firmware. 

3

My understanding is that the WD10EARS is an Advanced Format drive which has a sector size of 4096 bytes. AISI, your first partition starts at LBA 64 rather than the more traditional LBA 63, probably to align it with the 4K sector size of the WD10EARS. Why then would the drive be partitioned with a block size of 1K (= 2 x 512-byte sectors)? Furthermore, shouldn’t each LBA be 4KB, not 512 bytes?

I’m sorry if the above appears ignorant, but I have no experience with Advanced Format drives.

4

fdisk displays start/end in units of sectors (512 bytes),and the extent of each partitioin in blocks (1024 bytes).  That is just how it formats the partition table into a text form so that we can read it, I don’t know what the “raw” units are in the actual partition table, but extpect they don’t change no matter what units fdisk shows us.

5

It looks like the problem had to do with this disk having been part of a RAID array at one point.  (I’m not sure if it was, but there is a good chance it was.)  Wiping the first 1MB of the disk and repartitiioning, then rebooting twice let the special devices be created.  At the first reboot they were not, but there may have been some history stored on the system disk (not the disk in question) which caused that to interfere even though the disk no longer called for it.