Wonder if the Operating-mode parameter playing any role which decides if
all servers are upgraded or not in server group. We have that parameter
available in 9.x.
Worth checking it.
Regards,
Ravi
On Mon, Apr 29, 2019, 9:46 AM Thomas Miskiewicz wrote:
> Doug
>
>
> You said: Even if you change
Doug
You said: Even if you change that dbversion, that shouldn’t solve the problem.
Even though the key was supposed to be the version number, simply changing it
doesn’t make the DB structure the old version.
That’s exactly my point: Can someone please reveal to us the specific criteria
by
Thomas,
I’m sure there was a lot of thought put into this by Engineering with the
intention of making the install process easier.
When the installer changes were made, it was with the plan to help customers
out by automating some of the decisions made by the installer.
Having said that, I
Doug,
I just told a story about you to one of my camping buddies. This still cracks
me up. You reminded me of it when you used the word doubt. I was buried in an
install at Coke in Atlanta. I think it was Solaris/ARS 4.whatever. I was
getting a shitload of error messages and it was
The thing is that I have reset the currdbversion but that doesn’t do anything.
Well in the last pre installation screen the info “Installer is performing a
secondary server install/upgrade, No forms will be imported” disappeared indeed
but it did appear after the fact at the end of the
Was there doubt with what I stated earlier?
If what I said doesn’t jive with reality, I can go back and do some more
research but all the evidence I’ve seen points to the CurrDBVersion being the
key.
Let me know if you see the currDBversion and dbversion in the control table
being 57 (not
Thanks Abhijit,
I upgraded from 9.1.04 to the latest version and the installer still says it’s
a secondary server.
This server is just an archive and it’s running fine so I think I’ll leave it
like this.
It remains a mystery to me that BMC apparently doesn’t know the exact procedure
they use
For 9.1.04 , there is a roll back utility to roll back platform upgrade
(AR, Atrium Core, Atrium Integrator) which also roll backs control table
mentioned by Doug. Please check with BMC support for this utility. You will
have to run this utility and then run upgrade again.
Thanks,
Abhijit H
On
I have a restore point for the current messed up state so I’ll run the
installer and see what it says.
> On 24. Apr 2019, at 21:00, Reif, Douglas wrote:
>
> If I ran this past the ‘committee’ you know what they would say; “We never
> tested that”.
> I’m guessing. Maybe they did test it. But
If I ran this past the ‘committee’ you know what they would say; “We never
tested that”.
I’m guessing. Maybe they did test it. But I have a good feeling that you’d be
on your own.
Having said that, the idea has merit.
Say you upgraded to 1902. It should assume that your DB is a fully intact
What about upgrading to even higher version? I see that the DB version would
change so maybe we could force it this way?
> On 24. Apr 2019, at 20:33, Reif, Douglas wrote:
>
> This is a difficult position. Since the DB was already upgraded to 57, the
> installer won’t upgrade it again; nor
This is a difficult position. Since the DB was already upgraded to 57, the
installer won’t upgrade it again; nor will it perform the imports that
typically would have occurred after the DB was upgraded and arserver restarted.
And there is not a way to downgrade the DB.
A “secondary” server is
Great Kevin, that’s sounds like a like I can work with. I will give it shot
and yet it’s be great to know how bmc recognizes primary vs secondary.
Thomas
On Wed 24. Apr 2019 at 20:21, Kevin Shaffer
wrote:
> In addition to what Doug said, we had a similar issue and these are all
> the pre req
Hi Doug,
and thank you for the prompt reaction!
The currdbversion version is indeed 57 however we don’t have a db we can
revert to...
So the questions remain:
- how does the installer recognize whether it’s dealing primary vs
secondary server
or
- how can we convince it to think of this
In addition to what Doug said, we had a similar issue and these are all the pre
req steps we had to perform to make it work in our environment because the
prechecker also enforced some things.
We too spent days looking through numerous XML files for the
BMC_IS_SECONDARY_SERVER variable but
Thomas,
We often see this problem after a prior install failed but had already updated
the database.
You run the next install and it checks the dbversion from the control table.
See https://communities.bmc.com/docs/DOC-37267. This shows that for 9104 the
currdbversion would be 57.
So my
16 matches
Mail list logo
