How to configure off alternate boot device?

[Ralph Grothe]

Hi,

this applies to an rp8420 under HP-UX B.11.11

On this test box I temporarily stole the first boot disk of mirrored vg00 as I needed this in a production box whose mirror root disk of the same disk model and size went defunct.

Now I want to adapt the setboot config to reflect the changes of the test box.
But when I try to configure the alternate boot path off it doesn't let me do so.

Although I assume that a false alt boot path reference wouldn't hurt that much if it is missing anyway,
it would be nice to map the current degraded state exactly nevertheless.

Is there a special syntax to achieve this?

Here are the current settings
as well as my futile attempts to get rid of the alt boot path:

# model
9000/800/rp8420

# uname -srv
HP-UX B.11.11 U

# vgdisplay -v vg00|grep PV\ Name
PV Name /dev/dsk/c1t2d0

# lvlnboot -v vg00
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t2d0 (0/0/6/1/1.2.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t2d0
Root: lvol3 on: /dev/dsk/c1t2d0
Swap: lvol2 on: /dev/dsk/c1t2d0
Dump: lvol2 on: /dev/dsk/c1t2d0, 0

# lifls /dev/rdsk/c1t2d0
ODE MAPFILE SYSLIB CONFIGDATA SLMOD2
SLDEV2 SLDRV2 SLSCSI2 MAPPER2 IOTEST2
PERFVER2 PVCU SSINFO ISL AUTO
HPUX LABEL

# lifcp /dev/rdsk/c1t2d0:AUTO -
hpux -lq /stand/vpmon -a

# cat /stand/bootconf
l /dev/dsk/c1t2d0

# lssf /dev/dsk/c1t2d0|cut -d\ -f15
0/0/6/1/1.2.0

# setboot -p 0/0/6/1/1.2.0 -b on -s off

# setboot
Primary bootpath : 0/0/6/1/1.2.0
Alternate bootpath : 1/0/6/1/1.2.0

Autoboot is ON (enabled)
Autosearch is OFF (disabled)

Note: The interpretation of Autoboot and Autosearch has changed for
systems that support hardware partitions. Please refer to the manpage.

# setboot -a ""
setboot: "" is not a proper bootpath

# setboot -a
setboot: option requires an argument -- a
usage: setboot [-p primary_path]
[-a alternate_path]
[-b on|off]
[-s on|off]
[-v]
[-t test_name=on|off|default]
[-T test_name=on|off|default]

# setboot -a NULL
setboot: "NULL" is not a proper bootpath

# setboot -a missing
setboot: "missing" is not a proper bootpath

[Ralph Grothe]

Ah, just another thought that came to my mind.

Since vg00 isn't mirrored anymore
I guess that I also would need to change the boot disk's AUTO string from

# lifcp /dev/rdsk/c1t2d0:AUTO -
hpux -lq /stand/vpmon -a


to maybe merely

hpux /stand/vpmon -a

(n.b. as this is a VPar hence the reference to the vpmon kernel)

[Johnson Punniyalingam]

official procedures

http://docs.hp.com/en/5991-1236/When_Good_Disks_Go_Bad_WP.pdf

[Ralph Grothe]

Thanks Johnson,
I know this document (albeit maybe from a previous release).
Alas, this "official procedure" doesn't seem to address my setboot issue at all.
I assume because degrading a Root VG from a formerly one-way to a zero-mirror entity isn't considered state of the art, at least nothing to be recommended to customers.

But maybe my concerns are totally unfounded and it doesn't matter at all what is currently set as an alt boot path when there doesn't exist such at all?

[Torsten.]

You cannot "unset" this value, but you can set it to the same value as the primary.


Since it is a vPar machine, consider to set it to the boot disk of another vPar.

BTW, the "-lq" makes no sense if you boot vpmon.

[Javed Khan_1]

Hi,

Why not set it to cdrom. or same device a alternate path

Javed

[Ralph Grothe]

Hi Torsten,

> You cannot "unset" this value, but you can set it to the same value as the primary.

Ok, that's what I already found out by trial and error.
So, following your suggestion I announced the sole boot disk to be the alt boot path as well

# setboot -a 0/0/6/1/1.2.0

# setboot
Primary bootpath : 0/0/6/1/1.2.0
Alternate bootpath : 0/0/6/1/1.2.0

Autoboot is ON (enabled)
Autosearch is OFF (disabled)

Note: The interpretation of Autoboot and Autosearch has changed for
systems that support hardware partitions. Please refer to the manpage.


> Since it is a vPar machine, consider to set it to the boot disk of another vPar.

I'm not sure what to make of this.
The various VPars accessible are instances of totally unrelated organizational units belonging to or used by different customers who run independent applications on them.

> BTW, the "-lq" makes no sense if you boot vpmon.

Yes, that's what I was pondering about since remaining PV isn't part of a raid array (mirror) anymore why ignoring a quorum doesn't make much sense in this special (abnormal) case.
But isn't "-lq" justified on a host with an intact mirror?
Doesn't the /stand/vpmon executable reside on /dev/vg00/lvol1 in general
where, if vg00's PVs are members of a mirror and where vg-activation might fail due to lack of quorum when one of the member PVs has failed and isn't attached anymore?
So why wouldn't the "-lq" make sense in such a (standard) environment?

[Torsten.]

I think we both mixed up things here.

The stable storage of the system keeps the boot pathes, the LIF (or EFI) area of a disk keeps the AUTO file.

Normally the system is powered on, does POST, reads the NVRAM and boots the specified path.

But now this is vPars!

The system cold boots and need to boot the vpmon from a disk - no matter which one (except in mixed environments).

Once vpmon has booted, each VPar boots and reads the primary/alternate path from VPDB!



So the boot path in NVRAM should contain pathes to boot disks - no matter what VPAR. It's only important to find a copy of vpmon there.

[Ralph Grothe]

I am not sure if I can address any arbitrary boot device with the vpmon kernel from this machine?
If I recall correctly this is not just a VPar but also an NPar and the I/O paths of internal disks and drives were once assigned immutably to the NPars when the systems once were built up.

From within this vpar it's only these few disk paths that I can see.
(the NO_HW slot is the one with the defunct disk donated by the other production system)

# ioscan -knfdsdisk
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
disk 0 0/0/6/1/1.0.0 sdisk NO_HW DEVICE HP 146 GMAW3147NC
/dev/dsk/c1t0d0 /dev/rdsk/c1t0d0
disk 1 0/0/6/1/1.2.0 sdisk CLAIMED DEVICE HP 146 GST3146707LC
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0
disk 2 1/0/6/1/1.0.0 sdisk NO_HW DEVICE HP 146 GMAW3147NC
/dev/dsk/c3t0d0 /dev/rdsk/c3t0d0
disk 3 1/0/6/1/1.2.0 sdisk CLAIMED DEVICE HP 146 GST3146707LC
/dev/dsk/c3t2d0 /dev/rdsk/c3t2d0


And these are this vpar's resources:


# vparstatus -w -M|xargs vparstatus -v -p
[Virtual Partition Details]
Name: vpdoro
State: Up
Attributes: Dynamic,Autoboot,Nosearch
Kernel Path: /stand/vmunix
Boot Opts: -lq

[CPU Details]
Min/Max: 2/2
Bound by User [Path]:
Bound by Monitor [Path]: 2.15
3.10
Unbound [Path]:

[IO Details]
0.0.6.1.1.0.0.0.0.0.0
1.0.6.1.1.2.0.0.0.0.0
1.0.4
2.0.14
0.0.6.1.1.2.0.0.0.0.0 BOOT, ALTBOOT

[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 4096


Now I realize there's also the boot opts "-lq", derived from the vpdb I presume?

Do I need to unset this in the vpdb by some vparmodify command?
(e.g. # vparmodify -p vpdoro -o "")

[Torsten.]

Just to clarify, sorry for confusion.

You cannot unset the alt path in NVRAM, but you can remove it from a vPar.

Just reduce the mirror, then remove it from the vPar, e.g.

# vparmodify -p ... -d io:0.0.6.1.1.2.0.0.0.0.0:ALTBOOT

[Ralph Grothe]

Alright, so I now would delete this i/o resource of the ALTBOOT path from this vpar.
But what about the now redundant boot option "-lq"?
Should I also blank it in one go by e.g.

# vparmodify -p $(vparstatus -wM) -d io:0.0.6.1.1.2.0.0.0.0.0:ALTBOOT -o ""

[Torsten. · Accepted solution]

I never did this, but this is what I would try.

However, "-lq" would be OK if there is only 1 disk configured.

[Ralph Grothe]

Sorry, for my hesitance.

Anyway, it looks as though this kind of vpar modification is only executable in the vpar's down state.
So I will defer it to the next maintenance interval of this box.

Thanks for the help Torsten.

# vparmodify -p $(vparstatus -wM) -d io:0.0.6.1.1.2.0.0.0.0.0:ALTBOOT -o ""
vparmodify: Error: Virtual partition vpdoro must be in the Down state.

[Torsten.]

Yes, IMHO everything with "-io" needs to be done in down state. Maybe the "-o ''" is an exception?