Daniel Burrows <[EMAIL PROTECTED]> writes: > On Sat, Aug 23, 2008 at 08:30:14PM +0200, Ferenc Wagner <[EMAIL PROTECTED]> > was heard to say: >> Daniel Burrows <[EMAIL PROTECTED]> writes: >>> 2. A typescript of the upgrade with "-o Debug::pkgDpkgPM=true" >>> added (both to get more debugging information and to see what >>> happened in the install sequence before slapd was removed). >>> If you're worried about messing up your system, you could >>> temporarily replace dpkg with a symlink to /bin/true. >> >> The system is already upgraded, so I can't easily provide a >> typescript (and was stupid not to record one in the first time). >> However, I can try reproducing the issue based on my backups if >> necessary. For the easy part, maybe this helps somewhat: > > The typescript would be very useful for this bug. I can make a few > guesses based on the dpkg log, but nothing definitive. > >> $ egrep 'libldap|slapd' /var/log/dpkg.log > > [snip] > >> 2008-08-21 13:48:15 status unpacked libldap2-dev 2.4.10-3 >> 2008-08-21 13:48:16 status installed libldap2 2.1.30-13.3 >> 2008-08-21 13:48:16 remove libldap2 2.1.30-13.3 2.1.30-13.3 > > I think this is where we remove libldap2; I'm not very familiar with > dpkg.log's format. > >> 2008-08-21 13:50:13 status installed libldap-2.4-2 2.4.10-3 >> 2008-08-21 13:50:34 status unpacked libldap2-dev 2.4.10-3 >> 2008-08-21 13:50:34 status half-configured libldap2-dev 2.4.10-3 >> 2008-08-21 13:50:34 status installed libldap2-dev 2.4.10-3 >> (next aptitude run) >> 2008-08-21 13:52:25 upgrade slapd 2.3.30-5+etch1 2.4.10-3 >> 2008-08-21 13:52:25 status half-installed slapd 2.3.30-5+etch1 >> 2008-08-21 13:52:28 status unpacked slapd 2.3.30-5+etch1 > > Do you mean the next time aptitude ran dpkg, or did you actually > tell aptitude a second time to install packages? > > I don't know if dpkg.log can tell you this, but did any packages > fail to install or configure between the two "runs"?
I tried the upgrade with aptitude, but that exited with an error, because it could not upgrade slapd: Errors were encountered while processing: libperl5.10 tomcat5.5-admin slapd perl apache2.2-common perl-modules apache2-mpm-prefork apache2-threaded-dev Then I restarted aptitude and retried the same operation. That happened at 13:51, as the aptitude log shows (that's why I included the prelude of the next run in that excerpt). That run was very short, of course, exiting at once with Preparing to replace slapd 2.3.30-5+etch1 (using .../slapd_2.4.10-3_i386.deb) ... Dumping to /var/backups/slapd-2.3.30-5+etch1: - directory dc=aai,dc=niif,dc=hu... slapcat: error while loading shared libraries: libldap_r-2.3.so.0: cannot open shared object file: No such file or directory failed. dpkg: error processing /var/cache/apt/archives/slapd_2.4.10-3_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/slapd_2.4.10-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Then I retargeted Etch, downgraded/replaced just enough packages to get slapd in a decent state, then removed it, and after this the upgrade finished without a single problem. Then I tried to install slapd, but that again didn't work as it could not import the database. >>> I doubt this is an aptitude bug -- most likely it has to do with >>> what arguments are being passed to dpkg, and that all lives in apt. >>> But I'm leaving this afternoon to go on vacation for a week, so >>> someone else may have to reassign it once we've confirmed that. >> >> Does the above confirm that? As a next step, I'd try installing a new >> Etch system with slapd and upgrade that. If that does not reproduce >> the problem, can you recommend a procedure to better approximate the >> original package state based on some status files from backup for >> example? > > I think it pretty much confirms this: particularly the fact that > aptitude believes that it's installing the required new package. That > means that at some point, the lower layers in apt are turning this into > two dpkg runs, and breaking them up in a way that doesn't respect > dependencies. I'm not quite sure, as the break corresponds to two aptitude runs. > Debugging output from apt would be an even stronger indication, but > I think that the logs you provided are good enough. I'll reassign this -- > maybe someone will have time to look into it, or maybe I can put my apt > hat on next week and try to solve it. > > If the bug is related to upgrading a package and simultaneously > removing one of its dependencies, That seems to sum it up nicely: slapd changed dependencies, and I elected to remove the old one. > one workaround would be to pass "-o Aptitude::Delete-Unused=true" > on the command-line for the upgrade, and then to run "aptitude > install" afterwards to clear out the unused packages. This wouldn't > actually fix the problem, but it would reduce the likelihood of it > cropping up until we have a proper fix. OK. -- Thanks, Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
