Alpha 4100 doesn't see disks anymore

[Michael Schulte zur Sur]

Hi,

I have a problem with a A4100, which panicked and after reboot doesn't see disks anymore. See decevent attachment. Any ideas?

thanks,

Michael

[Michael Schulte zur Sur]

Hi,

I can't believe it. System unavailable, backspace and attachment gone.

Michael

[Ralf Puchner]

this is only a busreset message. have you checked cabling internal and external?
If the disks are connected on the internal controller, check console parameters for termination.

[Pedro Albuquerque]

Hello.
Can you see the disks or the SCSI controller where those disks are attached in SRM console?

[Hein van den Heuvel]

I'm with Pedro, first make sure that the devices and adapters are properly visible at the console level. You know... show conf, show dev. A loose scsi cable, poorly seated drive coudl easily explain the panic and subsequent disk loss. If the disks are not visible at the console, I would normally re-seat everything. Unplug scsi cables, re-plug. Powerdown switches/controller - restart. Talk to the controller, ask it whether it still sees everything there is supposed to be. If you are not making progress then maybe you can describe us the console status, the adapters best you know, the cabling (length?!), the drives.
[You would not have an [SE] scsi cable that is a little over length, or over/under terminated and it 'happened' to work this long?
Good luck,
Hein.

[Michael Schulte zur Sur]

Hi,

the problem turned out to be a faulty disk, which blocked the bus. We replaced it, and then all the disks got a new disk device. I have renamed the disks but the disk group is gone. How can I restore that? Unfortunately no volsave made. Can I restore from tape and if, what do I need?

Thanks for any advice,

Michael

[Ralf Puchner]

if this is a mirrored lsm volume there should be no problem using the standard recovery procedure posted here in the forum several times.

If it is a striped volume the next step is to bring back the replaced disk into the current lsm configuration, recreating the advfs domain and restore from backup.

[Michael Schulte zur Sur]

Hi Ralf,

the disk group consisted of 3x2 mirrored disks, one of them with two subdisks. Plase point me to the thread with the solution. I must find a solution soon and so far I have only managed to recreate the disk group, but the volrecover does not give any result or error. Attached is the volprint of the disk group.

thanks,

Michael

[Michael Schulte zur Sur]

Hi,

finally I got LSM up and running again. I found out, that syscheck also creates a lsm configuration backup. It seem though, that I killed before the data with voldg init. Is my assumption correct?

thanks for all advice,

Michael

[Ralf Puchner]

Hi Michael,

you have not attached any file. If you need an urgent solution why not open a call within the support center instead of still waiting for an reply in this forum?

[Michael Schulte zur Sur]

Hi Ralf,

I can't believe it. I had to post twice because the first time I got a system unvalaible and when I hit backspace and posted again, the attachment was gone. So I posted it a second time with a remark and obviously it has been censored.

The problem is solved. The only question, I still have, is:
Does voldg init dg dsk1 dsk2 dsk destroy the advfs on the disks? If so, why isn't it more clearly described in the docs?

The reason, I tried to solve the problem here was, that we don't have support for this machine.

thanks

Michael

[Michael Schulte zur Sur]

Hi,

I am still wondering, why the names of the disks changed. The only thing, we did, that could cause it, was, that we exchanged two controllers for tapes in their slots, meaning the postion of the disk contoller stayed the same and as much as I know, the naming is dependent on the rank of a controller in it's pci segment. Are there controllers, which influence the numbering and others, which do not? One is a new and the other is an older narrow controller.

thanks for any insight,

Michael

[Ralf Puchner]

Michael,

attaching a new disk will lead to a new dsk-device, this will not happened if the disk is on an external storage controller and the unit is not recreated (so the WWID is untouched). But it is fairly easy to move the new dsk-name to the old one.

The advfs filesystem will survive if one of the lsm plexes of the mirror is still active. In case of a damaged disk, the plex containing the failed disk will be rendered inaccessible. After swapping the disk and reconfigure it for lsm use (voldiskadm is your friend to do the job during replacement) a simple volrecover will resync the previously failed plex with the active one. This can be all done online without interrupting filesystem activity, but it is important to use the correct commands to replace the disk.

btw. the procedure was described here in the forum:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=324509

or if voldiskadm is not your friend:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=211205

[Michael Schulte zur Sur]

Hi Ralf,

I would understand, when the replacement disk gets a new name, but all the disks got renamed from dsk2..dsk7 to dsk8..dsk13. This I can't understand. Also the diskgroup in question totally disappeard. The booting said something like can't autoimport(have no access to the machine). So I created the disk group with voldg init dg dsk....
Does this ruin the data on the disks?
So the commands won't work, because the disk group didn't exist.

got me?

thanks,

Michael

[Ralf Puchner · Accepted solution]

Michael,

if all disk was renamed than it seems the moving of the controller was the root cause (there are some config restrictions depending WWID and controllers). Why not renaming the devices to the old names, this solved the "new naming" problem.

The message of "autoimport" indicates a problem with config copies, hardware or is a follow on to the new disk names.

voldg init should not destroy the contents of the "data" partitions it only writes new admin/config informations on the disks. But the disks must be ordered the same way as before (e.g. disklabel must match).

In your case the right steps are:

1. fixing hardware problem
-> disks can be seen again

2. renaming the new dsk names to old names
-> leading to a working plex and filesystem

3. replacing disk using one of the 2 methods described in my previous postings.
-> second plex will be ready for resync

[Michael Schulte zur Sur]

Hi Ralf,

thanks for your thoughts.
It's becoming more clearly now. The disks got renamed, system couldn't autoimport, disk group got lost and maybe I did something unwise in the course of action. You told me, that reading docs is a good occupation and participating here in the forums I am learning to be quite efficient in that, even in cases, where I do not have a clue. ;-)
Though it still is sometimes frustrating to find the right doc.
As I wrote in another post, I was looking for the doc about cluster recovery. It was supposed to be in best practices, but I couldn't find it.

again thanks,

Michael

[Ralf Puchner]

Btw. if WWID of lsm disk changes (which is stored in private region of disk) then lsm may hang or rejects disk. Only possible fix is to remove disk from lsm control and add it back again (so private region will be updated).

[Joris Denayer]

Michael, Ralf


I discovered some similarities between both of you and the Schumacher boys.

- You share the same names
- One works for HP, the other not.
- They both want to be the best
- However, they cannot reply faster than you.
- ....

My suggestion: beware for crashes and have fun


Simply couldn't resist ;-)

Joris

[Michael Schulte zur Sur]

Hi Joris,

I laughed my head of. ;-)
In this case however Ralf is way ahead of Michael and Michael does not work for HP.
Ok, I promise, not to tailgate Ralf. ;-)

Michael

[Ralf Puchner]

I'm the one reading the documentation ;-)