vPar no more boot

[Eric SAUBIGNAC]

Bad news,

everything is OK from SAN point of view. And if the switch ports were seen at 4Gb, that's only because there configured autoneg and not up. Checked with the san admin.

other bad news : I cant boot in maintenance mode the vPar with an unused system LUN from an old vPar

So I must assume that I did a mistake during mirroring of the original LUN.

I will now check boot area of the faulty disk while booted with the old LUN

[Eric SAUBIGNAC]

@Albertino : I try to boot in maintenance mode since I have noticed that the vpar has a problem.

@Torsten : you are right, when the vPar is down, HBA are no more loggued in the fabric. And if my confusion about the real speed of the gbic is due to the autoneg configuration, I have realized that the brocade OS fabric version is pretty old : v5.1.0b. You now, this kind of version that was not able to show correctly in the java gui the current configuration of a port when you want to modify its settings ... ;-)

@all

Problem solved. I have now to understand which action has given this result or which action I forgot to finalize the mirroring of vg00. If anyone has a comment to do on how I realized the mirror (check one of my previous post in this thread), please feel free to post.


Some explanation on how I have repaired my mistake.

- Boot in maintenance mode an other system LUN. An healthy one ;-)

- Import as vghp21 the faulty disk. Clean every mirroring previously done.

- Then list boot configuration

root@unknown:/etc>lvlnboot -v

---> Booted healthy lun from the other vPar

Current path "/dev/dsk/c26t2d1" is an alternate link, skip.
Current path "/dev/dsk/c36t2d1" is an alternate link, skip.
Current path "/dev/dsk/c39t2d1" is an alternate link, skip.
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c29t2d1 (0/0/10/1/0/4/0.5.0.0.0.2.1) -- Boot Disk
/dev/dsk/c26t2d1 (0/0/10/1/0/4/0.1.0.0.0.2.1)
/dev/dsk/c36t2d1 (1/0/14/1/0/4/0.2.0.0.0.2.1)
/dev/dsk/c39t2d1 (1/0/14/1/0/4/0.6.0.0.0.2.1)
Boot: lvol1 on: /dev/dsk/c29t2d1
/dev/dsk/c26t2d1
/dev/dsk/c36t2d1
/dev/dsk/c39t2d1
Root: lvol3 on: /dev/dsk/c29t2d1
/dev/dsk/c26t2d1
/dev/dsk/c36t2d1
/dev/dsk/c39t2d1
Swap: lvol2 on: /dev/dsk/c29t2d1
/dev/dsk/c26t2d1
/dev/dsk/c36t2d1
/dev/dsk/c39t2d1
Dump: lvol2 on: /dev/dsk/c29t2d1, 0


--> Lun I should be able to boot from this vPar. Note the "No Boot Logical Volume configured"


Current path "/dev/dsk/c29t1d5" is an alternate link, skip.
Current path "/dev/dsk/c36t1d5" is an alternate link, skip.
Current path "/dev/dsk/c39t1d5" is an alternate link, skip.
Boot Definitions for Volume Group /dev/vghp21:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c26t1d5 (0/0/10/1/0/4/0.1.0.0.0.1.5) -- Boot Disk
/dev/dsk/c29t1d5 (0/0/10/1/0/4/0.5.0.0.0.1.5)
/dev/dsk/c36t1d5 (1/0/14/1/0/4/0.2.0.0.0.1.5)
/dev/dsk/c39t1d5 (1/0/14/1/0/4/0.6.0.0.0.1.5)
No Boot Logical Volume configured
Root: ??? on: /dev/dsk/c29t1d5
/dev/dsk/c26t1d5
/dev/dsk/c36t1d5
/dev/dsk/c39t1d5




No Swap Logical Volume configured
No Dump Logical Volume configured

- Then correct boot area with "lvlnboot -b /dev/vghp21/lvol1"



From this point I have been able to boot with the faulty disk in maintenance mode and finalize a clean configuration

[Torsten.]

I really don't like the

lvlnboot -R

I prefer the single steps

lvlnboot -r|-b|-d ...


for exactly this reason.

[Cortes Albertino]

Bonjour,

Regarding your used vg00 mirror procedure,

I usually ran the "vgextend /dev/vg00 ..." command just after the "pvcreate -B ...." and also use "lvlnboot -r/-b/-s/-d ...."

Albertino

[Eric SAUBIGNAC]

@Albertino : the order in which the mirrord disk is inserted in the vg00 really doesn't matter. Well, of course after pvcreate -B ...

@All : I guess "lvlnboot -R" was the problem. Not 100% sure because I remembered that I added some pvlinks to the mirrored disk AFTER the mirroring procedure.

And I have used this "-R" procedure for a while with no problem. So I am not really sure why it didn't succeeded this time ... Maybe I should have done some more tests to understand more deeply the problem, but I had not so much time for this. A bit lazy probably :-)

Something else : for those who want to migrate san boot disks of ITANIUM vPar, DON'T forget the vpar efi path database : vparefiutil ;-)

Eric