It's possible you got hit bug bug similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625484
Could you downgrade the libdb4.7 version to squeeze and run the upgrade script again? Ondřej Surý On 10. 5. 2013, at 19:10, Agustín Eijo <ae...@mpba.gov.ar> wrote: > Now, is: > > # dpkg -l | grep db4.7-util > ii db4.7-util 4.7.25-21 amd64 Berkeley v4.7 > Database Utilities > > db4.7-util configure first and then cyrus-common-2.4 (in apt-get dist-upgrade) > > Before, I didn't have db4.7-util. I had only libdb4.7 (4.7.25-9). db4.7-util > was installed as new in apt-get upgrade whith wheezy source.list > > > Agustín > PD: Excuse my English > > > > El 10/05/13 13:13, Ondřej Surý escribió: >> What was and is your db4.7-util version? >> >> Ondřej Surý >> >> On 10. 5. 2013, at 17:32, Agustín Eijo<ae...@mpba.gov.ar> wrote: >> >>> Hi, >>> >>> I had the same problem... >>> >>> Only restore old database directory /var/lib/cyrus and file >>> /usr/lib/cyrus/cyrus-db-types.active >>> >>> #cat /usr/lib/cyrus/cyrus-db-types.active >>> ANNOTATION skiplist >>> DBENGINE BerkeleyDB4.7 >>> DUPLICATE berkeley-nosync >>> MBOX skiplist >>> PTS berkeley >>> QUOTA quotalegacy >>> SEEN skiplist >>> SUBS flat >>> TLS berkeley-nosync >>> >>> I try running upgrade-db with set -x and I think the error could have been >>> the next: >>> >>> db4.7_recover: Build signature doesn't match environment >>> >>> Attach a full output in upgrade-db.txt >>> >>> Thank, Agustín. >>> >>> >>> >>> >>> >>> El 09/05/13 15:59, Ondřej Surý escribió: >>>> On Thu, May 9, 2013 at 4:18 AM, Ben Hutchings<b...@decadent.org.uk> >>>> wrote: >>>>> On Mon, 2013-05-06 at 07:23 +0200, Ondřej Surý wrote: >>>>>> I still miss the answer for: >>>>>> >>>>>>>> Could you check the permissions on /var/lib/cyrus and it's contents? >>>>> This is from the full system backup that ran just before the upgrade: >>>> [...] >>>> >>>> I see nothing wrong in here. >>>> >>>>>> And could it be that you ran out of free space in /tmp? >>>>> It's a tmpfs which appears to to have a capacity of 2G (there is 4G of >>>>> swap, barely used). I don't know how much free space it had during the >>>>> upgrade, of course. >>>> That might be the reason. Your deliver databases very quite big, maybe >>>> I just should stay on the same filesystem for the migration. >>>> >>>>>> I have tested the migration script throughly, but there still might be >>>>>> some corner cases unhandled. >>>>> Well, note that migration was triggered by running the init script >>>>> 'status' action (which is itself a bug - only 'start' should do that) >>>>> while the upgraded package was in the unpacked state. Are you sure that >>>>> doesn't make a difference? >>>> Could you please fill a separate bug report (I am sitting at the >>>> Windows machine right now, which makes me pretty useless). >>>> >>>>>> Well, it would help me to understand what has happened if I could test >>>>>> with real data. So, yes, it would be nice to lay my hands on full >>>>>> backup. >>>>> [...] >>>>> >>>>> I'm afraid these databases seem to include private information that I am >>>>> not prepared to disclose. >>>> I understand. >>>> >>>>> How about I try restoring the system backup on some other machine and >>>>> re-run the upgrade with 'set -x' added to upgrade-db? >>>> That would be great. I just need to know what has happened to fix it :(. >>>> >>>> O. >>>> -- >>>> Ondřej Surý<ond...@sury.org> >>>> >>>> -- >>>> To unsubscribe, send mail to706862-unsubscr...@bugs.debian.org. >>>> >>>> >>>> >>>> -- >>>> Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente. >>> >>> >>> -- >>> Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente. >>> >>> <upgrade-db.txt> >> >> -- >> Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente. > > > > > -- > Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente. >
