This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Postgres not starting after upgrade to 7.400

Hello,

i just started the up2date installation from 7.306 to 7.400 on our ASL.
After restarting, the system keeps hanging during startup when trying to start postgres sql.
Is there a bug in the 7.400 update? Has anybody any idea what to do to get the ASL running again without having to do a new installation?
This would be about the 10th time for me to reinstall ASL 7 since fall 2007. This product keeps making trouble very often. Before the installation of ASL 7 we used ASL 5 which was installed once and was running for 4 years without any problems. Are other users experiencing this kind of problems too?

Greetings
Jesko


This thread was automatically locked due to age.
Parents
  • According to the up2date release notes this is a database conversion occurring, looking at some other comments on the board may take longer for other systems than the 2 hours expected:

    From Up2Date Announcements: Known Issue - Initial bootup after 7.400 installation may take longer than expected

    After the successful installation of 7.400, the system needs to upgrade the reporting database during the next boot up. This process can take from few minutes up to two hours, during this process the system is not fully operational.

    The Duration of the upgrade procedure is directly dependent on the database size, which is larger on bigger systems. A customer with a 50GB reporting database needed 2 hours for the upgrade process.

    Please do not power down or restart the system during this process as in worst case it can cause data loss through database corruption and it will not speed up this process.
    If you have a system in that state, please just be patient, the system will boot up properly after the database upgrade has been finished

    In order to minimize the downtime cause by this, we suggest to schedule the installation to non-business hours.

    If you want to accelerate this process you can reduce the size of your database by deleting older entries.
    In order to do so, you need to change the Reporting Settings in 
    WebAdmin > Reporting > Settings > Settings > Reporting Settings.

    There you can disable reports you don't need as well as lower the duration how long reporting data is retained. The smaller you configure the duration, the less data will be in the database and the faster the upgrade process will be finished.

    After making changes to these settings, you have to wait at least 12-18 hours, as the database maintenance process runs twice a day, which than will do the reduction of the database size. During this process, the system is fully operational.

    If you have further question, please don't hesitate to contact your Astaro Partner or us directly.

    Best regards
    Gert Hansen
  • Thanks for the information. So I'll just have to be patient and will give it time until tomorrow morning beforde doing anything. Glad, I used the weekend for upgrading ;-))
  • I have the same problem, and didn't see the warning. If I have interrupted the reboot process and restarted again, will it come back up if I give it enough time? Is there any indication that it really is locked up and will not finish no matter how much time I give it?
  • It should recover.  Log into the Console or SSH and run TOP... you should see Postgres humming away... if you check the system log, you should see where the new tables, etc. are being added.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • Thanks for the information. So I'll just have to be patient and will give it time until tomorrow morning beforde doing anything. Glad, I used the weekend for upgrading ;-))


    Just for reference points; We have a Astaro Mail Gateway 2000. That one has a 30 day log retention in SQL. That box took 4.5 hours to upgrade the SQL databases. So be patient.
  • After waiting for more than 15 hours without any result my patience reached it's end and i grabbed the cd for reinstallation of ASL. Now ASL is running as 7.306 again and i'll try upgrading to 7.400 again without any log data, hoping this will work better.
    This kind of upgrading procedure doesn't look very practical to me. Which production environment can afford taking the internet connection offline for 5 hours or more even at the weekend?
  • jesko, why don't you use directly the v7.400 ISO??? Take a look at the Astaro FTP.

    Greets [:D]
  • Jesko, when you looked at it with top, did it show that PostgreSQL was busy?
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • @BAlfson: i couldn't run Top because Postgres was hanging during bootup and i found no possibility to log on to the console.

    @suzzyx: my latest configuration backup is 7.306 - i suppose this can not be restored directly under 7.400.
  • Astaro 7.400 is now up and running after new installation and update from 7.306 to 7.400.
  • Ratz, Thanks for your post.  I would have rebooted the 7.400 install if I didn't see it.  My installation took 6 hours and 13 minutes to get past the PostgreSQL point. I wish I had seen it earlier to delete much of the log data.
  • We are still working through these issues, additional information will be posted as soon as possible.  Systems with large databases do seem to be taking quite a while, and impatience has led a couple of users to additional problems (power cycling during the database conversion).

    We have temporarily withdrawn the 7.400 update and ask that you do not update any system manually until we resolve the isolated problems we have experienced.

    Please see the message at: Up2Date Announcements: Up2Date ASG 7.400 delayed
Reply
  • We are still working through these issues, additional information will be posted as soon as possible.  Systems with large databases do seem to be taking quite a while, and impatience has led a couple of users to additional problems (power cycling during the database conversion).

    We have temporarily withdrawn the 7.400 update and ask that you do not update any system manually until we resolve the isolated problems we have experienced.

    Please see the message at: Up2Date Announcements: Up2Date ASG 7.400 delayed
Children
No Data