Jump to:

At first I had some problems with the whole upgrade-> MySQL access denied. After a search or two I found one case where they suggested that password had been manually changed. So I went and took password from .my.conf. and updated db tables.
Now the upgrade went trough and during the installation there was no errors or such.
However, after upgrading barracuda and octopus I got 404 on aegir front-end and 500 on site(octopus).

I reviewed nginx access log and it said 13: permission denied (when accessing aegir frontend).
Therefore I made some changes to file permission on var/aegir/host_master with reference to old installation(still in the folder).
*And now I can access Aegir frontend though update doesn't work.
What would be the correct file permissions in different data sources? Same as Drupal? Is there any script available that could take care of fixing file permissions?

I can also receive emails about available updates concerning my current installation.
Should I just try to install it one more time with the debug mode set to true?

*Edits and updates

Browsing to VPS IP returns Chive login and so does chive.o1.dot.com

All other subdomains except for aegir o1/front-end =404 do return nginx default under construction page.

I reviewed MySQL database permissions and found out that there were only a few db permissions. Therefore I had to create couple new db permissions and the dot.com started to work. But still, hostmaster/aegir front-end doesn't open (404).

Could you also enable Drush debugging in the Octopus config file /root/.USER.octopus.cnf and post the full debug output on another upgrade attempt with octopus up-stable all log - it will be written to /var/backups/reports/up/octopus/DATE/octopus-up-* file.

###### Configuration created on 121013-1951 with### Octopus version BOA-2.0.3###### NOTE: the group of settings displayed bellow### will *override* all listed settings in the Octopus script.###_USER="o1"_MY_EMAIL="root@localhost"_PLATFORMS_LIST="ALL"_AUTOPILOT=NO_HM_ONLY=NO_O_CONTRIB_UP=YES_DEBUG_MODE=NO_MY_OWNIP=_FORCE_GIT_MIRROR=""_THIS_DB_HOST=localhost_DNS_SETUP_TEST=NO_HOT_SAUCE=NO_USE_CURRENT=YES_REMOTE_CACHE_IP=127.0.0.1_LOCAL_NETWORK_IP=_PHP_FPM_VERSION=5.3_PHP_CLI_VERSION=5.3###### NOTE: the group of settings displayed bellow will be *overriden*### by config files stored in the /data/disk/o1/log/ directory,### but only on upgrade.###_DOMAIN="o1.hostname"_CLIENT_EMAIL="root@localhost"_CLIENT_OPTION="CLASSIC"_CLIENT_SUBSCR="M"_CLIENT_CORES="4"###### Configuration created on 121013-1951 with### Octopus version BOA-2.0.3###_ALLOW_UNSUPPORTED=NO_USE_STOCK=NO_STRONG_PASSWORDS=NO

* Your Aegir control panel for this instance is available at https://o1.hostname * Your Aegir system user for this instance is o1 * This Octopus will use PHP-CLI 5.3 for all sites * This Octopus will use PHP-FPM 5.3 both for D6 and D7 sites * This Octopus includes platforms: ALL / Unsupported: NO * This Octopus options are listed as CLASSIC / M / 4 C

Ok, thanks for reviewing.
I've now tried to upgrade octopus according to your guidance. Here's what happened:
What concerns me is that
instance control panel is available at o1.MY_HOSTNAME since it should be in o1.dot.com(which is a alias)?
AFAIK the installation loads the octopus conf that seems to include "wrong" domain and therefore maybe I could change it manually and try running the upgrade once more?

I did try the debug mode and posted the "results" in the previous comment.In short:
Upgrade got hanging and nothing happened.
Just a notice "waiting 5 sec" and hang(waited for 30min).Went to see logfile which ended in: Do you want to proceed? (which is the first step in upgrade)

If I now try the upgrade again it will say that it is already up to date.

However, main point is the most recent "inline" log that you can find from attachments below :) It declares that there was errors in the first place.

If I try to change the permissions into e.g. rwx for aegir user and group in var/aegir/host_master/003/... it won't no longer give errors related to sites/.../files/.
For the index.php/front end part it turns into a error 500 but nginx doesn't show any erros in the log.
Obviously permission denied was solved and now something else gets in the way.

Could you please run another barracuda up-stable upgrade after enabling drush debugging in /root/.barracuda.cnf and attach the output? I guess that it needs to fix the master instance as it fixed the satellite instance.