Device renumbering

[Simon Attwell_1]

Is there any way to force Tru64 to drop
the entire device database and rebuild it from scratch when you cant boot the OS?

i.e. is there are boot parameter or an SROM envar that can be set to force device detection?

[Hein van den Heuvel]

Device names _should_ not matter, but admittedly I have 'cleaned them up' at times.

Tru64 tries hard to REMEMBER all disks it has ever seen, which is great for real, physical disk. For HSZ/HSG/EVA 'virtual' disks that can come and go this may be a pain.
I tend to take care of those with hwmgr and dsfmgr, but admit to having blown away the device database once and made the system start fresh with 'dsk1'.

Check out the 'Hardware Management Guide' in the Tru64 Docset:

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARSFCATE/TITLE.HTM
Keep an eye open for: /etc/ddr_dbase
And check out: "1.5.3.6 Renumbering Device Special Files"

Do a man on "dn_setup" and "dsfmgr"

Go slowly.

Good luck,
Hein.

[Joris Denayer]

Here is an example on a single system without LSM. Afterwards, You will have some work for configuration of filedomains, swap, etc...
So, you better have a good sys_check to find back how everything was configured before.
-------------------
boot -fl s

mountroot

rm /etc/dec*
rm /etc/dfsc*
rm /etc/dc*
cd /cluster/members/member/dev/; ./MAKEDEV std
rm /cluster/members/member/etc/dfsl*
rm /cluster/members/member/.Booted
cd /devcies; rm -rf disk rdisk tape ntape cport dmapi changer


init 0
boot -fl s

mountroot
dn_setup -init
dsfmgr -K
dsfmgr -v # optionally -vF
hwmgr show scsi

bcheckrc
# fix if necessary links in /etc/fdmns

lmf reset
cdslinvchk # Fix problems NOW
init 3


have fun!

[Hein van den Heuvel]

fwiw... frivolous comment, but it got me slightly upset so I want to vent...

I just happened accross to the hpux/database
forum to find that the underlying problem for this question was first posted there.

Why it would posted in that forum is a total mistery to me, but that's not why I reply.

The original posting included MUCH more detailed information which would allow for a much more precise answer instead of wasting our volontueered time on wild speculations as to what the real problem might have been.

Oh well. Original post below.
Cheers,

Hein.

-------
Simon Attwell
October 15, 2003 12:53:35 PM GMT

We are moving some hardware around...
We have two ES40's a Model 1 and a Model 2.
The Model 1 was a 4 way 500Mhz EV67. It was configured in a cluster using a DEGPA-TA as the cluster interconnect (known to tru64 as alt2). We moved the CPUs Memory and SAN card into the Model 2 chassis with another DEGPA-TA installed.
Cant boot the system now.
If you boot -fl s -fi genvmunix the system
will get through device detection and number the DEGPA as alt3 so the CNX MGR frieks because the ics0 interface (alt2) is unavailable and panics the OS.
How can you force a device renumber from SROM ? At least that way I can get the box up
single user and figure out what needs to be where.
-----------------

[Ralf Puchner]

"Cloning" of V5.x systems by recreating the device database is not supported. The only way is described within "best practise" - by using the cloning mechanism (statement from engineering)

Using any unofficial scripts or howto's is at your own risk and will not be supported by HP (statement from support center).

[Ralf Puchner]

In case of the above facts why not deleting the member and recreate it via clu_add_member?

[Hein van den Heuvel]

Ralph wrote> In case of the above facts why
not deleting the member and recreate it via clu_add_member?

Absolutely. And I would have given that as first/only answer, but how could we know this is the aswer without the details from the other post I happened to run into? Hence my rant/flame.

Hein.

[Joris Denayer]

A) Hein, my frivolous post will certainly not help in case of a cluster-member. But, the first entry mentioned nothing about clustering.

B) Ralph, we are not talking about cloning here. With these comands, you can recreate a corrupted Hardware/Device database.

C) Supported or not, these commands saved me already several times a reinstallation of my workstation when I was doing experiments with the HW database.

D) This will be my last update in this forum. Sorry, no more frivolous attempts to help people.

Good Luck

[Hein van den Heuvel]

>> A) Hein, my frivolous post will certainly not help in case of a cluster-member. But, the first entry mentioned nothing about clustering.

Hello Joris... did you see my post as a flame to your reply? It certainly was not meant that way. It seemed to me that your reply held enough hints to get a reasonably competent system manahger going!

> D) This will be my last update in this forum. Sorry, no more frivolous attempts to help people.

Joris, again, anything I said? your reply seemed helpful and useful to me. Please continue!

Cheers,
Hein.

[Simon Attwell_1]

Joris,

Thanks for your response however as I mentioned in this particular instance you cannot boot the operating system even to single user.

I apologise that my original post went awry. I'm not sure how it managed to end up in HP/UX -> databases since I was browsing in Tru64 general and Trucluster forums.

Thankyou Hein for finding it and posting it here.

Now, the delete/add member would be one way to have gone about this. However how would you deal with a single node cluster ? (It was a cluster but the other member has been "repurposed" for some reason. )

The solution in this case however, was to move hardware around in PCI slots until the adapter showed up as alt2 which is pure dumb luck.

So the anwer to my question seems to be...

There is no way to force Tru64 to completely renumber devices from SROM.

[Ralf Puchner]

you can use the dsfmgr redirect command for example, but if you swapped the whole system this method doesn't work because you can not boot the system - so it is easier to delete/add the member again.

In case of a single member you have the original creation disk of the cluster. So a clu_create will do the job.

Another (but limited supported) way is to configure and use nearly configured standalone machines (all pci cards must match the source configuration). In this case you can use the redirect command to change the devices.

Swapping the bootdisk to a totally different machine is not supported, this is a kind of cloning (creating disk on machine A, using it on B). Our engineering team doesn't support this method - in case of a problem you will be on your own. So please use the official supported way within a mission critical environment. All the scripts/methods handed out for special customer issues to solve database problems contains the information "not supported" and "use at your own risk". Maybe it will work, but what happend if it will fail within a production environment? In this case it is too dangerous to play around.