[SOLVED] Here goes nothing...

[Baylink]

I'm upgrading 5.0.18 to 6.0.2 under a live install. Aren't weekends great?

I have lots of disk space, so I rsynced my entire /opt/zimbra directory (265GB; yes, that takes a long time) from one partition to another, and I'm doing the upgrade there, after moving my symlink. If it blows up, I move the symlink back, unblock the server, and go.

I like fast backouts.

So, first it complains that my hosts file is screwed up -- and so it is. Not sure how that got missed in the machine move back in June. Fixed.

Next, it can't find sysstat. easy enough.

Then it complains that it can't find the license. That could be troublesome, but we'll forge ahead.

It doesn't like not seeing a full backup, but in fact it did one Friday night, and I'm pretty sure *an entire freaking copy of the install* is good enough. :-)

Verifying database integrity does in fact take a long time. And it's *now* that I discover I forgot to start screen(1) before I started the upgrade. Crap. I'm not dumping while it's stirring databases, readonly or not. I'll wait.

More to follow...

[Baylink]

I should note that the system is publicly accessible only through a reverse proxy on my firewall... which has been rewritten to point to a local page on the firewall saying "I'm upgrading the frickin' mail server; take a pill".

Ok, maybe not *quite* that wording... :-)

I've also cut the incoming POP, IMAP and SMTP ports so I can control the new install during testing, in case something breaks, and I have to swap out; I won't lose any mail that way.

[Baylink]

I was wrong, it turns out; I *was* under screen, which is good, cause my ssh link died.

No errors, found all packages, ready to upgrade.

The prompt about "clean install" *really* should note that a clean install will wipe not only your old code, but *your mailboxes and configs*, too... unless there's another prompt after it that does that.

Next up is the platform-override switch.

*PLEASE MOVE THIS CHECK TO THE TOP OF THE SCRIPT*. Thank you. That is all.

(Yes, I'll hang a bug.)

"The system will be modified" should probably also be replaced with something like "We're now ready to begin the upgrade"/however it's phrased for a clean install.

I see that whatever 4-layer-deep problem I used to have with the script doing the shutdown is now fixed. :-)

later: No, it wasn't. Let me go find that old thread.

[Baylink]

Alas, copying in the libphp5.so from the distro didn't help. 6.0.2 has *two* different httpd's in it, maybe I picked the wrong one.

No; 2.2.11 is from the upgrade, and I wasn't careful enough when trying to copy in the one from the distro (which is, incidentally, 1/5 the size of the one in the install package). I've made sure that it *actually* copied in this time, and am rerunning.

[Baylink]

And, apparently, if you try to *rerun the install*, it will just break it again. You have to *find the context for zmsetup*, and just run that manually.

[Baylink]

Which context is mostly that it wants to be root, cause it will su to zimbra on its own.

Got my schema all the way to 63...

And it can't find a valid backup file. Cause, sure, it was clear when it asked me that question, that *that was why it wanted to know*.

Nerdview. That's what it is.

The upgrade procedures *really* need to be tested by Smart People Who Don't Work For You, guys, cause that's the definition of your customers.

And, look! There's the full backup that *I knew it had created*, from 0415 *today*, right there in the backups/sessions directory. Why can it not find that, I wonder?

[Baylink]

The tail of my zmsetup.log. Can't get the whole thing cause screen doesn't allow easy scrollback.

Sat Nov 14 23:04:23 2009 Running /opt/zimbra/libexec/scripts/migrate20090315-MobileDevices.pl
Sat Nov 14 23:04:24 2009 Sat Nov 14 23:04:24 2009: Verified schema version 60.
Sat Nov 14 23:04:24 2009 Sat Nov 14 23:04:24 2009: Adding ZIMBRA.MOBILE_DEVICES table.
Sat Nov 14 23:04:25 2009 Sat Nov 14 23:04:25 2009: Verified schema version 60.
Sat Nov 14 23:04:25 2009 Sat Nov 14 23:04:25 2009: Updating DB schema version from 60 to 61.
Sat Nov 14 23:04:25 2009 Running /opt/zimbra/libexec/scripts/migrate20090406-DataSourceItemTable.pl
Sat Nov 14 23:04:26 2009 Sat Nov 14 23:04:26 2009: Verified schema version 61.
Sat Nov 14 23:05:31 2009 Sat Nov 14 23:05:31 2009: Verified schema version 61.
Sat Nov 14 23:05:31 2009 Sat Nov 14 23:05:31 2009: Updating DB schema version from 61 to 62.
Sat Nov 14 23:05:31 2009 Running /opt/zimbra/libexec/scripts/migrate20090430-highestindexed.pl
Sat Nov 14 23:05:32 2009 Sat Nov 14 23:05:32 2009: Verified schema version 62.
Sat Nov 14 23:05:32 2009 Sat Nov 14 23:05:32 2009: Adding idx_deferred_count column to Mailbox table.
Sat Nov 14 23:05:33 2009 Sat Nov 14 23:05:33 2009: Verified schema version 62.
Sat Nov 14 23:05:33 2009 Sat Nov 14 23:05:33 2009: Updating DB schema version from 62 to 63.
Sat Nov 14 23:05:34 2009 Stopping mysql...
Sat Nov 14 23:05:34 2009 *** Running as zimbra user: /opt/zimbra/bin/mysql.server stop
Stopping mysqld... done.
Sat Nov 14 23:05:51 2009 done.
Sat Nov 14 23:05:51 2009 Valid backup file not found, exiting.
Sat Nov 14 23:05:51 2009 UPGRADE FAILED - exiting.

[Baylink]

The error message appear to be coming from zmupgrade.pl::migrateLdap, but the context is hirsute enough I'm not going to be able to get it sussed without help...

[JoshuaPrismon]

The error message appear to be coming from zmupgrade.pl::migrateLdap, but the context is hirsute enough I'm not going to be able to get it sussed without help...

It looks to me like it's trying to restore the configuration backup, not a system/mail backup. I would open a ticket with Zimbra support - this does not look normal, and I've never seen it before.

[Baylink]

I wonder if they work Sunday mornings. :-)

Thanks, Josh; I'll do that.