You want DB2 to start up automatically at boot, so you use the official method and enable the fault monitoring system and then use
db2iauto -on instancename to enable autostart.
On rebooting, DB2 isn’t started. You check
/var/log/syslog and see:
Jun 13 15:37:05 servername kernel: [ 67.324105] db2fmcd
general protection ip:7fa9c68306c4 sp:7fff86c43150 error:0 in
or something similar. Yes, ironically enough, the fault monitor has caused a general protection fault.
The DB2 10.1 installer seems to attempt to enable DB2 Administration Server (DAS), which was used for the old DB2 Control Center that is no longer supported in DB2 V10. DAS causes the crash. To disable it:
Then I rebooted, and after a minute or so the fault monitor successfully started DB2.
Solution found on the developerWorks forums, summarized and reposted here for added visibility to search.
Seems to affect CentOS, Ubuntu Server and VMware DB2 V10.1 instances, on Intel i7 x86-64. Affects DB2 V10.1 Enterprise Server, DB2 Express-C, and probably other license variants. Does affect clean installs.
Network Manager refuses to start your Ethernet connection using the GUI, with the connection showing up as “Unmanaged”.
The command-line interface to Network Manager reports an error “Error: Connection activation failed: Device not managed by NetworkManager or unavailable”.
However, ifup/ifdown successfully starts and stops your Ethernet connection.
Some VPN software helpfully added the eth0 lines to your list of interfaces handled by the older network scripts. When Network Manager sees that, it refuses to manage eth0 itself.
Did you just install a new RHEL 6 system? If so, you might have used the familiar rhn_* commands to register the system. Unfortunately, those don’t work in RHEL 6.3. Instead, they result in a broken setup where Yum always barfs with the above error.
RedHat’s knowledgebase article claims that it’s possible to set up traditional RHN on a 6.x system, but their instructions don’t seem to work.
Instead, first you’ll need to get rid of the old ‘RHN Classic':
rm -rf /etc/sysconfig/rhn_systemid
rm -rf /var/cache/yum/*
yum clean all
Now delete the system from the classic RHN console on the web, to free up the entitlement. After that, you can register for the new improved RHN, using a different set of commands:
subscription-manager subscribe --auto
Now yum update should work.
Also, you don’t want to go to https://rhn.redhat.com/ any more. That’ll only show you the “Classic RHN” systems. Instead, go to https://access.redhat.com/management/ which will show you both. Yes, you have to manage your 6.x and pre-6.x systems via two different web UIs.
You can also access the new management interface via the Subscriptions menu; however, I missed finding it for ages because I didn’t realize that systems were now referred to as “consumers”. In RedHat’s crazy new terminology you’re a “distributor”, because you distribute keys to the “consumers”.