Bug#706862: Database destroyed during upgrade from squeeze

[Agustín Eijo]

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<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 to706862-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>
>
> --
> Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente.
>




--
Piense antes de imprimir. Ahorrar papel es cuidar el medio ambiente.