I am still unable to update octopus (was on 2.0.6 head and am now 2.0.6 stable). using strong passwords=yes. I have named my "o1" "fast1"
I had password problems in march, but randpass 32 esc and randpass 32 alnum became usable. See http://drupal.org/node/1952042
I tried the octopus upgrade 6 times on april 2 and 3 - all failed with the same error - drush command terminated abnormally due to unrecoverable error, Drush was not able to bootstrap the drupal database, then: could not find a settings.php file in the instance being created. I tried the upgades with different combinations of hot_sauce=YES and hot_sauce=NO AND use_current=YES and use_current=NO. I removed the /006/ directory each time it was created (when using use_current=NO) and I never found any "fail" files in /opt/temp
I noticed that in /data/disk/fast1/ there are all these .fast1.pass.txt-pre-BOA-2.0.6-130402-1114 files - one for each upgrade attempted. Well I downloaded them and opened them up and found that they sometimes contain passwords of 29, sometimes 30 characters, sometimes 31, and only once a 32 character password. Is this a problem? Is the install or upgrade script supposed to always create a password of exactly 32 characters? I list them below, and attach the files:
MUT.spUl[er~*EqN;ecGkXkFe;8teS 30 characters
2r*jm/HDci!giZ7HLh2d^?Ys*}f 32 characters
6^P2~jez5K3_)OIPkNTcuo0}AhGQZ 29 characters
ndX]h8Pr,8c-vEs.Ma= 31 characters
_[o]Sd^liD
[tRq2JUcv=ch4;i5Zs_Kb)%za_kv!e 30 characters
The log (attached) errors are:
Successfully connected to the Drupal database. [25.9 sec, 14.59 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [25.9 sec, 14.59 MB] [bootstrap]
Drush command terminated abnormally due to an unrecoverable error. [25.9 sec, 14.59 MB] [31;40m[1m[error][0m
Drush was not able to start (bootstrap) the Drupal database. [31;40m[1m[error][0m
Hint: This error often occurs when Drush is trying to bootstrap a site that has not been
installed or does not have a configured database.
Drush was attempting to connect to :
Drupal version : 6.28
Site URI : fast1.server1.domain.com
Default theme : garland
Administration theme: garland
PHP configuration : /opt/local/lib/php.ini
Drush version : 4.6-dev
Drush configuration:
/data/disk/fast1/aegir/distro/006/sites/fast1.server1.domain.com/drushrc.php
/data/disk/fast1/aegir/distro/006/drushrc.php
Octopus [Tue Apr 2 11:15:53 CEST 2013] ==> UPGRADE B: Hostmaster STATUS: upgrade completed
Octopus [Tue Apr 2 11:15:53 CEST 2013] ==> UPGRADE B: Simple check if Aegir upgrade is successful
Octopus [Tue Apr 2 11:15:55 CEST 2013] ==> UPGRADE B: FATAL ERROR: Required file /data/disk/fast1/aegir/distro/006/sites/fast1.server1.domain.com/settings.php does not exist
Octopus [Tue Apr 2 11:15:55 CEST 2013] ==> UPGRADE B: FATAL ERROR: Aborting AegirSetupB installer NOW!
Comment | File | Size | Author |
---|---|---|---|
#7 | failed-boa-upgrade-terminal-command-line-complete-b-and-o.txt | 175.76 KB | Anonymous (not verified) |
#7 | barracuda_log.txt | 3.7 KB | Anonymous (not verified) |
#7 | octopus_log.txt | 555 bytes | Anonymous (not verified) |
#7 | barracuda-cnf.txt | 1.55 KB | Anonymous (not verified) |
#7 | fast1-octopus-cnf.txt | 1.03 KB | Anonymous (not verified) |
Comments
Comment #0.0
Anonymous (not verified) CreditAttribution: Anonymous commentedadded addtl info
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThe log (attached) errors are:
Successfully connected to the Drupal database. [25.9 sec, 14.59 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [25.9 sec, 14.59 MB] [bootstrap]
Drush command terminated abnormally due to an unrecoverable error. [25.9 sec, 14.59 MB] [31;40m[1m[error][0m
Drush was not able to start (bootstrap) the Drupal database. [31;40m[1m[error][0m
Hint: This error often occurs when Drush is trying to bootstrap a site that has not been
installed or does not have a configured database.
Drush was attempting to connect to :
Drupal version : 6.28
Site URI : fast1.server1.domain.com
Default theme : garland
Administration theme: garland
PHP configuration : /opt/local/lib/php.ini
Drush version : 4.6-dev
Drush configuration:
/data/disk/fast1/aegir/distro/006/sites/fast1.server1.domain.com/drushrc.php
/data/disk/fast1/aegir/distro/006/drushrc.php
Comment #1.0
Anonymous (not verified) CreditAttribution: Anonymous commentedpage didn' save properly
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI cannot even save 5-10 lines of text on this issue reporting interface without half of it not appearing when it is saved. It is still there when I click edit, but it does not appear on the page - bizarre!
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedI have just tested this on the command line interface, and randpass 32 esc generates different length passwords of between 29 and 32 characters inclusive, while randpass 32 alnum always generates a 32 character password. It might be one or more o the "special characters" in randpass 32 esc that is causing this (like the . ^ or ; possibly ?)
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedthis is a bug report
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedLastly, I see that your server is generating the same different length passwords with randpass 32 esc - as seen here: http://drupal.org/node/1952042
I counted one with only 28 characters and one with 32 ...
Comment #6
omega8cc CreditAttribution: omega8cc commentedThe
randpass 32 esc
may generate passwords with *up to 32* characters, because it removes characters which could cause issues *after* generating a string with 32 characters. This is by design and it is *not* a source of your problem.Please enable debugging as explained in the guidelines and attach full upgrade log.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedI believe I may have a clue as to the problem. When I made the mistake of upgrading from BOA 2.0.5 to 2.0.6 head - trying to solve my IDN problems, I read the notes on _DB_ENGINE=InnoDB and added it to my BOA .cnf file. After upgrading barracuda to 2.0.6 stable, I tried to remove that line, and even though I removed it in the .barracuda.cnf file, it kept on re-appearing somehow in the terminal command line interface (see line 112 of the attached complete terminal command line interface). Could this be the problem?
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedI mention this in 7, above, because I installed boa 2.0.6 stable on a tiny local server which I can use to do all updating and upgrading (so I don't have problems in production server), then in barracuda set _DB_ENGINE=InnoDB, then a day later tried to remove that _DB_ENGINE setting, and although I did remove it from the .barracuda.cnf file, it came back and was there on the terminal line. Today I tried to upgrade barracuda and octopus on that test server, and I kept getting failure error messages when updating percona tables in the barracuda upgrade that percona needed to be restarted: Percona server not running properly. ANd percona is running when I do a status check. Restarting percona does not help as the same error occurs on a subsequent barracuda upgrade.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedAs an added note, in case this innodb is the problem:
In my master db - the MySQL db it is all MySQL. I have no idea (no documentation) if this was supposed to be changed with the _DB_ENGINE=InnoDB or not?
In my master.domain.com barracuda db - everything is InnoDB except some tables:
hosting_backup_queue_sites
hosting_backup_queue_sites_settings
hosting_ssl_cert
hosting_ssl_ips
hosting_ssl_server
all of which are empty
and hosting_ssl_site which is not empty.
Do I need to manually change these to InnoDB?
In my fast1 (o1) db everything is InnoDB.
Comment #10
omega8cc CreditAttribution: omega8cc commentedThis has nothing to do with InnoDB/MyISAM or Percona/MariaDB.
It sounds like a duplicate of #1963044: randpass problem has returned for 2.0.7 fresh install - disappeared when I installed all locales with dpkg-reconfigure locales because it is related to incorrect locales (no UTF-8) which gives unexpected results when you are trying to use strong passwords option.
Comment #10.0
omega8cc CreditAttribution: omega8cc commentedPage does not save all text