how does ignite know my disk should be c6t0d0? and the steps it goes through.

[Steve Post]

Simple ignite disaster recovery question.
When I recover with an ignite tape, it runs through a series of steps to rebuild the box.
It makes a mini OS.
It makes vg00.
It rebuilds /dev from scanning the hardware.
It makes other volume groups BOMB! The disks are in different spots than before.
Then it ....uh.....How DO I know?
Is it done? Is there more to go?

I know my disaster recovery of the box died. The scsi cables are connected different from when the ignite tape was made. As a result, disk c6t0d0 is now c4t0d0 (and lots of other disks). But the ignite tape didn't know it. It should. It's the one that changed a disk to c4t0d0, not me. I thought it would read off the volume group from the disk id on the disk instead of blissfully assuming it will be c6t0d0.

my questions:
1. What are the steps the ignite recovery tape goes through?
2. Is they a way to get past this error? That is, how can I interrupt ignite, find what the disk names are this MINUTE, and tweek unknown stuff to use the new device names instead of the ones at the point the tape was made?

[Court Campbell]

You could do a vgexport in preview mode with th shareable before you take an ignite image.

#vgexport -m /tmp/vgXX.map -p -s -v /dev/vgXX

I forget what exactly the shareable option puts in the map file, but when you go a vgimport it will scan the disks for some vg info on the disk. This is usually used in a cluster environment, but should work in this case since the device file are different. So after you ignite the sustem use

#vgimport -v -s -m /tmp/vgXX.map /dev/vgXX


Hope that helps.

[Steve Post]

Yeah that makes sense. But it's not me making the vgexport, it's ignite. If I went back in time, and performed this vgexport task, I still will have the recovery tape bomb out.

[Court Campbell]

Sorry, but I am somewhat confused. You successfully put the ignite image on the box, an I correct? You just don't any vg's other than vg00?

[Court Campbell]

Man, my typing is atrocious.

[Steve Post]

vg00 came back fine. Or did it? I had the word FAIL bannered on the screen after ignite was complete.

My question is "what are the steps the ignite recovery tape goes through?"
Why am I even asking? Because if I had that info I might be able to answer these questions:
Is ignite done?
Is ignite ok?
And what about my problem with the device instances changing on me?

My problem on device instances:
The tape drive at c4t0d0 became c6t0d0. And the tape array at c6t[0,1,2,3]d0 became c4t*d0. I wanted to somehow interrupt ignite to tell it....."Hey buddy, put the tape on c4, and put the array on c6."

If importing external volume groups is the very last step in the ignite process, I'm probably ok. I already imported vg01 back in using the c4t*d0 disks. But I don't know if it was the last step. So like I said, "What steps does ignite go through?"

[Marcel Burggraeve]

Quote :
As a result, disk c6t0d0 is now c4t0d0 (and lots of other disks). But the ignite tape didn't know it. It should. It's the one that changed a disk to c4t0d0, not me.

The addresses you mention are hardware addresses and are fixed to slots/interfaces/disks in the machine.
If you change SCSI cables around your system it IS actually you changing the disk to c4t0d0 and NOT ignite.

To solve these kind issues ignite has an option somewhere close to the start and before the actual recovery where you can interrupt the process and decide yourself where you want to restore and what you want to restore.

[Steve Post]

yep. I moved cables.

The instance numbers are *N*O*T* completely based on the hardware location. Far from it. They are based on the hardware and a point in time. I've seen it about 3 times here where I did NOT move cables and the instance numbers changed on me. This is because the box is setup years earlier and stuff has been installed and removed since then. Or the version of hpux looks at one type of hardware first before another? .......Oh, I just know I never trust the instance numbers from straight experience. Just like the third time I hit my foot with a bowling ball, I learn to hold the ball more carefully.

As far as an option to interrupt ignite? It's nice to know it exists. But I don't have to worry about it anymore. My error is not with vg00. It's with vg01. I opened a different forum entry on this because this one was too much about the instance numbers and nothing about the steps ignite goes through. Now I don't care.

[MarkSyder]

The default location for the OS disc is slot 6 - the highest priority SCSI slot (apart from the controller which is always slot 7).

It's a while since I used ignite, but iirc it tells you at an early stage which discs are in your system and asks you which one you want to use.

What server/WS are you using? On most of my boxes I can easily see which disc is in which slot.

Mark Syder (like the drink but spelt different)

[Steve Post]

what you called the slot, I call the t#. Thats the number after the t in /dev/dsk/c#t#d#.

server/WS? It is an rp3410.

When ignite asks which disk to use, it's asking me for which disk to build the vg00 boot disk on. That's easy. My problem...WAS...the external disk in vg01.

I've rebuilt the box a few times. That c# (yep the number in /dev/dsk/c#t#d#) has changed on me twice. I'll be more specific:
I boot off and install from the Foundation DVD Sep2006.
It says the array is at c4.
It do it again.
It says the array is at c6.
Whatever. I don't care anymore. I can get around it. It's not a big deal. This is closing now.