Sol_10 x86 5/08 disk label corruption (yes i have searched...)

Question

I am truly sorry if the following is going to be a "oh no not this again" issue.
I am having an issue with 3 of my disks having "primary label corrupt: using backup" issues. Here is what I have tried and what has happened thusfar:
first I tried format, which core dumped
# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
       0. c0d0 <drive type unknown>
          /pci@0,0/pci-ide@11/ide@0/cmdk@0,0
       1. c0d1 <drive type unknown>
          /pci@0,0/pci-ide@11/ide@0/cmdk@1,0
       2. c1d0 <drive type unknown>
          /pci@0,0/pci-ide@11/ide@1/cmdk@0,0
       3. c1d1 <DEFAULT cyl 30398 alt 2 hd 255 sec 63>
          /pci@0,0/pci-ide@11/ide@1/cmdk@1,0
       4. c3d0 <DEFAULT cyl 38910 alt 2 hd 255 sec 63>
          /pci@0,0/pci-ide@14,1/ide@1/cmdk@0,0
Specify disk (enter its number): 0
Segmentation Fault - core dumpedok, thats wierd (and it does it with the other "drive type unknown" disks as well"). So I looked around and found a patch for format on x86 with a revision just a bit newer than what I had (137022-01 came with the install, I tried 137022-02's format command), to no avail (same response).
I then tried fmthard to try and read the label, which responded with "disk must be labeled first"
so I thought, ok, I will just use one of the working labels as a start (4 of my 5 disks are identical, so I figured I could fix the 3 bad ones using an existing disk label)
so I used fmthard again to write a disklabel that I had copied from the one good disk:
{code}
# fmthard -i -n "" /dev/rdsk/c1d1s2 > /tmp/partmap
# fmthard -s /tmp/partmap -n "" /dev/rdsk/c0d0s2
fmthard: Partition 8 overlaps partition 2. Overlap is allowed
only on partition on the full disk partition).
fmthard: Partition 9 overlaps partition 2. Overlap is allowed
only on partition on the full disk partition).
expected one reserved partition, but found 0
{code}
which I guess is another way to spell failure, as I still can't read a disklabel from the drive.
prtvtoc also reports "invalid VTOC" on the drives in question.
I have also tried booting a linux live environment, and partitioning these drives with one big solaris (code 'bf') partition on each. this had no effect on the issue.
I would like to point out that this very system was running solaris 10 x86 5/08 with the exact same harddrives 1 week ago. I had to re-install after some momentary laps of reason made me try out linux on the machine. this shouldn't have done much, as these drives have at one point been used in solaris, freebsd, and linux during their lives, and they haven't had much to do anyway, so I am confident in their current condition.
My big question is: why have multiple versions of format failed me? and is there any other way to give a disk a brand new disk label? there is nothing on the drives, so I don't care what happens to the data.
thank you all in advance

Answer 1

thank you both for your responses.
you aren't going to believe this, but format now behaves! it seems as though after creating a zfs pool using the disks that crashed format, the disks now show up just fine under format, in fact format says:
Searching for disks...done
AVAILABLE DISK SELECTIONS:
       0. c0d0 <SAMSUNG-S09QJ1OA10134-0001-232.89GB>
          /pci@0,0/pci-ide@11/ide@0/cmdk@0,0
       1. c0d1 <WDC WD25-  WD-WCANKE28342-0001-232.89GB>
          /pci@0,0/pci-ide@11/ide@0/cmdk@1,0
       2. c1d0 <WDC WD25-  WD-WCANKE22707-0001-232.89GB>
          /pci@0,0/pci-ide@11/ide@1/cmdk@0,0
       3. c1d1 <SAMSUNG-S09QJ1LL50379-0001-232.89GB>
          /pci@0,0/pci-ide@11/ide@1/cmdk@1,0
       4. c3d0 <DEFAULT cyl 38910 alt 2 hd 255 sec 63>
          /pci@0,0/pci-ide@14,1/ide@1/cmdk@0,0
Specify disk (enter its number): 0
selecting c0d0
NO Alt slice
No defect list found
[disk formatted, no defect list found]
/dev/dsk/c0d0s0 is part of active ZFS pool pool. Please see zpool(1M).I am running 64-bit on an amd phenom 9550 based machine.
I am going to read through the zfs documents (ALL of them, not just the quick-starts) and see what it says about disk labels.
here is pstack's output on the core file of `format'
# pstack ./core
core './core' of 1013:  format
-----------------  lwp# 1 / thread# 1  --------------------
080626e1 c_disk   (8047560, 8047454, feffb818, 4, 806740e, 0) + 369
08060777 main     (1, 8047498, 80474a0) + 2e3
080547c6 ???????? (1, 80475c8, 0, 80475cf, 8047603, 8047618)
-----------------  lwp# 2 / thread# 2  --------------------
feeb5053 _door_return (0, 0, 0, 0) + 23
fec30d3d door_create_func (0) + 29
feeb3a81 _thr_setup (feab0200) + 4e
feeb3d70 _lwp_start (feab0200, 0, 0, febbeff8, feeb3d70, feab0200)
-----------------  lwp# 3 / thread# 3  --------------------
feeb3dcb __lwp_park (80c5c08, 80c5c18, 0) + b
feeae60e cond_wait_queue (80c5c08, 80c5c18, 0, 0) + 3b
feeaeb07 _cond_wait (80c5c08, 80c5c18) + 66
feeaeb49 cond_wait (80c5c08, 80c5c18) + 21
fed82bc8 subscriber_event_handler (8091e00) + 3f
feeb3a81 _thr_setup (feab0a00) + 4e
feeb3d70 _lwp_start (feab0a00, 0, 0, feaaeff8, feeb3d70, feab0a00)