Reinstalling OS with EMC disks

[Global Server Operation]

I have a rp7410 running 11.11 OS. The customer data is on EMC disks. I am being asked to reinstall the OS to rule out that it is causing problems with the PeopleSoft Application.
What steps are involved in saving the customer data on the EMC disks. I was told just exporting a mapfile would do. Is this correct and how would I do this? This is my first time reinstalling an OS with EMC already configured. All replies will be welcomed and appreciated.?

[harry d brown jr]

I don't think I would just rely on saving the vg map using "vgexport", instead make sure you do a backup of the data first.

What kind of problems is PeoplePuke having? The first thing I would do is to bring the machine up to date with all of the HP recommended patches using the Custom Patch Manager under the "Maintenance and Support" area (then look under "patching").

live free or die
harry

[Ross Zubritski]

Hi,

Take a good full backup. Then vgexport -p -m mapfile /dev/vgblahblah -s.

Regards,

RZ

[Sridhar Bhaskarla · Accepted solution]

Hi,

Re-installing OS is a very bad idea. I would be the last one to attempt doing it just because the application is having issues. What kind of issues are you facing anyway?.

But I am aware of the politics at the work place.

There are two ways you can install.

1. Re-installing the same OS you have now. You can simply use make_tape_recovery to achieve this task.
2. Re-installing the OS from the latest CDs. This is tedious as you will have to reconfigure it to match the current OS configuration. This includes but not limited to, network, password/group, additional softwares, drivers, patches, kernel tuning etc.,

In either the case, I would suggest you to export the map files of your volume groups with various options and copy them to another server.

#vgexport -p -v -s -m /tmp/vgxx.s.map vgxx
#vgexport -p -v -m /tmp/vgxx.map -f /tmp/vgxx.disks vgxx

Repeat the above for all the VGs and copy /tmp/*.map files to another system. Once you reinstalled the OS, you would then copy them back and import the VGs.

#mkdir /dev/vgxx
#mknod /dev/vgxx/group c 64 0x0?0000 (? should be a unique number, ll /dev/*/group will list all the group files)
#vgimport -v -s /tmp/vgxx.s.map vgxx

The above will scan all the disks and then import the ones that correspond to vgxx.

#vgchange -a y vgxx
#mount -a (provided you synchronized the old /etc/fstab)

However, another way which is my choice would be to use vgxx.disks with vgxx.map file. You will need to modify vgxx.disks to match the disks on the new OS. You may have to change just "cx" entries. Once it is done.

#vgimport -v -m /tmp/vgxx.map -f /tmp/vgxx.disks vgxx


-Sri

[Michael Duthie]

Seems a bit of drastic action, have they ruled everything else out ?

I guess they mean fresh install rather than and ignite restore. You will also have to reinstall additional file sets e.g. Mirror/UX or Adv JFS, OS patches as well as the application.

Anyway here is the vgexport commands.

#vgexport -v -m vgXX.map -p vgXX

#mkdir /dev/vgXX
#mknod /dev/vgXX/group c 64 0x0?0000
#vgimport -v -m XX.map vgXX /dev/dsk.cXtXdX

[Rita C Workman]

Your volume group can be maintained by doing the vgexport. But I would do it using the -s option, because that will include the vgid as part of the vgexport, thus ensuring you will get the disk back on your vgimport. Then either copy these mapfiles (not vg00 though) to another system for safe keeping or off to a dat tape, BEFORE you start to reload O/S !
Rememember your talking rebuilding loading the O/S in between, and thus addresses will change, you may need that vgid info.

I use:
vgexport -pvs -m /etc/lvmconf/ /dev/

Then I get import with:
vgimport -vs -m /etc/lvmconf/ /dev/

Just a thought,
Rita

[Rita C Workman]

Oh one more thing...People Soft....I would ask for what their justification is for this request.

Just my 2cents,
Rita

[Global Server Operation]

This server is a new server since January 6 of this year. It is also current with the latest patches. It came from HP with the OS pre-installed. The OS is configured idendtical with the other server new server that came in , an rp5470 which has no problems. The Oracle DBA cannot get an answer from PeopleSoft what is causing their process scheduler to crash. More important she cannot give us any indications that it is the OS. So rather than push PeopleSoft for an answer she pushing for the OS to be reinstalled. I had talked to HP a few times, sent HP system information on both servers. They have reviewed it and found no problems. HP also said that, if someone can give us some indications of errors that may suggest it to be an OS problem, they will be happy to investigate. With out any information to go on they cannot help. The DBA says that they do not have any information on the error. I did state to the customer that I do not believe that we have an OS problem. But the DBA has made this happen.

[harry d brown jr]

Are the kernel parameters the same between the two machines?

Are the logical volumes the same sizes? Even /tmp and /var/tmp.

Is the peoplesoft task scheduler executing scripts that someone wrote? It's the first place to look.

live free or die
harry

[Michael Duthie]

The chances of a reinstall fixing your problem seem very remote to me. Better to look at the difference between the 2 systems. The 7410 probably has more CPUS & memory than the 5470. That may mean you have to increase some kernel parameters or increase swap.

[Global Server Operation]

Every one thanks for all of your replies. Your input has confirmed what I have been telling the customer all along. I am opposing this issue and have at least put a halt to this request. I am requesting a meeting and asking for documentation before I proceed with their request. Again thanks everyone. In case I end up reinstalling the OS, I will keep your replies in mind. I will assign points.