Operating System - HP-UX
1748159 Members
4040 Online
108758 Solutions
New Discussion юеВ

Re: Not able to remove device file for internal removed disk.

 
SOLVED
Go to solution
Turgay Cavdar
Honored Contributor

Re: Not able to remove device file for internal removed disk.

Kavita Poonia
Regular Advisor

Re: Not able to remove device file for internal removed disk.

So what csn be the solution now ?
Torsten.
Acclaimed Contributor

Re: Not able to remove device file for internal removed disk.

What other steps are done so far (LVM related)?

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Kuntal Gupta
Frequent Advisor

Re: Not able to remove device file for internal removed disk.

Remove the device files for the disk and then try rmsf -v -H ,50% chance.

I have also faced the same prob few times.
Restart will sort out the issue.

But the main prob is that if it is showing NO_HW against the disk by ioscan o/p, in that case if you add a dis /present a LUN from SAN it would not recognize.


Kuntal
jai123
Visitor

Re: Not able to remove device file for internal removed disk.

Below support doc will help you..

 

HP-UX 11i v3 - How to Remove Invalid Multiple Agile Device Files for a Single LUN
Information
Multiple agile DSFs seems to be assigned to the same LUN:
# ioscan -m dsf Persistent DSF           Legacy DSF(s) ======================================== ... /dev/rdisk/disk416       /dev/rdsk/c0t2d0s1 /dev/rdisk/disk417       /dev/rdsk/c0t2d0s2 /dev/rdisk/disk418       /dev/rdsk/c0t2d0s3 /dev/rdisk/disk617       /dev/rdsk/c0t2d0 /dev/rdisk/disk617_p1    /dev/rdsk/c0t2d0s1 /dev/rdisk/disk617_p2    /dev/rdsk/c0t2d0s2 /dev/rdisk/disk617_p3    /dev/rdsk/c0t2d0s3 ...
The same problem shows up in the -fnN ioscan options.
Details
It has been observed that in most cases, this issue occurs after an Ignite-UX cloning process. The problem is not with Ignite-UX, the reason for this issue is very simple: The agile DSFs have duplicated major and minor numbers.
When the original image is cloned, the old device files are still there but are no longer valid device files on the new system. When the new system is installed, these old device files become just simple (stale) files located at /dev/x , OS has not registered and consequently the minor numbers are available in the new system for any new LUN that is detected.
The invalid device files might be usable, but should not be used. If for any reason the disk or tape device files are lost, can be easily recreated with insf -e , but the invalid device files would not be recreated.
Following the example above, the next output shows the duplicated minor numbers (0x######):
From /dev/disk: brw-r-----   1 bin        sys          3 0x000009 Feb  3 21:15 /dev/disk/disk416 brw-r-----   1 bin        sys          3 0x00000a Feb  3 21:15 /dev/disk/disk417 brw-r-----   1 bin        sys          3 0x00000b Feb  3 21:15 /dev/disk/disk418 ... brw-r-----   1 bin        sys          3 0x000009 Jun  7 13:36 /dev/disk/disk617_p1 brw-r-----   1 bin        sys          3 0x00000a Jun  5 23:42 /dev/disk/disk617_p2 brw-r-----   1 bin        sys          3 0x00000b Jun  5 23:42 /dev/disk/disk617_p3 From /dev/rdisk: crw-r-----   1 bin        sys         22 0x000009 Feb  3 21:15 /dev/rdisk/disk416 crw-r-----   1 bin        sys         22 0x00000a Feb  3 21:15 /dev/rdisk/disk417 crw-r-----   1 bin        sys         22 0x00000b Feb  3 21:15 /dev/rdisk/disk418 ... crw-r-----   1 bin        sys         22 0x000009 Jun  7 13:35 /dev/rdisk/disk617_p1 crw-r-----   1 bin        sys         22 0x00000a Jun  7 16:46 /dev/rdisk/disk617_p2 crw-r-----   1 bin        sys         22 0x00000b Jun  7 14:06 /dev/rdisk/disk617_p3
From this information, it is not really possible to determine which file is correct and which one is not. One could use the date or a simple analysis such as that the disk#_p# device should at least have the same disk# portion making disk617 the good file in this case.
The easiest way to fix this problem is to let the OS remove the invalid files for you. A new -x options has been added to the rmsf command on 11i v3 allowing to run this task automatically. It is recommended to run this task in early stages of the server deployment process, if not it might be possible that some of the invalid (not registered) device files are already in use by LVM in data VGs.
# rmsf -x
Another common scenario for this command is a storage reconfiguration. In that case. All the device files are known to be valid, but due to the reconfiguration and as a good practice, the old devices need to be removed. The administrator may accomplish this task by removing one file at a time or just using the rmsf with the -x option.
The execution of the above command should fix most of the cases explained in this article. This article already mentioned in http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=3367813&prodTypeId=18964&objectID=c02254626

 

Regards ,

 

jay