zmsetup.pl on Mac OS X Unhappy

[segleaur]

Hey guys, I've just gotten around to upgrading zimbra 4.0 to 4.5.4 for Mac OS X, due to a little too much work lately. Anyhow, the "easy install" went through without a problem, but when I run zmsetup.pl as root, of course, I zmsetup.pl spits out an error. It seems that this happens when the script tries to execute migrate20061101-IMFolder.pl. It tries to execute a SQL statement like:

INSERT INTO mboxgroup1.mail_item (
    mailbox_id, id, type, parent_id, folder_id, index_id, imap_id,
    date, size, volume_id, blob_digest,
    unread, flags, tags, sender,
    subject, metadata,
    mod_metadata, change_date, mod_content
)
SELECT
    id, 14, 1, 1, 1, null, null,
    1176313968, 0, null, null,
    0, 0, 0, null,
    'Chats', 'd1:ai1e4:unxti14e1:vi9e2:vti5ee',
    change_checkpoint, 1176313968, change_checkpoint
FROM mailbox
WHERE group_id = 1
ON DUPLICATE KEY UPDATE subject = 'Chats';

to which mySQL responds:

Cannot add or update a child row: a foreign key constraint fails (`mboxgroup1/mail_item`, CONSTRAINT `fk_mail_item_parent_id` FOREIGN KEY (`mailbox_id`, `parent_id`) REFERENCES `mail_item` (`mailbox_id`, `id`))

And the script goes nuts, interpreting that error as a command:

sh: line 1: mboxgroup2/mail_item: No such file or directory
sh: line 1: fk_mail_item_parent_id: command not found
sh: line 1: mailbox_id: command not found
sh: line 1: parent_id: command not found
sh: line 1: mail_item: command not found
sh: line 1: mailbox_id: command not found

Died at /opt/zimbra/libexec/scripts/Migrate.pm line 365, 
 line 15.
Script failed with code 2304:  - exiting
UPGRADE FAILED - exiting

Because, obviously, mboxgroup2/mail_item does not exist as a directory.

So, my question is: is there a workaround for this or do I have to do a stepping upgrade from 4.0 to 4.5.x where x < 5?

[jholder]

Are you switching to bash root?

[segleaur]

Yup. Total sequence to log in to the term is:

x:~ admin$ su - root
Password:
x:~ root# cd /opt/zimbra

If i need to be zimbra for a while, it's (as root)

x:/opt/zimbra root# su zimbra
x:~ zimbra$

Edit: By the way, I ran the zmsetup.pl again just to see what would happen, and the mboxgroup error is incremental, in the sense that the first time it ran, it was mboxgroup1, second run is mboxgroup2, and so forth. Didn't notice it the first time, sorry.

[jholder]

Try sudo /bin/bash
then /opt/zimbra/libexec
./zmsetup.pl

[segleaur]

No joy, J. Same error sequence.

[jholder]

My advice is to upgrade to the NE on the same version.
Then run backup.
And restore.

jh

[segleaur]

Any implications? 4.0 was OSS version, not NE. I'm guessing I could still run NE with it's functions disabled post trial-license? Or should I try upgrading from 4.0 to 4.5.1 and then to 4.5.4?

[jholder]

Well, Brian is the expert on this, so I'm blowing hot air.
I think there may be some db corruption, so if you can get your data out, and into a fresh install, that would be best.

NE trial is a fully functional trial.

john

[segleaur]

OK, so I have these nice large tar files on drive (backup before upgrade) and several sitting around on DATs. Soooooo, if I were to do a fresh reinstall (i'm testing to see if a stepped upgrade works as we "speak"), what files do I have to worry about and how I do make sure the InnoDB files are intact? Note that the tar files are full backups of the entire environment offline - so I would have to recreate the 4.0 environ, dump, install 4.5.4 and import?

[jholder]

Did you just tar up /opt/zimbra?