RT at a Glance HASH ref error during upgrade from 3.4 to 3.8

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0 and everything seems to work including attachments.
I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0
Which forum?

and everything seems to work including attachments.
You mean that attahcments worked fine with new RT 3.8.0 on clean DB
hosted on mysql 5.0 server?

Have you tested old attachments that were in old DB on mysql 4.0?

I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

I think here is problem. Could you share config of your new mysql 5.0
and all commands you used to migrate DB from old 4.0 server to 5.0?

At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Which forum?
Sorry, I meant the wiki and the mailing list.

You mean that attahcments worked fine with new RT 3.8.0 on clean DB
hosted on mysql 5.0 server?
Have you tested old attachments that were in old DB on mysql 4.0?
When I view the ticket, the correspondence text shows up, aren’t those attachments. I cant verify that binary attachments work because I’m fiddling with the perl installation right now and rt is currently not working at all.

I think here is problem. Could you share config of your new mysql 5.0
and all commands you used to migrate DB from old 4.0 server to 5.0?
At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

I used the bash script in the wiki to backup my previous database
http://wiki.bestpractical.com/view/backupRTDB

except this line I had to change to
mysqldump $rtDB --opt --default-character-set=binary Attachments | gzip > $attachfullfn
mysqldump $rtDB --opt Attachments | gzip > $attachfullfn

I skipped the gzip and just did >backup.dump and >backup.att

because mysql gave me errors about how binary was not a recognized charset.

Then on the new server. I imported the files it into the database by
mysql -p rt3 < backup.dump
mysql -p rt3 < backup.att

Then I ran rt-setup-database --action upgrade
and then the mysql schema upgrade

perl etc/upgrade/schema.mysql-4.0-4.1.pl rt3 user pass> sql.queries
mysql -u root -p rt3 < sql.queries

My new mysql 5.0 config is the same as the 4.0 config. Could there lie the problem?

At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

Are you saying on the import use --default-character-set=binary ?
How? Like this?
mysql -p rt3 --default-character-set=binary< backup.att

Thanks for the help

Larry HFrom: ruslan.zakirov@gmail.com [ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov [ruz@bestpractical.com]
Sent: Wednesday, August 06, 2008 5:26 PM
To: Larry Han
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT at a Glance HASH ref error during upgrade from 3.4 to 3.8

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0
Which forum?

and everything seems to work including attachments.
You mean that attahcments worked fine with new RT 3.8.0 on clean DB
hosted on mysql 5.0 server?

Have you tested old attachments that were in old DB on mysql 4.0?

I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

I think here is problem. Could you share config of your new mysql 5.0
and all commands you used to migrate DB from old 4.0 server to 5.0?

At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

hi:
my environment is just like yours.
you should run mysql upgrade script first, then run rt upgrade
script. or many things will corrupt.
i can not transfer mysql database with “mysqldump”, i got some
corrupt data after upgarde RT. maybe i miss some important parameters
with mysqldump.
finally i just copy the binary file and they work fine after upgrade.2008/8/7 Larry Han lhan@semaphore.com:

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0 and everything seems to work including attachments.
I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

hi:
my environment is just like yours.
you should run mysql upgrade script first, then run rt upgrade
script. or many things will corrupt.
i can not transfer mysql database with “mysqldump”, i got some
corrupt data after upgarde RT. maybe i miss some important parameters
with mysqldump.
finally i just copy the binary file and they work fine after upgrade.
Copy is not a good option for innodb database.

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0 and everything seems to work including attachments.
I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Which forum?
Sorry, I meant the wiki and the mailing list.
Ok.

You mean that attahcments worked fine with new RT 3.8.0 on clean DB
hosted on mysql 5.0 server?
Have you tested old attachments that were in old DB on mysql 4.0?
When I view the ticket, the correspondence text shows up, aren’t those attachments. I cant verify that binary attachments work because I’m fiddling with the perl installation right now and rt is currently not working at all.

You didn’t answer either of my questions, but may be that doesn’t matter.

I think here is problem. Could you share config of your new mysql 5.0
and all commands you used to migrate DB from old 4.0 server to 5.0?
At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

I used the bash script in the wiki to backup my previous database
http://wiki.bestpractical.com/view/backupRTDB

except this line I had to change to
mysqldump $rtDB --opt --default-character-set=binary Attachments | gzip > $attachfullfn
mysqldump $rtDB --opt Attachments | gzip > $attachfullfn

I skipped the gzip and just did >backup.dump and >backup.att

because mysql gave me errors about how binary was not a recognized charset.
That’s ok as your old mysql server is 4.0. Read instructions below.

Then on the new server. I imported the files it into the database by
mysql -p rt3 < backup.dump
mysql -p rt3 < backup.att

Then I ran rt-setup-database --action upgrade
and then the mysql schema upgrade

perl etc/upgrade/schema.mysql-4.0-4.1.pl rt3 user pass> sql.queries
mysql -u root -p rt3 < sql.queries

My new mysql 5.0 config is the same as the 4.0 config. Could there lie the problem?

At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

Are you saying on the import use --default-character-set=binary ?
How? Like this?
mysql -p rt3 --default-character-set=binary< backup.att

I think the following steps should make migration for you.

NOTE FOR READERs: this is only correct for people migrating from 4.0
to 4.1 and newer.

  1. when you do a mysqldump you don’t need additional options, as mysql
    4.0 has no --set-default-charset or --set-charset options, so use:

    mysqldump --opt rt3 > rt3.mysql.dump

or the following to gzip by the way

mysqldump --opt rt3 | gzip > rt3.mysql.dump.gz
  1. Configure your mysql 4.1 or newer to use latin1 as default
    character set. I can not explain this, it will take too long.

  2. You create new DB for RT in your mysql 4.1 or newer using RT

  3. You move the dump file to the server with mysql 4.1 or newer and
    restore data using

    mysql --set-default-charset=binary < rt3.mysql.dump

  4. You apply upgrade action on this new DB

  5. You apply commands generated by schema upgrade script

I think I’ve covered all possibilities that can corrupt data during migration.

Thanks for the help

Larry H


From: ruslan.zakirov@gmail.com [ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov [ruz@bestpractical.com]
Sent: Wednesday, August 06, 2008 5:26 PM
To: Larry Han
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT at a Glance HASH ref error during upgrade from 3.4 to 3.8

I’m in the process of moving and upgrading our RT server from
rt 3.4.1
mysql 4.0
to
rt 3.8
mysql 5.0

I have followed the steps on the forum and I have the database moved over to mysql 5.0
Which forum?

and everything seems to work including attachments.
You mean that attahcments worked fine with new RT 3.8.0 on clean DB
hosted on mysql 5.0 server?

Have you tested old attachments that were in old DB on mysql 4.0?

I did a mysql dump from the old 4.0 database and then imported the dump into the 5.0 database. Then I applied the ‘rt-setup-database --action upgrade’ command and then did the mysql schema upgrade.

I think here is problem. Could you share config of your new mysql 5.0
and all commands you used to migrate DB from old 4.0 server to 5.0?

At this point I can suggest you reimport DB from dump (I think you
used mysqldump for migration) using --default-character-set=binary
option. Then again apply schema upgrade scrip.

All tickets seeem to be present in the current database and all attachments look fine. However, I get the following error in the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 504.

The RT at a Glance config pages show a similar error.

Searching google for this error message or parts of this error message return nothing. Is there a step that I forgot to do or something that causes this problem? Do I have a misconfigured or incorrect perl package?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


Best regards, Ruslan.

Best regards, Ruslan.

Hi:
i think your mysql upgrade procedure is great. can you put it into document?
i just read UPGRADING.mysql in rt 3.8.1rc2, it is the same as 3.8.0.
so most people like me will run rt upgrade script first, then run
mysql upgrade script. and get corrupt system.
and you said binary copy is not good for innodb. so I think I
should dump then restore when upgrade mysql from 4 to 5. are there any
reasons? maybe mysql-5 innodb is better than mysql-4 innodb?
thanks for help!!

Regards,
tbskyd

I think the following steps should make migration for you.

NOTE FOR READERs: this is only correct for people migrating from 4.0
to 4.1 and newer.

  1. when you do a mysqldump you don’t need additional options, as mysql
    4.0 has no --set-default-charset or --set-charset options, so use:

    mysqldump --opt rt3 > rt3.mysql.dump

or the following to gzip by the way

mysqldump --opt rt3 | gzip > rt3.mysql.dump.gz

ok

  1. Configure your mysql 4.1 or newer to use latin1 as default
    character set. I can not explain this, it will take too long.

I checked mysql 5.0 documentation and it seems like latin1 is the default charset already?
Is this correct?

  1. You create new DB for RT in your mysql 4.1 or newer using RT

thats this command
rt-setup-database --action init --dba root --prompt-for-dba-password

  1. You move the dump file to the server with mysql 4.1 or newer and
    restore data using

mysql --set-default-charset=binary < rt3.mysql.dump

actually
mysql --default-character-set=binary < rt3.mysql.dump

  1. You apply upgrade action on this new DB

thats the ‘rt-setup-database --action upgrade’ command?

  1. You apply commands generated by schema upgrade script

ok

I’ve seen differing reports and would like a definite answer on when upgrading whether you should do the ‘rt-setup-database --action upgrade’ command first or if you should do the mysql schema update first.

I think I’ve covered all possibilities that can corrupt data during migration.

Thanks, this has helped me a lot and I bet will help a lot other people out as well.

Ok, so I followed all these steps but I still have the same error on the RT at a glance page.

Can’t use string (“BQYDAAAAAgQCAAAAAwQDAAAAAgoKTXkg”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Elements/MyRT line 76, line 505.

Trying to change RT at a glance prefs also gives me the same error

Can’t use string (“BQYDAAAABAoEREVTQwAAAAVPcmRlcgpD”) as a HASH ref while “strict refs” in use at /var/www/tickets01/share/html/Prefs/MyRT.html line 126, line 505.

Anyone run into this before?From: rt-users-bounces@lists.bestpractical.com [rt-users-bounces@lists.bestpractical.com] On Behalf Of Larry Han [lhan@semaphore.com]
Sent: Thursday, August 07, 2008 10:39 AM
To: Ruslan Zakirov
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT at a Glance HASH ref error during upgrade from 3.4 to 3.8

I think the following steps should make migration for you.

NOTE FOR READERs: this is only correct for people migrating from 4.0
to 4.1 and newer.

  1. when you do a mysqldump you don’t need additional options, as mysql
    4.0 has no --set-default-charset or --set-charset options, so use:

    mysqldump --opt rt3 > rt3.mysql.dump

or the following to gzip by the way

mysqldump --opt rt3 | gzip > rt3.mysql.dump.gz

ok

  1. Configure your mysql 4.1 or newer to use latin1 as default
    character set. I can not explain this, it will take too long.

I checked mysql 5.0 documentation and it seems like latin1 is the default charset already?
Is this correct?

  1. You create new DB for RT in your mysql 4.1 or newer using RT

thats this command
rt-setup-database --action init --dba root --prompt-for-dba-password

  1. You move the dump file to the server with mysql 4.1 or newer and
    restore data using

mysql --set-default-charset=binary < rt3.mysql.dump

actually
mysql --default-character-set=binary < rt3.mysql.dump

  1. You apply upgrade action on this new DB

thats the ‘rt-setup-database --action upgrade’ command?

  1. You apply commands generated by schema upgrade script

ok

I’ve seen differing reports and would like a definite answer on when upgrading whether you should do the ‘rt-setup-database --action upgrade’ command first or if you should do the mysql schema update first.

I think I’ve covered all possibilities that can corrupt data during migration.

Thanks, this has helped me a lot and I bet will help a lot other people out as well.
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Actually, I don’t think that it is a database problem.
When I do a mysqladmin drop rt3;
and then I do rt-setup-database --action init, the RT at a glance page still shows the same error.

So I think it may be a problem with my perl or the RT install.
Any suggestions?

Hm, interesting… Sounds like some problem with serialization.

We use Storable module to serialize data, it worth try either upgrade
or downgrade. Please don’t forget to remember the current installed
version, so we can bump dependencies if problem is in this module.

Install new or older version. Drop database, init, test.On Fri, Aug 8, 2008 at 1:47 AM, Larry Han lhan@semaphore.com wrote:

Actually, I don’t think that it is a database problem.
When I do a mysqladmin drop rt3;
and then I do rt-setup-database --action init, the RT at a glance page still shows the same error.

So I think it may be a problem with my perl or the RT install.
Any suggestions?

Best regards, Ruslan.

So actually, it was a database problem. I failed to clear my browser cache when testing.
I finally solved the issue. If I didn’t import the table “Attributes,” the RT at a glance page would work. However even if I had imported and then dropped the attributes table, the RT at a glance page would still not work. I had to do a dump of all tables except the attributes table in order to make it work.

Is there an explanation of why?

Thanks for all the help.

LarryFrom: ruslan.zakirov@gmail.com [ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov [ruz@bestpractical.com]
Sent: Thursday, August 07, 2008 3:04 PM
To: Larry Han
Cc: rt-users@lists.bestpractical.com
Subject: Re: Re: [rt-users] RT at a Glance HASH ref error during upgrade from 3.4 to 3.8

Hm, interesting… Sounds like some problem with serialization.

We use Storable module to serialize data, it worth try either upgrade
or downgrade. Please don’t forget to remember the current installed
version, so we can bump dependencies if problem is in this module.

Install new or older version. Drop database, init, test.