Reporting a rt2.0.15 to rt3.0.9 mysql migrate failure

Dear Jesse / Bestpractical,

Attempting to migrate RT-2.0.15 into RT-3.0.9 .
Checked user list first for references to failure.
Platform source: mysql-4.17, platform target mysql-4.17,
both on debian linux.

using RT-3.0.9 / mysql / mod_perl1 target.

First initialized db was created:

Creating mysql database rt3.
Now populating database schema.
Creating database schema.
schema sucessfully inserted
Now inserting database ACLs
Now inserting RT core system objects
Checking for existing system user (RT::CurrentUser=HASH(0x8d5ba14))…not
found. This appears to be a new installation.
Creating system user…done.
Now inserting RT data
Creating Superuser ACL…Creating groups…3.4.5.6.7.8.9.done.
Creating users…10.12.done.
Creating queues…1.2.done.
Creating ACL…2.3.done.
Creating ScripActions…1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.done.
Creating ScripConditions…1.2.3.4.5.6.7.8.9.done.
Creating templates…1.2.3.4.5.6.7.8.9.10.11.12.done.
Creating scrips…1.2.3.4.5.6.7.8.9.10.11.12.13.done.

Then dump dir from rt2 was attempted to be imported:

The first non-successful result was this:

Importing groups
ggCouldn’t find user with RT2 userid - not adding to CS RepsgggCouldn’t
find user with RT2 userid - not adding to
LeadsggrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrqqqqqqqqqqqqqqqqqqqqqqImporting
tickets…t-1
.t-2
.t-3
.t-4

.t-392
.t-393
.t-394
.t-395
Couldn’t create attachment
$VAR1 = {
‘Subject’ => ‘’,
‘ContentType’ => ‘text/plain’,
‘Filename’ => ‘media-inc.log’,
‘Headers’ => 'Content-Type: TEXT/PLAIN; charset=US-ASCII;
name=“media-inc.log”
Content-Transfer-Encoding: BASE64
Content-ID: Pine.LNX.4.44.0306031556040.16591@web0.speakeasy.net
Content-Description:
Content-Disposition: attachment; filename=“media-inc.log”
X-RT-Original-Encoding: us-ascii
',
‘Creator’ => ‘4’,
‘Parent’ => ‘1501’,
‘Created’ => ‘2003-06-03 22:45:31’,
‘ContentEncoding’ => ‘none’,
‘id’ => ‘1503’,
‘TransactionId’ => ‘2238’
};

Got a packet bigger than ‘max_allowed_packet’
[Wed Feb 18 22:26:55 2004] [crit]: Died at ./dumpfile-to-rt-3.0 line 714.
(/opt/rt3/lib/RT.pm:254)

Checking the lists.bestpractical.com archive lists there are some
references to attachments but none matching this that I found, so
here is the report. Hope it helps.

are migrated attachments, or version 2.0.15 to 3.0.9 not supported?

Thanks,

Dave Dennis
dennis@speakeasy.net
(w) 206-971-5134
(m) 206-769-3546

Couldn’t create attachment
Got a packet bigger than ‘max_allowed_packet’

I bet that if you google for that error message. Or check the mysql
manual, you’ll see something useful. This is probably a good candidate
for the FAQ on wiki.bestpractical.com

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Dear Listfolk,

Right, I had looked up under mysql 4.X it says max_allowed_packet cannot
be raised, it has a theoretical limit of 2G based on your hosts RAM.

http://www.mysql.com/newsletter/2003-08/a0000000216.html

The ticket that failed, #394 in my 2.0.15 RT, has an attachment. Its
size though should not be problematic, 313 kb. As the data migration
failed, I did what the README said, posted a bug report.

Kind regards,

Dave Dennis
dennis@speakeasy.net
(w) 206-971-5134
(m) 206-769-3546On Wed, 18 Feb 2004, Jesse Vincent wrote:

Couldn’t create attachment
Got a packet bigger than ‘max_allowed_packet’

I bet that if you google for that error message. Or check the mysql
manual, you’ll see something useful. This is probably a good candidate
for the FAQ on wiki.bestpractical.com

Dear Listfolk,

Right, I had looked up under mysql 4.X it says max_allowed_packet cannot
be raised, it has a theoretical limit of 2G based on your hosts RAM.

http://www.mysql.com/doc/en/Packet_too_large.html

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.