Upgrade woes


(S) #1

I have spent the past week or so trying to effectively wrestle with an old installation of Squiz for a high-profile Web site. Squiz advised us to upgrade from 4.2.x to 4.6.x and then to 4.18.x, then running upgrade scripts and modifying the database schema throughout.

 

I did manage to upgrade to 4.6.0 and then to 4.6.1, whereupon all pages were served correctly and even _admin worked. However, when upgrading to 4.18 I encountered an issue trying to access _admin. The error shown immediately after logging in is as follows:

 

Fatal error: Uncaught exception 'PDOException' with message: 'SQLSTATE[42703]: Undefined column: 7 ERROR: column "assetid" of relation "sq_internal_msg" does not exist' in [SYSTEM_ROOT]/core/lib/DAL/DAL.inc(612): execute() #1 [SYSTEM_ROOT]/core/include/internal_message.inc(308): execPdoQuery(Object(PDOStatement))
#2 [SYSTEM_ROOT]/core/include/mysource.inc(2655): send()
#3 [SYSTEM_ROOT]/core/include/mysource.inc(1580): _logSecurityMsg('system.security.login.failed', Array, true)
#4 [SYSTEM_ROOT]/core/include/mysource.inc(473): _processGlobalActions()
#5 [SYSTEM_ROOT]/core/include/init.inc(283): init()

 

This is not entirely surprising as I was unable to run upgrade scripts, notably upgrade_clear_squid_cache_preferences.php

 

php scripts/upgrade/upgrade_clear_squid_cache_preferences.php .
ERROR: Failed logging in as root user

 

If I try to suppress (remove) the "exit" then I get:

Moving Squid Cache preferences to External Tools Config
Moving global preferences... Preference not found
Updating global preferences... Ignored
Updating preferences for HR Users (7430)... Ignored
Updating preferences for Columns (7694)... Ignored
Updating preferences for Comms Users (460)... Ignored
Updating preferences for REPT (7220)... Ignored
Updating preferences for Strategy and Insight (20835)... Ignored
Updating preferences for Contractors (13693)... Ignored
Updating preferences for Editors (18380)... Ignored
Updating preferences for Resolve - Subscription Group (19042)... Ignored
Updating preferences for PHSO Testers (17911)... Ignored
Updating preferences for Media (22645)... Ignored
 

Most of the other scripts under scripts/upgrade yield the same errors, which comes from:

 

$root_user = $GLOBALS['SQ_SYSTEM']->am->getSystemAsset('root_user');
if (!$GLOBALS['SQ_SYSTEM']->setCurrentUser($root_user)) {
        echo "ERROR: Failed logging in as root user\n";
 

 

I compared this to two previous versions, but in them it was similar (though the error was reported somewhat differently).

 

Some scripts yield the same error message that I get from the Web end, namely "'PDOException' with message: 'SQLSTATE[42703]: Undefined column: 7 ERROR: column "assetid" of relation "sq_internal_msg" does not exist' in [SYSTEM_ROOT]/core/lib/DAL/DAL.inc(612): execute()"

 

My attempts to tackle this continued for days, but I have been getting nowhere. There were two main approaches:

1. Modify the scripts to force them to run with no issues and expand the schema. This would require knowing a lot of the source code, small modifications don't help.

2. Changing the schema manually to suppress errors, e.g.:

matrix=# ALTER TABLE sq_internal_msg ADD COLUMN assetid text;
ALTER TABLE

This approach, however, just yield another set of errors when trying to log in, e.g.:

"Source string for root_user_disabled not found for locale en_GB"

This approach can also be destructive.

 

How can I restore access to _admin and is there a way to run upgrade scripts to bring the schema up to date? This is a CentOS 5.10 machine with around 20,000 assets.

 

Thanks in advance for any help you can provide,

 

--
Dr. Roy S. Schestowitz | 106 Dalton Street | Manchester M40 7EH | U.K.
http://Schestowitz.com | GNU/Linux administration | PGP-Key: 0x74572E8E

 


(Nic Hubbard) #2

Whoah. If I were you I would restore to a backup and start the upgrade over. I wouldn't ever mess with the code in any of the scripts.

 

You are running the upgrade scripts as root, right?

 

Are you doing this upgrade on a test system (please say yes)? It is always advisable to do this first so you can solve any issues before doing the upgrade on production.


(S) #3

Hi Nic Hubbard,

 

Thanks for replying, I have been lurking and I saw you helping in many threads.

 

Yes, this is a test system -- a clone of a production system. I had made backups of scripts that I modified (only slightly) and I always ran as root, so the above error was a little mysterious. Backup are made at each stage of this upgrade process, so reverting back to a previous state is possible.