Failing upgrade from 6.0.10 to 7.0 Ubuntu server 8.04.4 LTS 32-bit multiserver

[phoenix]

No, as far as I understood from original post, and searched for other bug reports, I could not find any. The problem was connected with availability to select my relevant timezone - there were no # available in a list for our region. And after finishing upgrade script, configuration screen was presented, stating, that I have to setup Timezone, which was setup before and now on 6.0.10.

OK, so your scenario is this (as I understand it): You had a timezone set in your previous install of Zimbra; you ran the upgrade and the timezone was unset; your were unable to set the timezone because it doesn't exist in the list of available timezones. Would that be what happened?

If that's the case: what timezone are you in; did you not have this problem when you installed zimbra or ran the last upgrade; does your timezone exist in the list of available timezones in the Admin UI?

I assume you set it to another timezone to finish the install then changed it afterwards?

[tim_ba]

I also had a problem with timezone. It was set in previous 6.0.10 install of Zimbra; I ran the upgrade and the timezone was unset. I'm in Europe/Sarajevo, so I chose Europe/Belgrade.
Since I had other error messages, like in https://bugzilla.zimbra.com/show_bug.cgi?id=55541, I restored from backup, and I'll wait for 7.0.1.

[phoenix]

I also had a problem with timezone. It was set in previous 6.0.10 install of Zimbra; I ran the upgrade and the timezone was unset. I'm in Europe/Sarajevo, so I chose Europe/Belgrade.

You can file a bug report for that, if you like.

Since I had other error messages, like in https://bugzilla.zimbra.com/show_bug.cgi?id=55541, I restored from backup, and I'll wait for 7.0.1.

That's not necessary, the problem is fairly easy to spot and the fix is simple.

[j2b]

Yes, Bill, that what exactly happened in my case. I am in Europe/Riga (GMT +2). In former upgrades there were no such issues, although, I can not remember now, how it was on first install v5. Curently all servers are set to GMT +02:00 Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius, but after running upgrade - it asks to set timezone, but no any GMT+2 available. It seems that list is somehow shortened.

As in link from my first post, I changed server's timezone to London, but due to other problems, script didn't finished. I am waiting for my last users to disconnect, to go for another round of upgrade, as I solved certificate issue, which probably was a problem for deploying new deployments after v6, and afterward script didn't posessed info with new fields, etc.

[j2b]

Nope, upgrade didn't run. Despite idea, that the problem lied in SSL certificates, thus not allowing to connect ot LDAP server to implement new deployments - upgrade didn't go through at all. Recovered from backup again.

Step by step:

1. started ./install.sh on LDAP (only) server on multiserver installation (Ubuntu 8.04 LTS with latest updates and kernel upgrades - regular ones from Ubuntu. Server is a VM in ESX).

2. script found all correct installations (LDAP, SNMP, Zimbra-core).

3. checking prerequisites - informed about sqlite3, which was in section "...suggested prerequisites..."

4. ignored sqlite, as it is not relevant to LDAP, and was mentioned in posts, that ignoring it, installation goes through.

5. everything goes smooth as usual. After the following lines:

Updating from 7.0.0_BETA1
Updating from 7.0.0_BETA2
Updating from 7.0.0_BETA3
Updating from 7.0.0_RC1
Updating from 7.0.0_GA
Updating global config and COS's with attributes introduced after 6.0.10_GA...failed.
Stopping ldap...done.
Upgrade complete.

Here I can not understand last 3 lines. Or, by this I could say, that "Updating global config and COS's with attributes introduced after 6.0.10_GA...failed." is not vital for upgrade procedures. But show does not stop here. Script runs furher.

6. After:

Running bdb db_recover...done.
Running zmldapapplyldif...done.
Checking ldap status....already running.

Odd lines start to appear, which were not noticed before:

Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Setting defaults...Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
done.
Setting defaults from existing config...done.
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Checking for port conflicts
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
	at com.zimbra.common.util.Log.<clinit>(Log.java:44)
	at com.zimbra.common.util.LogFactory.getLog(LogFactory.java:50)
	at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLog.java:115)
	at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java:2875)
Setting defaults from ldap...done.

Due to notice - NoSuchFieldError, before I assumed, that it could be connected with new attributes, which are not installed and ...failed.

7. Configuration menu pops up, saying, that 1) Common configuration ***** +TimeZone UNSET

8. Moving deeper in settings 1 + Enter, gives Common configuration submenu, where TimeZone is under 6)

9. Hitting 6 + enter, stops upgrade script

Can't call method "tzid" on an undefined value at /opt/zimbra/libexec/zmsetup.pl line 2892, <> line 2.

FINITO!

As this is a production server, I didn't went any further with experimenting, and recovered data from backup. zmsetup-***.log file didn't get me any more clues. The following was noticed:

- All these Java errors stated above, without any other explanation.
- Where TimeZone settings where checked, the following is presented:

Tue Feb 15 01:32:27 2011 Local timezone detected as EET
Tue Feb 15 01:32:27 2011 Default Olson timezone name America/Los_Angeles

... which is odd, but OK. Then again, a bunch of Java errors, and final 4 lines are the following:

Tue Feb 15 01:34:24 2011 Loading default list of timezones.
Tue Feb 15 01:34:24 2011 Previous TimeZoneID 
Tue Feb 15 01:34:24 2011 Determining system locale.
Tue Feb 15 01:34:24 2011 DEBUG: Local tz name EET

Mainly all previous issues remain in force:
- new attributes does not get deployed and can not understand are they vital or responsible for these java errors.
- timezone issues remain too. For this time I didn't change server's timezone, remaining Europe/Riga, as I do not want to experiment with production server.

Can anybody from Zimbra assist in finding solutions on this?

[j2b]

No comments at all? It is odd, but first serious upgrade after VMware acquisition, and upgrades do not work any more This was not noticed before.

[j2b]

Any helpfull hints from Zimbra people at least to try to track down the possible cause, as logs do not say to me anything?

[tim_ba]

Same problems after a try to upgrade to 7.0.1. It may be the problem with our configuration.

[zimbra@ks5 ~]$ zmtzupdate
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
at com.zimbra.common.util.Log.<clinit>(Log.java:44)
at com.zimbra.common.util.LogFactory.getLog(LogFactor y.java:50)
at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLo g.java:115)
at com.zimbra.common.util.CliUtil.toolSetup(CliUtil.j ava:40)
at com.zimbra.common.util.CliUtil.toolSetup(CliUtil.j ava:36)
at com.zimbra.common.util.CliUtil.toolSetup(CliUtil.j ava:32)
at com.zimbra.cs.mailbox.calendar.FixCalendarTZUtil.m ain(FixCalendarTZUtil.java:74)

[zimbra@ks5 ~]$ zmprov gc default zimbraPrefTimeZoneId
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
at com.zimbra.common.util.Log.<clinit>(Log.java:44)
at com.zimbra.common.util.LogFactory.getLog(LogFactor y.java:50)
at com.zimbra.common.util.ZimbraLog.<clinit>(ZimbraLo g.java:115)
at com.zimbra.cs.account.ProvUtil.main(ProvUtil.java: 2923)

This should tell something, but... I read that log4j (you must have a stray log4j JAR file somewhere) or classpath (you have conflicting version of class org.apache.log4j.Level in your classpath) are mentioned for some similar problems, but I don't know if that has something with this.

[j2b]

@tim_ba. I could definately agree with you, that problem may be (and most probably is) in configuration. The hardest par on this issue is that no deep configuration changes, except the ones, which didn't influence this process for a years were made in our case. And there is a lack of information. At least for me.

Due to mostly no conversations in forum on these issues, and our necessity to migrate to different systems, including moving to 64-bit and Ubuntu 10.04 servers, I decided to go with fresh install, which in our case didn't end without issues. Currently allready for a month trying to migrate users' data with imapsync, regular Zimbra IMAP External accounts, etc, and all ways finish with errors. For me at current, the most actual issue is IMAP stability, as regular timeouts and errors come up. But as we still have to move, I am doing it by hand, comparing mailboxes, folders and counting e-mails, etc. Quite a nightmare, to say honestly. I would be happy to read and learn on my issues, but lack of deep understanding and connections between Zimbra and classic components, actualy leave with not so much choices.

[tim_ba]

According to the previous advice on this thread, I opened a bug https://bugzilla.zimbra.com/show_bug.cgi?id=56742.
But, I was wrong at the beginning because setting of timezone to Europe/Sarajevo is not a cause but a consequence of a problem that zmtzupdate and zmprov cannot be run after an upgrade to v7. And that might be a consequence of some other problem with our configuration. What's common for us is that we both have 32bit Zimbra v6 as a VM. In my case, it's Hyper-V on Windows 2008. Accordingly, title of this thread might be changed from "Failing upgrade from 6.0.10 to 7.0 Ubuntu server 8.04.4 LTS 32-bit multiserver" to "Failing upgrade from 6.0.x to 7.0.x in 32-bit VM"
My current intention is to try to upgrade to 64bit 6.0.12 and then further to 7.