pvcreate cannot determine block size

[Mel Burslan]

At this oint it does not matter if you can kill the process or not. You will need a replacement drive.

First, try

kill 19428

more than likely it will not die but do not go with -9 right off the bat

if it is still there, then try -9 option

kill -9 19428

I have a sneaking suspicion that, this will not work either. If this is a hot swappable drive, replace it while the server is alive. At this point, your pvremove command, could receive the signal it is waiting fro, from the new and functional disk drive and can complete its running. If not, it is too early to tell what the next steps might be, but most probably pvchange and vgcfgrestore will be your path.

Out of curiosity, iehp.org ?=? Inland Empire Health Plan ? If so, you must almost be my neighbor :)

[Vishu]

yes, killing this PID wont kill the process if the associated disk is dead. Removing that disk/LUN may help.

and, hanging of your DD clearly saying that disk is faulty. So, need a new disk/LUN. Get the new disk/LUN to the server and then again try pvcreate on its raw device file.

[John Jimenez]

Yes I could not kill it. I am going to try removing the 200 gig disk. If this does not work, I am going to try and create the 127 gig that used to be there and see if I can get these commands finish.

[John Jimenez]

I unpresented and removed the 200 gig LUN. I then created the 127 gig one that used to be there and introduced that one back as c23t10d0. but the pvremove or the dd is not finishing. I tried killing them both again but no luck

disk 126 1/0/2/1/0.97.8.239.1.10.0 sdisk CLAIMED DEVICE DGC CX500WDR5
/dev/dsk/c23t10d0 /dev/rdsk/c23t10d0

[Vishu]

Well John,

it is your 127 Gig LUN. so dd command may take a lot of time. use diskinfo first. if it prints good, then use dd as

# dd if=/dev/rdsk/c23t10d0 of=/dev/null bs=1024k count=1000

and wait for few mins to complete it. and paste the output.

[Bill Hassell]

When you remove a disk (LUN), you must first make sure it is no longer a part of any volume group. Always use pvchange -a N /dev/dsk/whatever to deallocate it from any volume group, then remove it from the system with rmsf (NOTE: not rm). Use the command:

rmsf -H

or use the alternate form:

rmsf -a /dev/rdsk/whatever
rmsf -a /dev/dsk/whatever

Removing /dev files for disks using rm will create problems. You need to inform the OS about hardware changes. Now you can unpresent the LUN.

Also check ioscan for NO_HW:

ioscan -f

Look for NO_HW. Then remove those paths with rmsf -H

My guess is that there are some unconnected device files in /dev/dsk and rdsk:

lssf /dev/*dsk/* | grep "???"

The ??? flags device files that have no hardware path. Use rmsf -a to remove those files too.

[John Jimenez]

Hi Bill,

Yes before I got rid of the 127 gig LUN. I successfully removed the logical volume and volume group in SAM. I then successfully pvremoved c23t10d0 and rmsf -H all for paths.
I then ioscaned to make sure that the 4 paths were removed

I then created a new 200 gig LUN and introduced it as c23t10d0. I issued the insf command and the I/O scan showed up as "claimed". But when I did the PV create I got the error, but at least got the prompt back. But because I got the error I decided to go no further and pvremove it, and that is when it locked up.

[Vishu]

untless a disk is pvcreate, there is no need to pvremove that.

so, when you remove the device file with rmsf, have you run insf -e to get them back after presenting the LUN to server.

And, what about the current diskinfo and dd(with count) command output.

[John Jimenez]

Hi Ranju, After I removed pvremoved and rmsf the old 127 gig LUN. I unpresented it and destroyed it on the EMC. I then created a new 200 gig LUN. I ran ioscan, and then I ran insf not insf -e. But when I ran insf I got the following out put.

=> #insf
insf: Installing special files for sdisk instance 127 address 1/0/2/1/0.97.4.239.1.10.0
insf: Installing special files for sdisk instance 126 address 1/0/2/1/0.97.8.239.1.10.0
insf: Installing special files for sdisk instance 148 address 1/0/4/1/0.97.4.239.1.10.0
insf: Installing special files for sdisk instance 152 address 1/0/4/1/0.97.8.239.1.10.0

I then ioscaned it again and it showed claimed, but then when I pv created it here:

=> #pvcreate /dev/rdsk/c23t10d0
Warning: Cannot determine block size of Physical Volume "/dev/rdsk/c23t10d0".
Assuming a default value of 1024 bytes. Continuing.
pvcreate: IO error on Physical Volume device /dev/rdsk/c23t10d0: root@diamond.iehp.org:/>

Are you saying that a corrupted pvcreate never took place? and there was no need to pvremove?

[John Jimenez]

I just opened up a case with HP. The pvcreate and dd have been hung for almost 4 hours and the system still seems to be running normal. Those two processes do not seem to be taking up high CPU or disk utilization. I will update you with any new information from HP. I appreciate and welcome any further comments or possible solutions.