cancel
Showing results for 
Search instead for 
Did you mean: 

Member2 can't boot from SAN

Larry Vatkin
Advisor

Member2 can't boot from SAN

I'm configuring TruCluster 5.1B on two hardware partitions of GS160 and member2 can't boot from SAN. As if I've done everything right using wwidmgr, but still got this:
(boot dga555.1002.0.4.17 -file genvmunix -flags s)
block 0 of dga555.1002.0.4.17 is a valid boot block
reading 19 blocks from dga555.1002.0.4.17
device dga555.1002.0.4.17 no longer valid
failed to read dga555.1002.0.4.17
bootstrap failure

Could it be that boot disk dsk1 is seen by member2 as different name? .member2.cfg file is attached.
Thanks,
Larry
14 REPLIES

Re: Member2 can't boot from SAN

See if the other member can mount the member2 disk. If it can, take a cursory look at the boot partition files. Also, check the sysconfigtab for member2 at the bottom for disk major and minor assignments.

From above, you're not even getting off the ground for member2. Any LSM?

Re: Member2 can't boot from SAN

LSM wouldn't be factor here but might later.

Re: Member2 can't boot from SAN

Time to go home :)
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

Thanks, Roger.
No, LSM is not there yet.
I can mount /cluster/members/member2/boot_partition on root2_domain#root on member1 and see genvmunix and osf_boot there. I suspect the relationship between Alpha and Storage itself, which is IBM Storage Volume Controller on top of DS4400 (formerly FAStT700). I couldn't boot member1 from SAN disk either. Actually, I can do everything, but boot with SAN disks - with LSM and without.
Any ideas?
Thanks,
Larry
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

One more detail:
wwidmgr displays reservation conflict for the boot disk (dga/b555) and quorum disk (dga/b777):
AlphaServer Console V6.9-1, built on Nov 18 2004 at 09:46:43
P00>>>ww -sh ww
Reservation conflict for dga555.1001.0.4.17
Reservation conflict for dga555.1002.0.4.17
Reservation conflict for dga777.1003.0.4.17
Reservation conflict for dga777.1004.0.4.17
Reservation conflict for dgb555.1001.0.1.18
Reservation conflict for dgb555.1002.0.1.18
Reservation conflict for dgb777.1003.0.1.18
Reservation conflict for dgb777.1004.0.1.18
Reservation conflict for dga555.1001.0.4.17
Reservation conflict for dga555.1002.0.4.17
Reservation conflict for dga777.1003.0.4.17
Reservation conflict for dga777.1004.0.4.17
Reservation conflict for dgb555.1001.0.1.18
Reservation conflict for dgb555.1002.0.1.18
Reservation conflict for dgb777.1003.0.1.18
Reservation conflict for dgb777.1004.0.1.18
[0] UDID:-1 WWID:01000010:6005-0768-0185-0033-7000-0000-0000-0000 (ev:wwid0)
[1] UDID:-1 WWID:01000010:6005-0768-0185-0033-7000-0000-0000-113e (ev:wwid1)
Eric van Dijken
Trusted Contributor

Re: Member2 can't boot from SAN

I never add the quorum disk to the wwidmgr.

I would clean the wwidmgr setting.

>>> wwidmgr -clear all
>>> wwidmgr -quickset -udid 555

(This will show a list of devices, find one that has the status "CONNECTED: YES" )

>>> init

>>> boot -file genvmunix (insert device name from above)

Watch, Think and Tinker.
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

Thanks, Eric.
In fact, I added the quorum disk just to see another reservation conflict. And I booted multiple times before and after I added and removed quorum disk. All according to wwidmgr rules.
Alas, with the same result...
Looks like all things point to the controller, because direct boot from storage worked before.
And, again, I could do anything with SAN disks, but boot from them, Cluster or just pure Tru64 OS.
Any hint will be appreciated.
Thanks,
Larry
Eric van Dijken
Trusted Contributor

Re: Member2 can't boot from SAN

Can you give us a listing of the "wwidmgr -show reach" command?
Watch, Think and Tinker.
Eric van Dijken
Trusted Contributor

Re: Member2 can't boot from SAN

Oh, because the timezones are against us.

You could also try to add all paths to the "bootdef_dev" and than boot.

>>>wwidmgr -clear all
>>>wwidmgr â set ada â topo fabric â item 9999
>>>wwidmgr â quickset â udid dga555
>>>set bootdef_dev dgaX.1001 dgax.1002 dgbx.1003 dgbx.1004
>>>boot
Watch, Think and Tinker.
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

This is a setup, when I tried to limit paths from 4 to 2 pointing to exact node with boot disk:
P00>>>sh b*
boot_dev dga111.1001.0.4.17 dga111.1002.0.4.17 dgb111.1001.0.1.18 dgb111.1002.0.1.18
boot_file
boot_osflags A
boot_reset ON
bootbios
bootdef_dev dga111.1001.0.4.17 dga111.1002.0.4.17 dgb111.1001.0.1.18
dgb111.1002.0.1.18
booted_dev
booted_file
booted_osflags
P00>>>ww -sh re
Disk assignment and reachability after next initialization:
6005-0768-0185-0033-7000-0000-0000-1147 via adapter: via fc nport: connected:
dga111.1002.0.4.17 pga0.0.0.4.17 5005-0768-0130-04fc Yes
dgb111.1002.0.1.18 pgb0.0.0.1.18 5005-0768-0130-04fc Yes
P00>>>set bootdef_dev dga111.1002.0.4.17,dgb111.1002.0.1.18 P00>>> b
.................
AlphaServer Console V6.9-1, built on Nov 18 2004 at 09:46:43
CPU 0 booting
(boot dga111.1002.0.4.17 -flags A)
device dga111.1002.0.4.17 no longer valid
failed to read dga111.1002.0.4.17
bootstrap failure
(boot dgb111.1002.0.1.18 -flags A)
device dgb111.1002.0.1.18 no longer valid
failed to read dgb111.1002.0.1.18
bootstrap failure
P00>>>
Eric van Dijken
Trusted Contributor

Re: Member2 can't boot from SAN

Larry,

Just to make sure, i have never worked with your setup. We use FCA2354/2384 with an EVA5000 setup.

One thing i notice is that the wwidmgr output, shows that your UDID is set to "-1"
I am not 100% sure, but this may be a problem.

Another thing you could try, is: P00>>>wwidmgr -show ww -full

This should give more detailed information from you san disks. (check the wwidmgr manual for more info on: "no longer valid")


Watch, Think and Tinker.
Han Pilmeyer
Esteemed Contributor

Re: Member2 can't boot from SAN

Just a couple of remarks:

- UDID is purely informational for Tru64 UNIX. Not having it set (i.e. shown as -1 is fine).
- In your last attempt you have bootdef_dev set up through both adapters (dga and dgb), however in both cases you selected the same port on the EVA (1002, if I remember correctly). Perhaps the unit is on the other controller on the EVA and that other controller isn't reachable.
- In a typical environment with HSG's or EVA's, I would expect to see a path 1001, 1002, 1003 and 1004. That doesn't appear to be the case here. I would suggest double checking your zoning and selective storage presentation.
- The boot member disk is not protected by PGR's for the system that needs to boot from it and the quorum disk is not protected by PGR's at all. You shouldn't see any reservation conflict messages on those devices. Again I would double check the configuration for member2.
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

Thanks Eric and Han,
This particular setup hasn't been tried anywhere as far as I know, so it's uncharted territory.
I've tried everything and got consistent results: SAN boot from the Storage is working, with Volume Controller between Alpha and Storage - isn't.
I'm using Tru64 and TruCluster 5.1B/PK4 with FCA2354/2384 adapters, Brocade Silkworm 3800 switches.
Larry Vatkin
Advisor

Re: Member2 can't boot from SAN

The code of the controller required a fix, which solved the problem.