volume group not active at boot time

[Medavie]

We recently upgraded secure path to release 3.0b. After re-booting the 2 volume groups which are affected by secure path are not being activated at boot time. What I am having a problem with is , at what point in the boot sequence do the volume groups get activated. I am thinking that the secure path software is bring activated after the volume groups are activated. One note is that after the system boot completes I can activate the volume groups using vgchange with no problem.

[RAC_1]

check /etc/lvmrc. you can specifiy which vgs to activate boot time in this file.

[Steven E. Protter]

confirm your suspicions by looking at /etc/rc.log

If there is a boot order issue, you may need to change the location of the soft link starting the secure path product.

These are in /sbin/rc#.d

The # is replaced by a number which you will see in the rc.log file.


They point to /etc/sbin/init.d start up scripts.

SEP

[RAC_1]

Also check /etc/rc.log

[Medavie]

The /etc/lvmrc has the auto activate turned on which is the same as all other servers I have. Also the rc.log shows the startup as normal until the mountall which is one of the first things to activate and thenis gives all kinds of errors when it can not fsck and mount the lvols as they are not there.

[RAC_1]

Post the eact error message.

[Vasikaran Venkatesan · Accepted solution]

To answer your question of "what stage the LVs get activated" - it is during the init phase of the boot process.
init reads /etc/inittab which runs /sbin/bcheckrc - > which calls /sbin/lvmrc and goes for the activation of VGs as defined in the /etc/lvmrc.

[kavanagh_1]

Your problem is this: SecurePath used to have a problem readdressing disks upon reboot. SP1 of securepath got around this by keeping it's path data in a kernel loadable module swspData. The problem is that 'kmadmin -L swspData' is executed AFTER the lvmrc vgchange -a ...
You might think the solution would be to put the kmadmin command in before the lvmrc vgchange.. Unfortunately, kmadmin uses dynamic libraries found in /usr/lib which at the point lvmrc is called are unavailable.
I would have expected HP to provide a static loadable kmadmin command (like they do for /etc/vgchange for example) but no - their solution is to call:
/usr/sbin/vgchange -a y
/usr/sbin/mountall
in rc2.d somewhere.

[CABY_2]

We have the same problem with SecurePath v3.0b SP1 with all required patches installed.
The following messages appears on console during boot sequence :
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c12t0d0":
Invalid argument
vgchange: Warning: Couldn't query physical volume "/dev/dsk/c12t0d0"

[CABY_2]

These problem was referenced in SecurePath v3.0B Service Pack 1 Release Notes :

If you configure some Secure Path devices under volume groups, make SAN configuration changes, and reboot the system, the volume groups may not be
activated at reboot. This situation can occur because the Secure Path persistence module is loaded after the Logical Volume Manager (LVM) configuration completes. To resolve this problem, you must manually activate the volume groups using the command vgchange -ay after the system has completed the boot process.

The problem has been corrected in SecurePath v3.0C.