Update:

1. Go to Admin ›  Utilities ›  SQL Manager ›  Manage Database Tables, select ‘Select All’ at the bottom, and choose ‘Repair selected tables’.

DONE

2. Could any of the last 60-or-so entries have ‘unusual’ characters or content? This shouldn’t really be an issue but obviously something is choking around there.

YES. I found two entries in the last 61 entries, and removed strange characters from both.

  1. Rename “British Splash-In Championship” to “British Splash-In Championship” in exp_weblog_titles (entry_id=3338)
  2. Rename “Olympus Launches the “Pen Your Story Challenge— to “Olympus Launches the Pen Your Story Challenge” in exp_weblog_titles (entry_id=3317)

3. 128MB should be fine, but are you able to up this limit (and verify via phpinfo) just to rule it out?

CHANGED to 256MB.

I just re-tried the upgrade, and it failed at the exactly the same place.

Note that I also did a new install, and it worked fine, so my environment is set up properly for EE2.0b.

Any other leads?

Interesting. After I hit “OK” in the last error dialog, the text changed on the update screen to:

Please Stand By…
We are currently updating your ExpressionEngine installation.

Do not close your browser until the update routine is finished.

2.0.0: Converting Database Table exp_wikis: 0 of 1 queries

(it stops there, though)

echeng - are you using the wiki module?

Lisa -
Yes, it is installed. The update directions say that modules and extensions will be disabled upon update, don’t they?. Is there explicit action that must be taken to massage the install before update?

No, the wiki should upgrade fine; but are you actually using it/is there data in it? 

I had a look and I don’t see that error reported previously, so just getting a bit more information before figuring out how to proceed.

Thank you. =) We’ll get there!

I’m not actively using it, but there is probably data in it.

To be clear, the titles table status report was still showing when the error pop-up showed up. The wiki message appeared after I clicked OK.

Any more suggestions? Can I turn on some sort of detailed logging mode or something? This is getting a bit ... frustrating.

Thank you for your help!

echeng,

Can you share with us what is in your config file now regarding the next step in the update process.

You should have a variable similar to the following

John—now, we’re getting somewhere.

This is exactly what I did:

1. copy fresh 2.0.2pb1 files and change permissions per new install
2. restore 1.6.9 db
3. copy 1.6.9 config.php to 2.0.2pb1 directory
4. attempt upgrade

When I do this, I get no AJAX status updates. When it fails (after > 10 minutes):

The screen reads:

If I then re-do steps 2-4, restoring the old config file and database (but not the rest of the files), I get AJAX status updates (e.g. 2.0.0 Converting Database Table…). The same ud_next_step shows in config. But a file other than config.php is changed during the first attempt that enables AJAX updates…

echeng, I’ve sent an email to the address associated with your account.  If possible, I’d like to take a closer look.

Thank you. Email sent.

I set up the exact same system on a Linux-based web server, and it throws an error at the same place as it did on my Mac OS X server. It appears that the error isn’t server dependent.

Hi echeng,

We will be investigating this issue and will update this thread as soon as we can. Thanks for your patience.

Cheers

Greg

Wow- that took a while.  But- last install went through fine.  A couple of things to note:

1. exp_captchas was huge- and honestly can be truncated no problem.  It was throwing memory errors trying to deal with it- thus the 400 errors.  Basically?  I just emptied it via phpmyadmin before running the update.  That got past most of it (and I’ll add truncating the table to the updater- I did it already, but I still had to empty yours manually first.  So if it comes up for anyone- truncate exp_captchas if it’s hugge (was 55mb almost 800,000 records).

2.  Make sure the database doesn’t have any tables it shouldn’t.  The backup had some from 2.0 in it- snippets and such.  Threw an error on me- but once I noticed they were there, I just dropped those extra tables when I truncated captchas.

3.  Had some duplicate records in exp_category_posts- which will throw an error when EE tries to add a combined index.  I’d already put a check into the next version of the updater, but hadn’t tested it out.  It needs a few tweaks, but was sufficient for handling this case.

4.  I upped the memory to 256- which is probably not necessary w/the captcha table reduced.  But I did that first- and it wouldn’t hurt to leave it that way when you run the update.

Oh- and because I didn’t want to remove/rename the install stuff- in index.php I ‘fidged’ the check that makes you remove the folder:

The FALSE bit shouldn’t be there- but for testing it’s a quick way to have it skip that check.

You’ll want to use the contents of the current install folder if you go in to do this yourself.  I put some new files up.  If all is well ‘as is’- you can go ahead and delete the install folder and proceed as normal.  I can tell by looking at the cp login, some paths and such will need changing.  But the update itself went through fine.  After a good bit of tweaking

Thanks for your patience and allowing me to experiment with your install.

If you have any questions about what I did- just let me know.

Thank you, Robin! That is fantastic news.

I do have a few questions, however, since I will need to re-do this upgrade later using the production data, and again when we do the actual migration. Can you tell me if these steps will allow me to reproduce the upgrade?

1. truncate exp_captchas
2. make sure the database doesn’t have any tables it shouldn’t (use fresh export from existing 1.6.9)
3. handle dupe records in exp_category_posts (next updater will solve this, right?)
4. up memory to 256M (I actually did this in php.ini before you got in there.
5. edit system/index.php so it is OK with leaving the installer folder there:

Thanks again!

Yep- I knew you’d likely need to run an update yourself, so wanted to leave the install folder up there.

K- regardless of whether a new release is out, you’ll need to do 1&2&4- for #2, a fresh export from existing 1.6.9 will be fine.  #4 is probably unnecessary, but it won’t hurt and you can reduce it after the update is done.

IF there’s an update released before you update, you won’t have to worry about #3.  If there isn’t an update- just using the install folder on your test site (that I edited) will take care of the problem.

With #5- you’ll want to edit the system/index.php to remove the FALSE once you’re done with the update- at which point, you’ll have to remove the install folder before you’ll be allowed to access the control panel itself.

Make sense?