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 to 706862-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> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
