UPDATE: Upgrade/migrate from Kolab 2.1 SUSE Native install to OpenPKG 2.2.3 version DB problems Debian5

[Skip Morse]

I was able to fix the DB errors, instead of only copying the
mailboxes.db and annotations.db, I copied also, the whole db folder,
db.backup1, db.backup2, and the deliver.db and it's folder (and
changed to proper permissions after)...

I had a slight issue with a blank screen on horde, but i was able to
login with explorer, so I can try to piece that out...

My main concern at this point is that within horde, all mail is
showing as unseen, is this normal, or is there a way around this?  I
thought the seen info was held within each user's mail directory,
maybe that's not the case?




---------- Forwarded message ----------
From:  <skipmorse at gmail.com>
Date: Fri, Apr 23, 2010 at 3:53 PM
Subject: Upgrade/migrate from Kolab 2.1 SUSE Native install to OpenPKG
2.2.3 version  DB problems Debian5
To: kolab-users at kolab.org


Howdy all,

I thought I had worked my magic, but something has gone sideways,
hopefully someone can help.

I've somewhat successfully upgraded/migrated my install... Well, after
a lot of comparing files, testing and importing/exporting, I've hit a
snag...

After starting kolab 'openpkg rc all start', it seemed like things
were working as expected, I was able to login to the admin page and
all users, shared folder, distribution list etc... were there.

Then I tried logging into horde and the page seemed to just timeout,
so I started looking for logs...

in my /kolab/var/imapd/log/imapd.log, I'm getting a lot of these:

<warning> imap[6974]: DBERROR db4: file /kolab/var/imapd/mailboxes.db
has LSN 173/5203582, past end of log at 1/10193
<warning> imap[6974]: DBERROR db4: Commonly caused by moving a
database from one transactional database
<warning> imap[6974]: DBERROR db4: environment to another without
clearing the database LSNs, or removing
<warning> imap[6974]: DBERROR db4: all of the log files from a
database environment

I verified that the annotations.db and mailboxes.db were set to use
the berkeley format in imapd.conf and in the .template file.

This might be were I went wrong: I thought, since it was still in
'berkeley' format and was uncorrupted and would be reading from the
same mail spool, all should be fine if I just copied the file. I also
dumped it to a text file before, so I could use that if I have to.

The reason I did this is because we use the toltec connector, and long
ago I had some back and forth with Joon about upgrading the server and
shared folders 'uploading' from outlook as local folders per user. The
last word on that was that it would happen if the UUID of the folders
on the server changed. My GUESS is that maybe the UUID is stored in
the mailboxes.db, and if that's the case, I figured importing the dump
into a new db would change those values (I did reply to joon about the
possibility of retaining those values with no response).

Any ideas? Ultimately, I just need to keep the mail, and have the new
server see the same UUID's as the old so toltec doesn't start
uploading folders/messages. I can't really tell passed this point if
what I've done works other than this issue, but I 'feel' like I'm
close.

** also, there's nothing in that log about annotations.db which I also copied

-Skip