Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 48

Thread: Upgrade from 7.2.0 to 8.0 fail with ldap error

  1. #11
    Join Date
    May 2010
    Posts
    272
    Rep Power
    5

    Default

    hey thats intresting, could not remeber change those values, but it looks like i did, i guess it was with tuning.

    ok very much thanks iam gonna try that in the night

  2. #12
    Join Date
    Sep 2012
    Posts
    3
    Rep Power
    3

    Default

    Hi all,

    This might help some other folks out there:

    Restoring existing configuration file from /opt/zimbra/.saveconfig/localconfig.xml...done
    Operations logged to /tmp/zmsetup.09222012-162307.log
    Upgrading from 7.2.0_GA_2669 to 8.0.0_GA_5434
    Stopping zimbra services...done.
    Starting mysql...done.
    This appears to be 7.2.0_GA
    Error: /opt/zimbra/data/ldap/ldap.bak is empty
    UPGRADE FAILED - exiting.

    For some reason, my ldap.bak was being overwritten during installation/backup , and my solution was to copy the original timestamped backup after the upgrade process indicated:

    The system will be modified. Continue? [N] y

    Shutting down zimbra mail

    ***Backing up the ldap database...done.

    Removing existing packages

    zimbra-ldap...done
    zimbra-logger...done
    zimbra-mta...done

    cp /opt/zimbra/data/ldap/ldap.bak.20120922145210 /opt/zimbra/data/ldap/ldap.bak

    Hope that makes sense :-)

    -M

  3. #13
    Join Date
    May 2010
    Posts
    272
    Rep Power
    5

    Default

    Quote Originally Posted by Albin Mujkic View Post
    I had the same problem and it is not certificate related.

    The problem was that i have changed ldap settings:
    ldap_common_threads,ldap_common_toolthreads,ldap_d b_cachesizeldap_db_idlcachesize,ldap_cache_domain_ maxsize
    by following OpenLDAP Performance Tuning instructions (OpenLDAP Performance Tuning - Zimbra :: Wiki).

    I had set the ldap settings to default again:

    su - zimbra
    zmlocalconfig -e ldap_common_threads=8
    zmlocalconfig -e ldap_common_toolthreads=1
    zmlocalconfig -e ldap_db_cachesize=10000
    zmlocalconfig -e ldap_db_idlcachesize=10000
    zmlocalconfig -e ldap_cache_domain_maxsize=100

    zmcontrol restart

    and upgrade to 8.0 finished successfully.

    For multinode installation do this on ldap master and replicas to.

    Well id did change something, i cold a little mroe output now but it still fails at the same point.
    in addition if i try to run the slapp d command from the upgrade iam getting now also a segfault
    too bad..


    well at least it was a good test for our backup


    @ mchughs

    uhm wtf?

    youre shure you know what your doing?

    as far i know tehy use the ldap.bak file to create the new ldap files based on the conversion.
    so now simply renaming it wont do much alone , you still have to upgrade the ldap directory or you may run into serisous - baremettal restore - trouble


    what youve done after renaming your files?



    pS: upgrade from 7.2 to 7.21 was flawless as usual - 8.0 seems really wierd, maybe to much upgrade at once

  4. #14
    Join Date
    May 2010
    Posts
    272
    Rep Power
    5

  5. #15
    Join Date
    Sep 2012
    Posts
    3
    Rep Power
    3

    Default

    Quote Originally Posted by bofh View Post
    Hi bofh,

    I apologize for not being clear about the issue. The ldap backup portion of the upgrade from 7.2 to 8.0 overwrites
    the ldap.bak, BEFORE updating it. Hence a bug report is an appropriate action.

    -mchughs

  6. #16
    Join Date
    May 2010
    Posts
    272
    Rep Power
    5

    Default

    Yes it does, at least i suspected that.

    Well if i do the upgrade first time i got an .bak file generated, if i do it a second time its gone too, still replacing it wont save the issue cause i cannot upgrade it
    if i try todo the upgrade manually by slapp command im getting a segfault

    maybe theres an additional ldap settings needs to be tweaked back to default.
    hopefully we get osme more info from the bugzilla

  7. #17
    Join Date
    Sep 2012
    Posts
    3
    Rep Power
    3

    Default

    Gotcha, you might want to check the directory where ldap.bak is stored... On my server, the upgrade script made an initial backup and added a timestamp like so ldap.bak.XXXXXXX .

    Once I noticed that, I just opened two shells and restored the ldap.bak from the latest correct timestamped one and viola, the entire process completed successfully. The server is up and running perfectly now.

  8. #18
    Join Date
    May 2010
    Posts
    272
    Rep Power
    5

    Default

    Quote Originally Posted by mchughs View Post
    Gotcha, you might want to check the directory where ldap.bak is stored... On my server, the upgrade script made an initial backup and added a timestamp like so ldap.bak.XXXXXXX .

    Once I noticed that, I just opened two shells and restored the ldap.bak from the latest correct timestamped one and viola, the entire process completed successfully. The server is up and running perfectly now.


    hmp again, no that does not work.
    the ldap.bak.timestamp is the backup bevore it get upgraded.
    the problem is that the update script try to issue a slapp command (as shown in the log) in order to succesfully upgrade it.
    this script segfaults when its executed, not because of an emtpy bak (its there nad its fine) but during the ldap upgrade it segfaults.


    after setting ldap to defaults it segfaults just later so i get a bit more of the new structure, but it still segfaults

  9. #19
    Join Date
    Sep 2012
    Posts
    2
    Rep Power
    3

    Default

    Quote Originally Posted by Albin Mujkic View Post
    I had the same problem and it is not certificate related.

    The problem was that i have changed ldap settings:
    ldap_common_threads,ldap_common_toolthreads,ldap_d b_cachesizeldap_db_idlcachesize,ldap_cache_domain_ maxsize
    by following OpenLDAP Performance Tuning instructions (OpenLDAP Performance Tuning - Zimbra :: Wiki).

    I had set the ldap settings to default again:

    su - zimbra
    zmlocalconfig -e ldap_common_threads=8
    zmlocalconfig -e ldap_common_toolthreads=1
    zmlocalconfig -e ldap_db_cachesize=10000
    zmlocalconfig -e ldap_db_idlcachesize=10000
    zmlocalconfig -e ldap_cache_domain_maxsize=100

    zmcontrol restart

    and upgrade to 8.0 finished successfully.

    For multinode installation do this on ldap master and replicas to.
    I can confirm this is working for me. No errors in migration process after resetting those defaults !

  10. #20
    Join Date
    Mar 2007
    Posts
    8
    Rep Power
    8

    Default

    for me the IM is critiacal, and it work in 7.2.0.

    after the 8.0 upgrade do you still have do IM working?

Similar Threads

  1. Upgrade from 6.0.10NE to 7.0.0 fails with LDAP error.
    By Angrysmiley in forum Installation
    Replies: 5
    Last Post: 08-19-2011, 11:51 AM
  2. [SOLVED] Upgrade from 5.0.20 to 6.0.2 LDAP error
    By johjoh2k in forum Installation
    Replies: 4
    Last Post: 11-25-2009, 05:50 PM
  3. Upgrade Fail from 6.0.1 to 6.0.2
    By stich86 in forum Migration
    Replies: 2
    Last Post: 10-29-2009, 11:30 AM
  4. [SOLVED] Upgrade from 5.0.7 to 5.0.9 Mac Fail
    By BarefootPanda in forum Installation
    Replies: 0
    Last Post: 08-25-2008, 08:43 AM
  5. All cronjobs fail after upgrade
    By linmar in forum Administrators
    Replies: 2
    Last Post: 06-30-2007, 07:01 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •