BOA Upgrade from 2.0.7 to 2.0.8 .. octopus failing to upgrade

Thanks for the speedy response, omega8cc .. Much appreciated.

I checked the database, and there were two similarly named DBs, with one of them having no data and just one non-information_schema table .. So, I deleted that table, and it was also ironically the database in the settings file for the last upgrade I ran for boa-2.0.7 .. So, it is possible that this problem was created by the upgrade to 2.0.7 and not this one. Incidentally, mysql struggled in deleting this table and the kept crashing complaining that mysql.proc needed to be repaired (even after successful repairs of mysql.proc table) .. In the end, I had to shutdown mysql and move the innodb files for this DB out of the way, and then restarted mysql

I also found the owner of that DB I deleted existing in the user's table, but unlike the owner of the seemingly more valid DB (with all tables and data), it did not have a corresponding user account corresponding to the aegir instance .. So, I also deleted this extra user account.

I then synced password as you suggested .. and again, ran 'bash BOA.sh.txt' .. followed by 'boa in-stable public' .. but I ended up with the same error result. My debug session is attached here ..

In hindsight, perhaps I should also have deleted the directory created by the latest wrong upgrade and the one before that (boa 2.0.7 upgrade) whose settings are pointing to the wrong DB .. But I will await your knowledgeable suggestions.

It is worth nothing that I ran the very same upgrade on another completely different server, and it completed without incidence ..

Please, replace 'deleting table' in my last comment with 'deleting database' .. apologies ..

I went back and deleted 008 corresponding to my last attempt to upgrade to boa-2.0.8 .. I also moved aside 007 which had the wrong DB information reported in my last post.

Then I synced passwords again .. and re-ran BOA.sh.txt and 'boa in-stable public' .. still the same end result, but with other error messages along the way .. see my debug session attached here

My current directory tree after my last 'boa in-stable public' looks like so:

agu:/data/disk/o1/aegir/distro# ls -ld *
drwxr-xr-x 8 o1 users 4.0K Jun 22 2012 001/
drwxr-xr-x 8 o1 users 4.0K Jul 16 2012 002/
drwxr-xr-x 8 o1 users 4.0K Jul 16 2012 003/
drwxr-xr-x 8 o1 users 4.0K Apr 9 13:33 004/
drwxr-xr-x 8 o1 users 4.0K Apr 9 13:33 005/
agu:/data/disk/o1/aegir/distro#

So, it seems the update process deleted the 006 as invalid, and then tried to use the 005 as the directory for the last successful upgrade .. or something along those lines ..

I am beginning to wonder if my previous recent upgrades have been failing silently ..

EdNet, it does seem as if you have investigated your issues more extensively than myself .. But it also seems like your DB is in some strange state. Mind you I have not tested any other delete operations against mysql, so it is not impossible that my challenges are as much as yours.

But, if I see any further inconsistencies with mysql, then I will dump the entire databases, and rebuild but I am generally disinclined from doing this because the primary issue is likely more a script oriented and permissions issue, rather than a DB problem in particular (well, that is what I think) ...

In the worst scenario, it could be a case of finding out how to take backups of site's (without full access to the boa/octopus control panel), scrapping everything and starting again. I hate inconsistencies that I am having to carry along with in hope they will go away. Sometimes, it is just more efficient to bite the bullet and rebuild.

If you have also opened an issue, then I will suggest that we await omega8cc's suggestions. I am a sysadmin (day job .. LOL), so I blame myself for not yet finding enough time to fully dig into the scripts that make up boa/barracuda/octopus and fully understanding exactly how they work .. A greater insight into how the scripts fit together and what they do will make resolving issues like these much easier than just mere guesswork ..

omega8cc, thanks for the feedback .. and info ..

Sorry, been traveling .. Will now revisit this issue .. and come back with some feedback

Taken a good look now, and learnt a great deal more about how BOA components plug together ..

I think the initial problem was created during the install of 2.0.7 (it seems using the boa script created the situation, but I have used it in the past without issues ) .. It seems boa moved aside the old database and tried to recreate them, and was recreating it and failed half-way .. (just a stab in dark as to the original cause) .. I can see that the DB names changed for octopussomedomain and aegirsomedomain, and an attempt was made to recreate them .. unsuccessfully ..

And it seems like a name glob is used to match DBs for a domain, and the renamed and new (or expected) DB names differ by just 2 characters at the end .. So, this seemed to be creating all sorts of side effects

I traced the DB changes via the database backups .. So, I guess my recovery would involve restoring the DBs as they were (including deleting the DBs with similar names), along with permissions and trying again .. I am doing this now ..

Will come back with some feedback .. Now, I can understand why omega8cc warns repeatedly against using boa for upgrades ..

I still have this problem ..

But I think now the problem is with the bits of boa that generate a new directory under distro/00[0-9] .. presumably by calling drush commands ..

The primary error message now is:

Initializing drush commandfile: provision_cdn [1.43 sec, 13.02 MB]                                                  [bootstrap]
Initializing drush commandfile: provision_civicrm [1.43 sec, 13.02 MB]                                              [bootstrap]
Including /data/disk/o1/.drush/provision_civicrm/verify.provision.inc [1.43 sec, 13.02 MB]                          [bootstrap]
Including /data/disk/o1/.drush/provision/dns/verify.provision.inc [1.43 sec, 13.02 MB]                              [bootstrap]
Including /data/disk/o1/.drush/provision/platform/backupmigrate/verify.provision.inc [1.43 sec, 13.03 MB]           [bootstrap]
Including /data/disk/o1/.drush/provision_boost/verify.provision.inc [1.43 sec, 13.03 MB]                            [bootstrap]
Including /data/disk/o1/.drush/provision_cdn/verify.provision.inc [1.43 sec, 13.03 MB]                              [bootstrap]
Including /data/disk/o1/.drush/provision/platform/verify.provision.inc [1.43 sec, 13.03 MB]                         [bootstrap]
The directory /data/disk/o1/aegir/distro/007 does not contain a valid Drupal installation [1.43 sec, 13.03 MB]      [error]
Drush command terminated abnormally due to an unrecoverable error.                                                  [error]
Error: Call to undefined function conf_path() in /data/disk/o1/tools/drush/includes/environment.inc, line 823 [1.43
sec, 13.03 MB]
Output from failed command :                                                                                        [error]

Fatal error: Call to undefined function conf_path() in /data/disk/o1/tools/drush/includes/environment.inc on line

There are pointers there to keep trying to figure this out .. while awaiting input from omega8cc ..

omega8cc, I thank you for your efforts in trying to help me get on top of this situation. In the end, I got too busy to try and troubleshoot the situation some more.

Besides, I had a relaxed attitude about the situation due to the fact that system was like a development system, and I was able to quickly migrate away the few important things on it.

I am starting afresh on a clean slate, and I have learnt so much more about the setup of the system.

Going forward, assuming I can find some spare cycles, in what ways can I contribute to this project ?

thanks and best regards

dont' know what I was thinking, but my domainname was showing in the text I had pasted here .. just fixed that.