Special files

[Didier Honore]

We are upgrading (it is a re-installation) our cluster with HP-UX 11.

On HP-UX 10.20, we had special files for several disks like:

c5t4d1

Now we have for the same device:

c3t4d1

So I think we will have some problems when we will want to do the vgimport to recreate our volume groups.

Why I do not have the same special files?

How to solve this problem?


Thanks

Didier

[CHRIS_ANORUO]

You can change the special files with this sed command:

cat specialfile | sed 's,/c5t4d1, i\ /c3t4d1,g' > newspecialfile.
Then later you can rename or move newspecialfile to specialfile.

[CHRIS_ANORUO]

You can change the special files with this sed command:

cat specialfile | sed 's,/c5t4d1, i\ /c3t4d1,g' > newspecialfile.
Please, make a copy/backup of your special files before changing them. ......................
There should be one front slash before the c's, I hope it appears.
I don't know what is happening to this posting and SSL.........

[Curtis Larson]

Why I do not have the same special files?
1)a system could have been upgraded with additional hardware over time.
2) the customer/owner could have made modifications, ie renaming/creating their own device files

I think your asking too much of a installation process to know what order the hardware was installed or what modifications were done in a previous lifetime.

But, still two installations on the same hardware can result in different device file names. This is because hp's process that automatically creates device files does so via polling the hardware. Which ever hardware responds first gets created first.

How to solve this problem?
you need to "map" the volume group's physical volumes to their hardware address from the old system. vgdisplay -v vgname to get the physical volumes then a lssf on the device name to get the hardware address. So you massage this information to get files that tell you the old information. ie vg01 has /dev/dsk/c1t2d0, etc and another that maps the device files to the hardware, ie /dev/dsk/c1t2d0 x/y/1.2.0
/dev/dsk/c1t3d0 x/y/1.3.0, etc

Now on your new system to a ioscan -FunC disk, massage this information to get a file that maps your new devices files to hardware addresses similar to what you created for your old system.

From this you can "map" your old device files to the new device files. ie old device file "a" corresponds to hardware address "A", hardware address "A" coresponds to new device file "b".

From here you can do many things. create your own device files, rename the ones already there or as I prefer to do just call your vgimport with the new device file names.

You already have to copy all your mapfiles anyway so what is a few more files going to hurt. And, the above can all be scripted to reduce human error on doing lookups on printouts. I wrote a script to do this, but that was 2 employers ago so you'll have to do your own, unless someone else has one for you.

[Ovidiu D. Raita]

You've already got the answer to ...why. Let me try to explain you what can be done to cleanly solve the issue:

You just have to export and import the vgs with -s option:
# vgexport -p -s -m vg1.map vg1
# vexport -p - s -m vg2.map vg2
etc

and then
# mkdir /dev/vg1
#mknod /dev/vg1/group c 64 0x010000 <- choose a unique minor, the same for both cluster nodes
#vgimport -s -m vg1.map vg1.map
... then the same for vg2, etc

This way the system will scan ( -s ) the available disks and match them with the vg information stored in the map file.

Then you have to get the cluster config and thenreaply the cluster because if the lock disk has a new device file.

[Tim Malnati]

The fact that device names have changed is not important to vgimport. The utility does need to know all the new device names that are involved and this is the reason why you must have them listed on the command line when you you invoke the process (don't worry about alternate links for now, they can be vgextended later). The map produced is to coordinate the actual logical volume names used perviously.

On systems HPUX 9.x and earlier, the hard disk device numbers were created based on the order when they were originally created. On HPUX 10.x and above the device number is determined by the actual hardware position of the device on the bus. Chris's comment remains true on tape devices though.

With all this said, there is no reason to attempt to fool with device designations and there is no need to plug a scsi cable into a specific location either. Attempting to switch them around (with sed or anything else) will only confuse the issue down the street when a CE comes in to diagnose a disk problem and does not find them attached in the appropriate places.