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