New Install - empty mboxgroup1 database, can't open zimbraAdmin page

[Centurion]

Sorry for the long title, but it's been a long day. I am trying to install the OSS version of Zimbra on a fresh CentOS-4.4 server to evaluate the suitability of Zimbra. The installer goes fine, with no obvious errors, however, after the installation is complete, the mboxgroup1 database is totally empty:

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mboxgroup1         |
| mysql              |
| test               |
| zimbra             |
+--------------------+
5 rows in set (0.00 sec)

mysql> use mboxgroup1;
Database changed
mysql> show tables;
Empty set (0.00 sec)

This seems to be the root of the problem that is causing the zimbraAdmin page to fail to load. The login screen appears, I can enter the admin@our.domain user with correct password, but the login just hangs with "Loading...". If I enter the incorrect password, it returns with an "Authentication Failed" message. So it appears authentication is working.

The the /opt/zimbra/log/mailbox.log reports:

2007-04-27 15:55:58,203 INFO  [http-7071-Processor49] [ua=ZimbraWebClient - FF2.0 (Linux)/undefined;ip=10.10.10.74;] cache - Initializing folder and tag caches for mailbox 1
2007-04-27 15:55:58,205 WARN  [http-7071-Processor49] [ua=ZimbraWebClient - FF2.0 (Linux)/undefined;ip=10.10.10.74;] session - failed to create session
com.zimbra.common.service.ServiceException: system failure: fetching folder data for mailbox 1
        at com.zimbra.common.service.ServiceException.FAILURE(ServiceException.java:175)
...
stacktrace continues
...

Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'mboxgroup1.mail_item' doesn't exist

Query being executed when exception was thrown:

SELECT mi.id, mi.type, mi.parent_id, mi.folder_id, mi.index_id, mi.imap_id, mi.date, mi.size, mi.volume_id, mi.blob_digest, mi.unread, mi.flags, mi.tags, mi.subject, mi.name, mi.m
etadata, mi.mod_metadata, mi.change_date, mi.mod_content FROM mboxgroup1.mail_item mi WHERE mailbox_id = 1 AND type IN (1,2,13,3)
...
stack trace continues
...

Any idea where things have gone awry? The server is a slightly "minimalistic" install (we build up as a rule, rather than installing everything and working backwards) although all the installation requirements as set out in the various installation guides have been met. Hardware is almost double the specifications set out for a single-server setup. I've doubled the innodb_buffer_pool to 1GB and removed all references to "UTF8" in /etc/sysconfig/i18n (both of which seem to have resolved this problem in other threads).

[jholder]

Try to uninstall, then do a clean install. If it goes wrong, post your log file so that we can see what it kicks out when it creates the table.

[Centurion]

Thanks for your prompt reply - this bodes well for future commercial undertakings with Zimbra

As requested, we carried out a full uninstall (including manually removing /opt/zimbra). Rebooted and restarted the installation. The install logs and some information about the system are included (see attached).

Please note, our standard installation (kickstart) scripts create a 512MB /tmp partition which requires us to "fudge" the install; we simply unmounted the /tmp partition.This meant the /tmp directory became part of / (sda2) and thus had over 6GB for the install.After the installation we copied out the logs, rebooted and remounted /tmp.

Also, I've added a "txt" extension to the logs to make sure they get around the limits for attachments.

[jholder]

Wow. You've got a lot of tmp errors in there. For example:
* Loading schema /opt/zimbra/db/loggerdb.sql
/opt/zimbra/libexec/zmloggerinit: line 79: /tmp/logger.sql.9612: No such file or directory
/opt/zimbra/libexec/zmloggerinit: line 86: /tmp/logger.sql.9612: No such file or directory

Can't import the sql file for the logger, cause it's not there.

What ever the problem is, I'm willing to bet money it's because of your tmp setup. Is there any way you can allocate more space for that without "fudging" it?

That's the problem.

[Centurion]

Some more infomation - I've attached the mailbox.log which includes the first time the system was started (post-install and prior to reboot), followed by the logs after the reboot. The server was rebooted around 8:58am. There seems to be a LOT of database errors immediately after installation, which aren't present after the reboot. Did everything get initialised properly?

The log also includes two login attempts as "admin@..." but each time creates a different error, although the second error is repeated on subsequent logins (so I didn't include those - the error is the same as my original post).

So long story short - so far, same problem

[Centurion]

As for allocating more space to /tmp....erm, not without a rebuild Our test machines don't have SAN storage and unless required don't use LVM etc. So dynamically adding space is out of the question. The server is only a test machine, and a rebuild doesn't take long, but it does require me to be in front of the box (no remote "lights-out" management on test boxes either).

I can't see how a dedicated /tmp partition is any different to a shared partition (ie, part of "/"). But I'm willing to go down the rebuild road if it will rule out possible errors.

For what it's worth, the installation is carried out in a root shell invoked with sudo: "sudo -H -s" - ie, load a root shell, and root's home environment. Should we be using "su -" or a direct root login?

A rebuild will have to wait to Monday as I'm not going to work on the weekend for a test system I was hoping this was a remotely-fixable problem. C'est la vie.

[Klug]

Originally Posted by Centurion

I can't see how a dedicated /tmp partition is any different to a shared partition (ie, part of "/"). But I'm willing to go down the rebuild road if it will rule out possible errors.

It's not different, as long as it's correctly "mounted".

Just to be sure you /tmp is usable, maybe you should try to copy the ZCS install archive in it, untar the archive in it and launch it from there. This would help in checking /tmp is writable, has space in it, etc.

Originally Posted by Centurion

For what it's worth, the installation is carried out in a root shell invoked with sudo: "sudo -H -s" - ie, load a root shell, and root's home environment. Should we be using "su -" or a direct root login?

I'm sure it works with "su -" or direct root login, maybe sudo is the problem (concerning /tmp access and writability).

Originally Posted by Centurion

I'm not going to work on the weekend for a test system

You lazy

Originally Posted by Centurion

C'est la vie.

Bah oui 8)

[dijichi2]

You could try fudging from the other end, it works much better in my experience.

Before you run the installer, edit util/utilfunc.sh, search for /tmp and change '-lt 1' to '-lt 0'. The disk space check is relatively new in the installer (checks /opt for 5gc free, I have to disable that too). /tmp varies from platform to platform, sometimes it's part of root partition, sometimes seperate disk mount, sometimes a pseudo function of VM.

[Centurion]

Rebuilt the machine with a 1.5GB /tmp partition and carried out the installation using "su -". The install went through without a hitch and we are currently evaluating as I type.

Thanks to all who assisted with this over the weekend.