A while back I posted about Fixing IBM DB2 for non-ancient operating systems.
+n syntax broke the installer at a critical point, leaving DB2 rather broken.
I’ve since found a more elegant fix. Before you run the installer, run set the
_POSIX2_VERSION environmental variable:
# party like it's 1992 $ export _POSIX2_VERSION=199209 $ /tmp/db2/db2setup -r /tmp/db2/db2_wse_response_file.rsp
tail to use the older syntax, and the install completes successfully.
Unfortunately DB2 is broken in a lot of other ways. The supplied
db2_deinstall script removes the RPMs, but it does so regardless of whether DB2 is running or not. It also sprays files all over the filesystem. This makes it really difficult to fully and cleanly remove DB2 from your system and not have reinstalls tainted.
So here’s a script that should clean up its mess:
#!/bin/sh -e echo "You really should run db_deinstall first!" echo -n "Have you done this? [y/n] " read continue if [ "$continue" != "y" ]; then echo "OK Bye!" exit 1 fi killall -9 -u db2inst & killall -9 -u db2fenc & killall -9 -u dasusr & echo "Sleeping while DB2 is forced to shutdown." sleep 4 userdel --force --remove db2inst userdel --force --remove db2fenc userdel --force --remove dasusr groupdel dasadm groupdel db2grp groupdel db2fgrp rm -rf /opt/IBM/db2 rm -rf /home/db2 rm -rf /var/db2 grep -v ^db2c /etc/services > /etc/services.new mv /etc/services.new /etc/services
This assumes that you’ve set all your DB2 users’ homes to be under
/home/db2 (which is a sane way of limiting DB2’s potential damage anyway).
/etc/services and doesn’t clean up after itself, causing subsequent installs to fail hard for no apparent reason. You must clean this up if you want a reinstall to work.
My conclusion: administering DB2 can be an enormous time sink. Making it behave is not worth the time. Convince your manager or client to use something else like Postgres.