This has happened to me twice now, having rebuilt the machine in between.
I'm running SuSe 9.3, with a minimal system to start with as I wanted to build in services one by one. The first, so I can get users logging in, was LDAP. So I selected OpenLDAP 2.2.23 during installation and it selected BDB 4.3..27 as a dependency.
I carefully got it to work, and managed to get a client machine to use the LDAP service to log a user in no problem. I have not consciously done any software changes, just configuration changes and the vast majority of those, with the exception of configuring /etc/openldap/slapd.conf and ldapadd-ing the root of the LDAP tree, in YAST.
But then I rebooted the LDAP server machine and it all fails. Trying to start slapd afterwards (again through the YAST runlevel editor) and investigating logs I get the following:
Jul 30 00:10:20 server3 slapd[7387]: @(#) $OpenLDAP: slapd 2.2.23 (Mar 19 2005 20:43:26) $ abuild@salam:/usr/src/pack
ages/BUILD
/openldap-
2.2.23/ser
vers/slapd
Jul 30 00:10:20 server3 slapd[7387]: bdb_back_initialize: Sleepycat Software: Berkeley DB 4.3.27: (June 1, 2005)
Jul 30 00:10:20 server3 slapd[7387]: bdb_db_init: Initializing BDB database
Jul 30 00:10:20 server3 slapd[7388]: bdb(dc=mydomain,dc=co,dc=u
k): Program version 4.3 doesn't match environment version
Jul 30 00:10:20 server3 slapd[7388]: bdb_db_open: dbenv_open failed: DB_VERSION_MISMATCH: Database environment version mismatch (-30974)
Jul 30 00:10:20 server3 slapd[7388]: backend_startup: bi_db_open failed! (-30974)
Jul 30 00:10:20 server3 slapd[7388]: bdb(dc=mydomain,dc=co,dc=u
k): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
Jul 30 00:10:20 server3 slapd[7388]: bdb(dc=mydomain,dc=co,dc=u
k): txn_checkpoint interface requires an environment configured for the transaction subsystem
Jul 30 00:10:20 server3 slapd[7388]: bdb_db_destroy: txn_checkpoint failed: Invalid argument (22)
Jul 30 00:10:20 server3 slapd[7388]: slapd stopped.
Jul 30 00:10:20 server3 slapd[7388]: connections_destroy: nothing to destroy.
Does anyone have any ideas what's going on here? I googled extensively for combinations of some of the key phrases in these log entries but with little success. I'm desperate. I can't make any further headway with getting my system back up and running till I can get LDAP running consistently.