Recovering from a failed installation

[Will Honea]

Wanting to look at V9, I attempted to install Db2 Express-C on a Suse Linux
box I use as a sandbox. Since I was less that thorough when removing
previous installations of V8 and V7, the installation failed creating the
admin server. I now have a phantom instance that I can't access or drop so
the de_install fails but the installation is essentially useless. Is there
a reasonable way to remove all traces of V9 so that I can start over?

--
Will Honea

[aj]

Just a guess:

use rpm -e against all rpm -qa | grep db2 entries ??

HTH

aj

Will Honea wrote:

Wanting to look at V9, I attempted to install Db2 Express-C on a Suse Linux
box I use as a sandbox. Since I was less that thorough when removing
previous installations of V8 and V7, the installation failed creating the
admin server. I now have a phantom instance that I can't access or drop so
the de_install fails but the installation is essentially useless. Is there
a reasonable way to remove all traces of V9 so that I can start over?

[Will Honea]

aj wrote:

Being an engineer and mechanic as well a a programmer stuck with evaluating
this stuff, I did resort to the BMFH approach. Worked - but on three boxes
I'm getting the same result. At least now I can see the pattern and
problem: creation of the admin instance is failing. Really strange - the
control center opens and is apparently functional - I can add and make full
use of the client side functions.

Strange part is that while the Control Center refuses to acknowledge the
existence of the local instance (db2inst1 - I'm sticking the the strictly
default installation until I sort this out), a command line db2 session not
only recognizes it, it allows access to the toolsdb database created by the
installation, is happy to create the sample database, and merrily runs the
scripts to migrate existing V7.2 databases. The main object of all this
messing around is to get off the OS/2 V7.2 server we have without cutting
off several OS/2 clients we can't change for a while.

I have all the logs, so now it's time to track down just what the error was
during installation and see what has to be done to fix it. It appears to
be a problem with groups and permissions while creating the admin instance.
At least, this gives me something interesting to do for a few days <g>.

FYI, the installation is wierd - no rpms show up. Brute force purging of
files as root, a long scan for references to db2 and db2inst1 and any
reference to the db2??? users and groups seems to finally clean up the
mess. Much different installation process than what I've seen with V7 or
V8.

Just a guess:

use rpm -e against all rpm -qa | grep db2 entries ??

HTH

aj

Will Honea wrote:

>Wanting to look at V9, I attempted to install Db2 Express-C on a Suse
Linux
box I use as a sandbox. Since I was less that thorough when removing
previous installations of V8 and V7, the installation failed creating the
admin server. I now have a phantom instance that I can't access or drop
so
the de_install fails but the installation is essentially useless. Is
there a reasonable way to remove all traces of V9 so that I can start
over?

--
Will Honea

[Darin McBride]

Will Honea wrote:

Wanting to look at V9, I attempted to install Db2 Express-C on a Suse
Linux
box I use as a sandbox. Since I was less that thorough when removing
previous installations of V8 and V7, the installation failed creating the
admin server. I now have a phantom instance that I can't access or drop
so
the de_install fails but the installation is essentially useless. Is
there a reasonable way to remove all traces of V9 so that I can start
over?

Ideally, prior to uninstalling, you'd run "DB2DIR/bin/db2greg -clean" where
DB2DIR is wherever you've installed DB2 v9. This should clean up any
non-existing instances/das from the global registry. If you have already
toasted v9, and don't have v8 installed, either, don't worry, we can do
that later. (In fact, we can work around it altogether, but we won't get
into that until the bottom of this post.)

If you manage to clean up, you should be good to go. If not, next time you
install, ignore the das errors, and run the above clean command. Then das
creation should go through cleanly when you run "DB2DIR/bin/dascrt -u
[user]"

I have all the logs, so now it's time to track down just what the error
was during installation and see what has to be done to fix it.

Well, don't hold us in suspense! ;-)

FYI, the installation is wierd - no rpms show up. *

You didn't read the What's New documentation for v9, eh? :-)
http://publib.boulder.ibm.com/infoce...c/c0023235.htm

Following the links gets this summary:
http://publib.boulder.ibm.com/infoce...c/c0023236.htm

Brute force purging of files as root,

That works ... (unlike v8 where it leaves the RPM database in a confused
state)

a long scan for references to db2 and db2inst1 and any
reference to the db2??? users and groups seems to finally clean up the
mess. Much different installation process than what I've seen with V7 or
V8.

Yes, as the above links show, DB2 moved off RPM to allow you to install
anywhere, with multiple copies at any fixpack level you want, with all
products, not just ESE.

The one place you may be missing is /var/db2/global.reg - if you have no v8
or v9 products installed at all, you can simply delete the file rather than
cleaning it up. If you do have v8 or v9 installed and you don't want to
kill them, you'll have to use their bin/db2greg to clean it up.

[Will Honea]

Darin McBride wrote:

Yes, as the above links show, DB2 moved off RPM to allow you to install
anywhere, with multiple copies at any fixpack level you want, with all
products, not just ESE.

The one place you may be missing is /var/db2/global.reg - if you have no
v8 or v9 products installed at all, you can simply delete the file rather
than cleaning it up. Â*If you do have v8 or v9 installed and you don't want
to kill them, you'll have to use their bin/db2greg to clean it up.

That global.reg file was the key, far as I can tell. Comparing the logs and
history files between a newly installed OS and the failing ones got me down
to the point of failure coming when creation of the admin instance
attempted to manipulate the group id of the DASADMIN which appears in the
file with modifiers for both V8 and V9 - even after cleanly uninstalling
V8. The version 8 install also crashed with the exact same error history
after a failed V9 install.

I was looking for procedural differences and saw the reference to the
changed install - that's what triggered the brute force effort.

Off and running now. It appears that I have adequate interoperability all
the way across from OS/2 7.2 - both server and clients - to 9.1 LUW as long
as I stick to the command line and avoid the jdbc layer. Good enough for
now.

Thanks for the tip.

--
Will Honea