How to recover TRU64 system after system crash due to LSM script

[Srikanth Arunachalam]

Hi,

I have created LSM script to create volume, plex, sub-disk. Due to error in the script the system got crashed. The server is in TRU64 cluster pair. Please advice the steps to recover the system due to failures of LSM. The kind of error is due to incorrect information of offset length and other is due to wrong plex name.

Actually I was performing the following function.
(1) The cluster service was up and running.
(2) initialized new disk to diskgroup different from that of rootdg.
(3) created volume, plex, sub-disk on the new disk that is part of the applicationdg.

please advice.

[Han Pilmeyer]

What is it that is actually failing now? What you wrote indicates that rootdg was not affected, so the cluster should still boot.

Are the cluster root disks on LSM?

What version are you running (including patch kit)?

[Srikanth Arunachalam]

Hi Han,

Thanks for your response. The system crashed and the console prompt ">>>" kepts displaying information about server panic, unable to form cluster.

The rootdg is independent of application. The application is actually loaded on omcdg disk group. The problem is only on omcdg disk group. No cluster root disk is not in LSM.

TruCluster Server V5.1B (Rev. 1029)
Compaq Tru64 UNIX V5.1B (Rev. 2650.

The action taken to resolve where following:-(1) Removed nodes from cluster
(2) rebooted with single-user mode
(3) ran bcheckrc
(4) ran volrestore to recover based on the volsave performed earlier.
(5) restarted the system in operation mode.

Although it worked, I would like to know if the procedure is correct for restoring the non-rootdg disk group.

[Han Pilmeyer]

Yes, volsave is the correct command to restore the LSM metadata back to the point of the last volsave.

I guess the system paniced when it attempted to load LSM? I think we may have fixes for something similar. Which is why I asked for the patch information. The data you supplied is too generic. "dupatch -track -type kit" should give the correct patch kit information.

[Srikanth Arunachalam]

Hi Han,

The following is the output of dupatch -track -type kit in our system.

T64V51BB24AS0003-20030929 OSF540

Can you please suggest alternate method of fixing this server panic. Detailed steps for restoration is really appreciated.

Thanks,
Srikanth

[Han Pilmeyer · Accepted solution]

You are at V5.1B PK3 (BL24). The latest is V5.1B SP05 (BL26). So you are 2 patch kits behind. There were a lot of LSM fixes in those patch kits, but without more details I'm not sure if exactly your problem was addressed.

If the panic was in the LSM startup, it may have been possible to disable LSM and boot the cluster that way. This would have allowed for starting LSM (vold) in debug mode and getting more details about the problem.

[Srikanth Arunachalam]

Thanks Han for your response. We will look for the information and update our system accordingly.

[Srikanth Arunachalam]

Hi Han,

Can you please give me the exact ECO name, is that T64KIT1000494-V51BB26-E-20060404
you are refering to.

Thanks,
Srikanth

[Han Pilmeyer]

No, it is: T64V51BB26AS0005-20050502

The one that you found is a patch (ERP most likely) on top of BL26. It would be best to install the ERP's for BL26 too.

[Srikanth Arunachalam]

Hi Han,

Thanks for all your response. Can you exactly take me to the pointer that suggests that the patch is required to alleviate the problems occuring due to LSM. I need to do this to advocate for my proposal to install the patches.

Regards,
Sri