Description of problem: nstalling openldap-servers-2.4.33-1.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ######################################################################################################### Stopping ldap (via systemctl): [ OK ] Warning: no db_recover available for /var/lib/ldap-kolab Migrating pre-OpenLDAP-2.4 data Making a backup of dc=localhost,dc=localdomain to ldif file /var/lib/ldap-kolab/rpm-migrate-to-2.4.ldif slapcat: error while loading shared libraries: libdb-5.1.so: cannot open shared object file: No such file or directory touch: cannot touch â/var/lock/subsys/slapdâ: No such file or directory error: %pre(openldap-servers-2.4.33-1.mga3.x86_64) scriptlet failed, exit status 1 error: openldap-servers-2.4.33-1.mga3.x86_64: install failed Version-Release number of selected component (if applicable): current cauldron, 2.4.33 How reproducible: every time I do an urpmi --auto-update BTW, a few recent updates were done to this package, but we still have a of %if %mdkversion >= xxxx in it
Assignee: bugsquad => bgmilne
1)Note that this is your un-upgraded slapd that is looking for a libdb-5.1.so that is not present, not the one from the package you are upgrading to. How did you manage to get into this situation? rpm -q openldap-servers lib64db5.1 rpm -qR openldap-servers|grep db 2)I am maintaining the package so that it is usable in Mandriva. I would have been maintaining it in Mandriva, if their admins didn't decide to remove my email account for no valid reason ... I don't know why you are looking in the spec when you haven't first looked at your system ... These other messages are suspicious as well: Warning: no db_recover available for /var/lib/ldap-kolab Migrating pre-OpenLDAP-2.4 data Making a backup of dc=localhost,dc=localdomain to ldif file /var/lib/ldap-kolab/rpm-migrate-to-2.4.ldif Can you provide the output of: /usr/sbin/slapd -VV 2>&1|while read a b c d e;do case $d in (2.4.*) echo nomigrate;;(2.*) echo migrate;;esac;done And: /usr/sbin/slapd -VV
Status: NEW => UNCONFIRMEDEver confirmed: 1 => 0
How did you manage to get into this situation? I upgraded from mga2 to cauldron about a week ago rpm -q openldap-servers lib64db5.1 openldap-servers-2.4.29-2.1.mga2 package lib64db5.1 is not installed # rpm -qR openldap-servers|grep db db51-utils db51-utils db51-utils = 5.1.25 libdb-5.1.so()(64bit) libodbc.so.2()(64bit) /usr/sbin/slapd -VV 2>&1|while read a b c d e;do case $d in (2.4.*) echo; nomigrate;;(2.*) echo migrate;;esac;done [root@localhost ~]# # /usr/sbin/slapd -VV /usr/sbin/slapd: error while loading shared libraries: libdb-5.1.so: cannot open shared object file: No such file or directory [root@localhost ~]# I can remove manually the openldap-servers-2.4.29 and then do an urpmi openldap-servers and all is solved (except a small error massage like # urpme openldap-servers To satisfy dependencies, the following 2 packages will be removed (4MB): openldap-extra-schemas-1.3-13.mga1.noarch (due to missing openldap-servers) openldap-servers-2.4.29-2.1.mga2.x86_64 (due to unsatisfied openldap-extra-schemas >= 1.3-7, due to unsatisfied openldap-extra-schemas >= 1.3-7) Remove 2 packages? (y/N) y removing openldap-extra-schemas-1.3-13.mga1.noarch openldap-servers-2.4.29-2.1.mga2.x86_64 ldap.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig ldap off removing package openldap-servers-2.4.29-2.1.mga2.x86_64 warning: /etc/sysconfig/ldap saved as /etc/sysconfig/ldap.rpmsave warning: /etc/openldap/slapd.conf saved as /etc/openldap/slapd.conf.rpmsave Redirecting to /bin/systemctl condrestart rsyslog.service removing package openldap-extra-schemas-1.3-13.mga1.noarch writing /var/lib/rpm/installed-through-deps.list Then # urpmi openldap-servers To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") openldap-extra-schemas 1.3 13.mga1 noarch (medium "Core Release (distrib32)") openldap-servers 2.4.33 1.mga3 x86_64 6MB of additional disk space will be used. 1.9MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) y [#1 SIZE:16.0KiB/44.0KiB(36%) CN:1 SPD:51.1KiBs] 2012-10-29 21:03:24.421554 NOTICE - Download complete: /var/cache/urpmi/partial/openldap-extra-schemas-1.3-13.mga1.noarch.rpm [#2 SIZE:16.0KiB/1.9MiB(0%) CN:1 SPD:72.5KiBs ETA:26s] [#2 SIZE:496.0KiB/1.9MiB(25%) CN:1 SPD:325.4KiBs ETA:4s] [#2 SIZE:1.2MiB/1.9MiB(66%) CN:1 SPD:515.6KiBs ETA:1s] 2012-10-29 21:03:28.175903 NOTICE - Download complete: /var/cache/urpmi/partial/openldap-servers-2.4.33-1.mga3.x86_64.rpm Download Results: gid|stat|avg speed |path/URI ===+====+===========+=========================================================== 1| OK| 59.8KiB/s|/var/cache/urpmi/partial/openldap-extra-schemas-1.3-13.mga1.noarch.rpm 2| OK| 587.3KiB/s|/var/cache/urpmi/partial/openldap-servers-2.4.33-1.mga3.x86_64.rpm Status Legend: (OK):download completed. installing openldap-extra-schemas-1.3-13.mga1.noarch.rpm openldap-servers-2.4.33-1.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ######################################################################################################### 1/2: openldap-extra-schemas ######################################################################################################### 2/2: openldap-servers ######################################################################################################### Stopping ldap (via systemctl): [ OK ] Starting ldap (via systemctl): [ OK ] Redirecting to /bin/systemctl condrestart rsyslog.service ldap.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig ldap on
Something during your upgrade resulted in dependencies for your installed openldap-servers not being satisfied. As such, this looks like a bug in whatever you used to ugprade (urpmi/perl-URPM) removing whatever satisfied the dependency libdb-5.1.so()(64bit) before upgrading openldap-servers (from a version that required it, to a version that required the 5.3 version). I am going to resolve as WORKSFORME, but you may want to consider re-opening and assigning to urpmi or perl-URPM if you have useful information from the upgrade.
Status: UNCONFIRMED => RESOLVEDResolution: (none) => WORKSFORME