Ed, This seems to be a bug. Can you post a reference to the two notes you mention ?
See these in MOS
Have you applied the latest 220.127.116.11 PSU ?
Srini, thanks for the feedback. I'd about given up on finding anything on this.
The thread I mentioned that I had started in MOS Communities is in the Storage Management community, titled "invalid LOCAL_LISTENER introduced when upgrading ASM from 18.104.22.168 to 22.214.171.124 "
Doc ID 1457634.1 speaks of a pre-existing listener and presents a variety of messages found in the various logs. It is not clear (to me, anyway) if this is addressing a new installation or an install/upgrade. In any event, none of the messages reported in the note appear in any of my logs.
Doc ID 1543002.1 talks about a failure to start from srvctl but a successful start from sqlplus. In my case, after completion of the install/upgrade, an attempt to get the ASM instance started from sqlplus also failed.
The documents you reference look the closest yet, especially if one pays attention to the caveat "... is a summary description only. Actual symptoms may vary"
Have not applied the latest 126.96.36.199 PSU, as this is the base, initial installation of 188.8.131.52, using OUI to both install and run the upgrade, so at that point there is no 184.108.40.206 to be patched. Am upgrading only the GI home at this time. I like to do these things in the smallest increment possible, and so do the GI home and databases separately. I've never used the OUI option to download software updates as part of the install, but I think I'll try to test that and see what happens.
I am running trials and dress rehearsals on my VBox test lab and have confirmed that the simple work-around is to run the install/upgrade, then manually remove the bogus LOCAL_LISTENER parameter. I had already tested that before finding the two notes referenced above. While they didn't appear to be a close match to me on causes, the outcome was the same, and they had essentially the same work-around solution .. fix the parameter after the fact.
One thing I did notice in testing was that all of the ASM and db instances in this Oracle Restart config receive and ALTER SYSTEM SET LOCAL_LISTENER .... SCOPE=MEMORY as part of their startup sequence. Presumably this is being issued by oracle restart, and would override any spfile settings anyway. But of course if a bad parm in spfile prevents the instance from even starting at all, there is nothing to ALTER SYSTEM against. I also noted that that ALTER SYSTEM command was coming with a fully qualified spec, not a tnsnames reference.