Bug#706862: Database destroyed during upgrade from squeeze

[Ondřej Surý]

What was and is your db4.7-util version?

Ondřej Surý

On 10. 5. 2013, at 17:32, Agustín Eijo <aeijo at 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<ben at 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ý<ondrej at sury.org>
>> 
>> --
>> To unsubscribe, send mail to 706862-unsubscribe at 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>