A while back I posted about Fixing IBM DB2 for non-ancient operating systems. tail’s deprecated +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
This allows 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).
DB2 mangles /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.
