If you can't map the return code (we were adding something like that in some release, may not be in there yet) just put an 'exit 0' in the install command of the patch cluster after the 'install_cluster' line
as far as the single user mode - i didn't think the agent ran in single user mode anyway (booting into single user mode) anyway. i thought there was something like an rc script that kicked off the patch apply when the box came back up in SUM.
and i haven't done any conversion to smf - if you did that maybe post the xml or whatever if you are feeling generous :)
I really want to find out how bladelogic handle patch in single user mode, because when I use the init script to start the agent, and select "use single user mode without reboot", the rscd processes keep connected even though in single use mode. that's what make me think my smf config are not right.
I can share the xml if it help anyone.
my understanding was that if you drop to SUM w/o the reboot it's not really SUM - the network is still up and there are still connections.
if you do the 'reboot into SUM' (or however it's labeled) then you should get a 'real' SUM.
we've seen some issues w/ that where if the agent was installed in /opt (via the pkg), /opt isn't mounted in a normal SUM so you need a script to mount it.
the 'legacy' method of init.d should still work fine in solaris 10., so i don't know how much you want to mess w/ the SMF.
Bill, I am running into issues with Solaris patching in SUM with the /opt not being mounted, what type of script are you refering too in order to mount /opt?
Pre: echo "mount /opt" > /etc/rcS.d/S99BMC_SUM_Mounter
Post: rm -f /etc/rcS.d/S99BMC_SUM_Mounter
Another question for you, we were running patching on a test box that doesn't have the /opt mounted and its now stuck in signle user mode, any idea how to get it out, we tired to halt and reboot and comes right back up into SUM.
Thanks for your help
I think svcadm can do this. I forget exactly how though.
or you can try
svcadm milestone -d svc:/milestone/multi-user:default
just happened to work on the same issue, here's what I sent to the Customer:
Check with local Solaris Admins if they are willing to mount /opt in SUM by default on their Solaris servers. If not, then we have few workarounds to consider.
1. Instead of reboot into SUM, you can use drop down into SUM without reboot - this is one of the SUM options in the Deploy Job. With this option, the partitions stay active and networking is available, so the system will not hang like it did.
WARNING: some patches do require the system be rebooted into SUM, so with this option you may have some errors with some patches, though this option is used by some Users without any issues.
2. Use pre and post commands for every Deploy Job in this fashion (needs to be tested first - this is what we discussed on the phone)
echo "mount /opt" > /etc/rcS.d/S99BMC_SUM_Mounter
rm -f /etc/rcS.d/S99BMC_SUM_Mounter
For this to work properly, we should configure the job to 'Reboot into SUM' and 'ignore item defined reboot settings and reboot at the end of job'.
3. Another option would be to create a permanent SUM script directly on the server which would perform the following:
[ -f /etc/rcS.d/S99xbldeploy ] && mount /opt
Basically if S99xbldeploy script is detected, then we know that it was BladeLogic who rebooted the system into SUM, so the /opt will be mounted. This script will need to be executed prior to S99xbldeploy obviously.
Also if your system cannot come out of SUM right now even if you reboot, then here is why:
This happens because the milestone command to bring the system back to multi-user was never executed by bldeploy, because bldeploy was never launched due to lack of /opt in SUM. This is what you need to run from the console logged in as root:
svcadm milestone -d all