disk device files after Ignite restore

[Stephan Boumans]

Hi all,

We have several N-class systems connected to a SAN with EMC storage.
On every system once a week an Ignite tape is made to the build-in DDS drive.
Last week I encountered the following, quiet serious, problem. I had to restore
one of these systems with the Ignite tape. The restore itself went all OK, except
that all of the lan and even worse, the disk device files of the EMC LUN's had been
numbered different from the original situation. (the controller number)
There have been no hardware(-path) changes on the system.
I couldn't think of another solution than to edit the /etc/rc.config.d/netconf and re-import the LUN's.
With a few volumegroups and 60 LUN's with each 2 alternate paths the restore process
took way to long and the customer was NOT amused...

My question now is: How can I make sure the same device-file numbering is being used during
the Ignite restore?

[David Burgess]

I'm assuming that this happens when insf runs and recreates the device files. A simple option would be to write a script to delete whatever gets created and then run mknod to recreate them the way you wanted. Ok it's a bit of a hassle, but will save you time if you have the same problem again.

Other than that, script what you did to edit netconf (or copy from a known good source) and import the LUNS.

Regards,

Dave.

[Alzhy]

No guarantees really.. but to make it easier for you to rebuild your VG's after a restore, make it a habbit to have maps (HW/PCI Path to device) so you'll quickly be able to rebuild.

I maintain maps for my LAN connections as well as my tape and disks. For Volume Group information you, export your VG maps with the VGID for easier rebuilds/imports:

vgexport -s -p -m oradata.map /dev/oradata


HTH.

[Ryan McKlveen]

This has happened to me before as well. There is a patch specifically for this - the renumbering of instances - the patch name escapes me at the moment. This happened on our adoptive node in our MC/SG cluster - luckily it was not a production box, but like you - took WAY too long to recover like that. Sorry that I can't provide the patch number, but I'd think that by now downloading a newer version of ignite, that issue would be addressed.

[Bill Hassell · Accepted solution]

This has always been the case. When you installed your system for the first time (or used the factory installation), there were no external disks like the EMC and probably only the internal LAN card. The disks and LANs were added along with the drivers, etc and device files built. When Ignite/UX restores back to the hardware, the /dev directory is not copied but instead, the device files are built according to the installed hardware. Well, now the EMC disks are connected and unfortunately, internal disks are LAST on the list to have their device files created. Same with the LAN cards.

The internal controllers have the highest addressing values so insf installs them last. On the original system, there was only internal disks and LANs so instance numbers would be zero, but after installing with the EMC and other LAN cards present, the zero instance will be the first disk or LAN card seen at the LOWEST number I/O slot. The reason this occurs is that there is no way for Ignite/UX to know that it is installing on exactly the same box so no assumptions are made.

[John Gunnis]

Hi,

My name is John Gunnis and I am having
the same problem with my L2000. I have a thread active under 9000 named L2000.
I have 8 disk devices that are being created
differently. I changed all the devices to the correct ones but doing a vgimport says the the device is mot found. Do I need to reboot after changing the devices? Any help
would be great.

John Gunnis

[Stephan Boumans]

Hi John,

Normally you should not have to reboot.
When you do a "ioscan -fnC disk", is the
S/W State saying the disks are claimed?

Grtz Stephan

[Wesley Marsh]

I think Bill hit this one square on the head. Several weeks ago I Ignited on N4000 from another. It changed the device files to 0x030000 or something close. (These were the internal disks)... wreaked havock on lot of other stuff as well. No explaination was offered by HPRC. I can see how Ignite can't make assumptions, but to make it a useful recovery tool for large environments, it seems like a little tweaking might be in order.