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!

CommentFileSizeAuthor
#7 failed-boa-upgrade-terminal-command-line-complete-b-and-o.txt175.76 KBAnonymous (not verified)
#7 barracuda_log.txt3.7 KBAnonymous (not verified)
#7 octopus_log.txt555 bytesAnonymous (not verified)
#7 barracuda-cnf.txt1.55 KBAnonymous (not verified)
#7 fast1-octopus-cnf.txt1.03 KBAnonymous (not verified)
Part 1.txt103.15 KBAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130403-1148.txt48 bytesAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130403-0925.txt48 bytesAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130403-0905.txt46 bytesAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130402-1240.txt47 bytesAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130402-1203.txt47 bytesAnonymous (not verified)
fast1.pass_.txt-pre-BOA-2.0.6-130402-1114.txt49 bytesAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Issue summary: View changes

added addtl info

Anonymous’s picture

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

Anonymous’s picture

Issue summary: View changes

page didn' save properly

Anonymous’s picture

I 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!

Anonymous’s picture

I 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 ?)

Anonymous’s picture

Category: support » bug

this is a bug report

Anonymous’s picture

Lastly, 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 ...

omega8cc’s picture

Title: Unable to upgrade octopus 2.0.6 - may still be problems with randpass generating diferent length passwords each upgrade atempt » Unable to upgrade octopus 2.0.6
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

The 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.

Anonymous’s picture

I 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?

Anonymous’s picture

I 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.

Anonymous’s picture

As 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.

omega8cc’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

This 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.

omega8cc’s picture

Issue summary: View changes

Page does not save all text