Howard Chu wrote:
There is no need for your step #2.
(step #2 is removing all entryCSN, contextCSN lines).
I did so because the SID of CSN values from the 2.3.30 dump is 00:
entryCSN: 20071214130312Z#000000#00#000000
Current SID is 001 or 002.
Given a valid slapcat from OpenLDAP 2.3 you should be able to slapadd it
directly in 2.4 without using -S or -w in your step #3. Therefore you
don't need step #4.
Ok.
Then I misunderstood your post:
http://www.openldap.org/lists/openldap-technical/200911/msg00066.html
I read it as the SID of "00" from 2.3 was not a correct CSN from a 2.4
backup.
No idea what that is. Your debug logs should tell what it was doing.
I've tried a lot of loglevels and look for anything suspicious.
I noticed (as I mentioned) this:
bdb_index_read: failed (-30989)
... and another thing I find weird.
The last entry in the LDIF is special in the log, like:
=======================================================
Dec 4 14:14:30 server1 slapd[5433]:<=
bdb_dn2id_children("cn=me,ou=3,uid=apm,o=net,cn=data,dc=example,dc=com"):no
(-30989)
Dec 4 14:14:30 server1 slapd[5433]: Entry
cn=me,ou=3,uid=apm,o=net,cn=data,dc=example,dc=com changed by peer, ignored
Dec 4 14:14:30 server1 slapd[5433]: send_ldap_result: conn=1004 op=1 p=3
Dec 4 14:14:30 server1 slapd[5433]: send_ldap_result: err=0 matched=""
text=""
Dec 4 14:14:30 server1 slapd[5433]: syncprov_search_response:
cookie=rid=003,sid=001,csn=20091204141336.982142Z#000000#001#000000
========================================================