lvmrc skipped

[Ralph Grothe]

I have some trouble with non-cluster-shared VGs not being activated by init during runlevel changes (viz. system boot).
Scouring through init's startup sequence I found that a shell script /sbin/lvmrc is sourcing /etc/lvmrc.
The latter contains sufficient commentary to see what its purpose is.
So I set the variable AUTO_VG_ACTIVATE=0 in it and modified the custom_vg_activation() to parse /etc/fstab for not commented (i.e. non-cluster-shared) VGs.
See my attachment.
I hope it got uploaded correctly, for it's my first attachment posting here because I know that due to this forum's limitations text passed to this textarea will lose indenting whitespace, and this textarea is not HTML markup aware :-(

My modifications to /etc/lvmrc seem ok for me as it works when I deactivate fstab's VGs and execute /sbin/lvmrc manually.

The problem is that I have my /opt filesystem in another VG than vg00, and it won't get activated by init with the consequence that the following mount -a will fail to mount /opt.
Unfortunately the sshd resides in /opt/openssh/sbin.
This results in a securely inaccessable box for me (viz. remote administration).

Could it be I have forgotten some toggle, maybe in /etc/rc.config.d or elsewhere?

TIA
Ralph

[melvyn burnard]

Well to be honest, looking at the changes you have made to lvmrc, I think you have added complication the way it is done.
Why not keep it simple and just have a separate line for each vg you DO want activbated at boot time.
e.g.:

/sbin/vgchange -a y -s /dev/vg00
/sbin/vgchange -a y -s /dev/vg_pete
/sbin/vgchange -a y -s /dev/my_vg

[Ralph Grothe]

Hi Melvyn,

the reason why I complicated things was because this is a test cluster with lots of disks, where I constantly create or remove new VGs.
And after those modifications I will never forget to adapt the /etc/fstab whereas I simply tend to forget about silly non-Unix-standard files such as /etc/lvmrc, which if not selfadapting also would require updating.

Btw, I see not to have supplied awk the full path (i.e. /usr/bin/awk).
Can that be a reason for failure?

[John Palmer]

Ralph,

I tend to agree with Melvyn on this one - after all, now you know about /etc/lvmrc, you won't forget to change it will you ;-).

However, the full pathname for awk will be required as lvmrc is run very early in the boot sequence. /usr/bin/awk won't work either as /usr isn't mounted at this point. You'll have to use /sbin/awk which will be available.

Also I seem to remember reading somewhere that you don't have to specify vg00 in lvmrc is it is automatically activated (and sync'd) earlier in the boot process.

Regards,
John

[melvyn burnard]

Yes you would have to specify the full path for awk, and in this case, anything under /usr is no good as it is not available at this stage, as John states.

As an additional comment, IF the root vg is mirrored using MirrorDisk/UX, then you do need to have an entry for vg00.

HTH

[Ralph Grothe]

Hi John,

Well, I may not forget it right now, but I'm sure (with so many silly things to remember, let alone all those root passwords ;-), I will be wasting another half an hour in a couple of month tracing this damned lvm*, what was its name again?

Wow, I haven't even realized up till now there is an awk in /sbin :-}
But how come its magic number is conveying that it be a shared executable,
thought shared libs weren't available in maintenance mode?

# chatr /sbin/awk
/sbin/awk:
shared executable
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: D (default)
instruction page size: D (default)

Anyway, I think the non-availability of /usr at this stage of the initialisation sequence must have been the real reason.

You seem right that vg00 isn't affected, otherwise I wouldn't even have been able to rlogin from another cluster node.

Unfortunately I cannot reboot right now, but I will try tomorrow

Thanks
Ralph

[Ralph Grothe]

@ Melvyn,

of course are my root VGs on nodes mirrored, but got activated correctly despite...

# lvlnboot -v vg00
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t3d0 (8/4.3.0) -- Boot Disk
/dev/dsk/c0t3d0 (8/0.3.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t3d0
/dev/dsk/c0t3d0
Root: lvol4 on: /dev/dsk/c1t3d0
/dev/dsk/c0t3d0
Swap: lvol2 on: /dev/dsk/c1t3d0
/dev/dsk/c0t3d0
Dump: lvol2 on: /dev/dsk/c1t3d0, 0

[James R. Ferguson]

Hi Ralph:

I think you are thinking of dynamic vs. static libraries. The 'chatr' output from /sbin/awk looks like what I'd expect.

Regards!

...JRF...

[Ralph Grothe]

Hi James,

thank you for confirmation on awk.
The one in /sbin must be another binary since it is three times as big compared to the one in /usr/bin.

Btw. I realized those new funny pharaoh bonnets.
What does this mean, have you reached a superior level of enlightenment or even immortality?
Only joking ;-)

[melvyn burnard]

James has just been to visit a new hair stylist :-}