Am Montag, 26. März 2007 11:02 schrieb Rainer Dorsch: > Am Montag, 26. März 2007 00:01 schrieb Steve Langasek: > > On Sun, Mar 25, 2007 at 04:52:24PM +0200, Rainer Dorsch wrote: > > > -> aptitude refused the upgrade: No soultion found for the conflicts > > > > > > open: 11182; closed: 4969; defer: 0; conflict: 3 > > > No solution found within the allotted time. Try harder? [Y/n] > > > > > > Not sure if aptitude from etch would have done better here. I went with > > > apt-get for the critical part. > > > > I don't suppose you have a /var/lib/aptitude/pkgstates from before the > > upgrade? I don't really expect a particular aptitude upgrade failure to > > be reproducible using just a package list. > > Julien mentioned that there might be a backup. I check that later....
Hmm...not sure, if aptitude.pkgstates1.gz is from before or after the upgrade. Uploaded it to http://www.alzental-castle.de/~rd/upgrade-to-etch/ for reference. silverboxy:/var/backups# ls -l insgesamt 9780 -rw-r--r-- 1 root root 1923090 2007-03-25 17:58 aptitude.pkgstates.0 -rw-r--r-- 1 root root 194694 2007-03-25 00:21 aptitude.pkgstates.1.gz -rw-r--r-- 1 root root 3487496 2007-03-25 20:40 dpkg.status.0 -rw-r--r-- 1 root root 716785 2007-03-25 00:20 dpkg.status.1.gz -rw-r--r-- 1 root root 716618 2007-03-23 22:50 dpkg.status.2.gz -rw-r--r-- 1 root root 716767 2007-03-11 21:22 dpkg.status.3.gz -rw-r--r-- 1 root root 716510 2007-03-07 22:28 dpkg.status.4.gz -rw-r--r-- 1 root root 716507 2007-02-25 22:43 dpkg.status.5.gz -rw-r--r-- 1 root root 716317 2007-02-14 23:11 dpkg.status.6.gz -rw------- 1 root root 1000 2007-03-25 12:53 group.bak -rw------- 1 root root 838 2007-03-25 12:53 gshadow.bak -rw-r--r-- 1 root root 2122 2006-12-04 12:02 inetd.conf.bak -rw-r--r-- 1 root root 2018 2005-01-19 09:34 inetd.conf.bak.0 -rw-r--r-- 1 root root 832 2004-12-09 22:05 inetd.conf.bak.1.gz -rw-r--r-- 1 root root 806 2004-12-03 09:17 inetd.conf.bak.2.gz -rw-r--r-- 1 root root 821 2004-08-25 19:34 inetd.conf.bak.3.gz -rw-r--r-- 1 root root 814 2004-08-01 13:15 inetd.conf.bak.4.gz -rw-r--r-- 1 root root 830 2004-06-05 01:14 inetd.conf.bak.5.gz -rw-r--r-- 1 root root 855 2004-02-04 20:25 inetd.conf.bak.6.gz -rw-r--r-- 1 root root 9760 2007-03-26 22:14 infodir.bak -rw------- 1 root root 2018 2007-03-25 12:53 passwd.bak -rw------- 1 root shadow 1418 2007-03-25 12:53 shadow.bak -rw------- 1 root root 2637 2003-03-14 23:12 smbpasswd.bak silverboxy:/var/backups# > > > -> postgres-client upgrade confused apt/dpkg completely. Installation > > > of all following packages failed > > > Preparing to replace postgresql-client 7.4.7-6sarge4 > > > (using .../postgresql-client_7.5.22_all.deb) ... > > > install: `/var/lib/postgres/dumpall/7.4': Not a directory > > > dpkg: warning - old pre-removal script returned error exit status 1 > > > dpkg - trying script from the new package instead ... > > > dpkg: error > > > processing /var/cache/apt/archives/postgresql-client_7.5.22_all.deb > > > (--unpack): > > > there is no script in the new version of the package - giving up > > > > Ok, so what is /var/lib/postgres/dumpall/7.4 on your system, and do you > > know how it got that way? It is a directory on my systems, which is what > > it's supposed to be. > > /var/lib/postgres was a file. I still have a copy of it. Can send it later. This one was originally /var/lib/postgres silverboxy:/var/lib# cat postgres.bak Package: postgresql-client Status: install reinstreq half-installed Priority: optional Section: misc Installed-Size: 1416 Maintainer: Oliver Elphick <[EMAIL PROTECTED]> Architecture: i386 Source: postgresql Version: 7.4.3-3 Config-Version: 7.4.3-3 Replaces: postgresql (<< 7.4) Depends: libc6 (>= 2.3.2.ds1-4), libkrb53 (>= 1.3.2), libpam0g (>= 0.76), libreadline4silverboxy:/var/lib# > > > Preparing to replace powernowd 0.90-3 > > > (using .../powernowd_0.97-1_i386.deb) ... > > > Stopping powernowd: powernowd. > > > install: `/var/lib/postgres/dumpall/7.4': Not a directory > > > > > > Why is powernowd worried about postgres/dumpall/7.4 ??? > > > > That would be a dpkg bug. I've seen this once before, in a certain > > corner cases dpkg fails to clean up the maintainer scripts from the > > previous package it was working with when that other package failed, and > > it ends up invoking the broken script by mistake. :/ > > > > I don't know if this has been filed as a bug against dpkg. > > I will check and open one, if I don't find one. Unfortunately I cannot > repro it any more. > I did not find a bug report. Submitted #416706 Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07032-359190 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/
