vPar, 11i v3, changing lan instance number problem

[PW HP-UX Support Team]

Howdy all!


I have created an infile that looks like:

1/0/1/1/0/6/0 lan 0
1/0/1/1/0/6/1 lan 1
1/0/2/1/0 lan 2
1/0/2/1/1 lan 3

I have then done:
# mv /stand/ioconfig /stand/ioconfig.sav
# mv /etc/ioconfig /etc/ioconfig.sav
# shutdown -ry 0

The system then rebooted to the expected ioinitrc prompt:

ioinit: Unable to restore /stand/ioconfig from /etc/ioconfig. The file
/stand/ioconfig can be restored from backup or either from
/stand/ioconfig.lkg or /etc/ioconfig.lkg.
If /stand/ioconfig cannot be restored, use "/sbin/ioinit -c"
to recreate it from the kernel.
If the file /stand/ioconfig has been restored from
/stand/ioconfig.lkg or /etc/ioconfig.lkg, it is necessory to
copy the same file to /etc/ioconfig and reboot the system
immediately.
When finished reboot the system immediately without proceeding further.
(in ioinitrc)# /sbin/ioinit -c
(in ioinitrc)# /sbin/ioinit -f /infile -r
ioinit: Instance number 0 already exists for class lan.
Line 1. 1/0/1/1/0/6/0 lan 0
(in ioinitrc)#

And this is where I get stuck. I thought that by removing the ioconfig files, that I would not have this "Instance number X already exists" error.

How do I get around this? The problem is my lan cards came up as lan4, lan5, lan6 and lan7. Obviously I want lan0 etc....

Thanks in advance.

[Duncan Edmonstone]

well the "ioinit -c" is re-creating all the instances starting at zero anyway, so that may be enough. It at least explains why you can't thjen renumber.

Of course you will probably find all your disk device instances have changed allthough if you're on the absolute latest version of 11iv3 this might not be a problem.

There used to be a documented process to do this in the support database, but I can't find it now...

HTH

Duncan

[PW HP-UX Support Team]

That documented process is the one I'm using. There's the one that may work (didn't work), and then there's this one that is supposed to work. (didn't work either).

....sigh. And yes, this is 0809 release of 11i v3.

[Duncan Edmonstone]

Reinstate your old ioconfig files and reboot back to multiu-user mode then:

ioscan -kf | grep -e INTERFACE -e DEVICE | awk '{printf "%s %s %s\n",$3,$1,$2}' > /infile

Then edit the infile and change your lan instance numbers.

Then:

# mv /stand/ioconfig /stand/ioconfig.sav
# mv /etc/ioconfig /etc/ioconfig.sav
# shutdown -ry 0

The system then rebooted to the expected ioinitrc prompt:

ioinit: Unable to restore /stand/ioconfig from /etc/ioconfig. The file
/stand/ioconfig can be restored from backup or either from
/stand/ioconfig.lkg or /etc/ioconfig.lkg.
If /stand/ioconfig cannot be restored, use "/sbin/ioinit -c"
to recreate it from the kernel.
If the file /stand/ioconfig has been restored from
/stand/ioconfig.lkg or /etc/ioconfig.lkg, it is necessory to
copy the same file to /etc/ioconfig and reboot the system
immediately.
When finished reboot the system immediately without proceeding further.
(in ioinitrc)#
(in ioinitrc)# /sbin/ioinit -f /infile -r

Note you *do not* run ioinit -c

HTH

Duncan

[PW HP-UX Support Team]

Hate to sound like a broken record, but same error.

When finished reboot the system immediately without proceeding further.
(in ioinitrc)# /sbin/ioinit -f /infile -r
ioinit: Instance number 0 already exists for class lan.
Line 1. 1/0/1/1/0/6/0 lan 0
(in ioinitrc)#

Here's a question. What happens if I do a:

# rmsf -H 1/0/1/1/0/6/0

and reboot? Will insf rebuild the devices properly on reboot?

TIA

[PW HP-UX Support Team]

For the record, this process works fine in nPar mode. But fails in vPars.

So...... Maybe there's a doc that I'm not aware of that has the vPar version of this process?

[Duncan Edmonstone]

another way of doing this I've used in the past is via a 2 stage processs where you "move the devices to new addresses, then move them back where you want... so in shortened form you would do this:

1/0/1/1/0/6/0 lan 50
1/0/1/1/0/6/1 lan 51
1/0/2/1/0 lan 52
1/0/2/1/1 lan 53

# /sbin/ioinit -f /infile -r

After reboot you should come back up with lan50, lan51 etc...

Then repeat with

1/0/1/1/0/6/0 lan 0
1/0/1/1/0/6/1 lan 1
1/0/2/1/0 lan 2
1/0/2/1/1 lan 3

# /sbin/ioinit -f /infile -r

worth a try I guess...

HTH

Duncan

[PW HP-UX Support Team]

Duncan, this is the first time that I have ever had ioinit -f /.... work in a vPar. When I say work, I managed to change the lan instances to 10,11,12 and 13. But now I can't get them to lan0,lan1 etc... It won't let me. In fact ioinit fails, and I have to re-move /stand/ioconfig.sav back to ioconfig get it to boot.

Surely I can't be the only person on the planet who has run into this problem? I honestly have no idea how these 2 vPars got messed up. I've built over 40 vPars in the last 2 months with no problem. This one is over a large slow WAN, and I likley can't ignite it to redo this mess.

[Torsten.]

Why messed up?

This could be totally normal and IMHO this is no problem at all.

If you install the initial nPar all devices get the device files and instances. If you create the vPars now and let's say lan2, lan14 and lan 23 stay within this vPar the names remain.

Is this really a problem?

[PW HP-UX Support Team]

I ignite off of the virgin system and it creates the nPar. Once booted, I configure 2 vpars, vparcreate etc.... The first vPar is essentially the nPar cut in half, becomes vpar0. lan0, lan1 etc.... are all fine in vpar0. I reboot in vPar mode, vparboot -p ...-I and ignite the 2nd vPar. It's lan cards always are setup correctly, lan0, lan1, lan2 and lan3. Perfect. Have done tons of vPars this way. (I build the drives here, and ship them out across the country, have them installed and work my magic from the MP).

For whatever reason this one system came up with both vPars having the nics in lan4,5,6,7. The vPars are deployed in a standard way for the support team. That is the problem. And I *should* be able to change this. And I should be able to explain how this happened. But it's never happened to me before. I would love to know how this happened.

What's wrong with it? Lots. We have 4 nics. Each nic goes off to its own happy subnet. There are oceans of static routes for these systems to work. Our support team doesn't want to have to go onto a system and try to figure out why one route / NAT or whatever isn't working with different nics. We have a standard for each nic, which maps to its respective network. Simplifies it. So.... I have one system out of the whole batch that looks goofy. I can't ignite it to rebuild the vPar cause it's on the other side of the country.

I guess I will open a ticket with HP.

Cheers