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

Comments

Issue summary:View changes

added addtl info

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]

Issue summary:View changes

page didn' save properly

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!

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

Category:support» bug

this is a bug report

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

Title:Unable to upgrade octopus 2.0.6 - may still be problems with randpass generating diferent length passwords each upgrade atemptUnable 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.

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?

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.

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.

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.

Issue summary:View changes

Page does not save all text