The 5.9 to 6.3 upgrade just hangs for hours on update 6021, just a continuous barber pole on the update page. If I break out of the update and try it again, it just does the same thing, hangs and gives this error.
Drupal database update
* user warning: Duplicate column name 'converted' query: ALTER TABLE menu ADD `converted` TINYINT unsigned NOT NULL DEFAULT 0 in /usr/local/www/data-dist/courses/includes/database.mysql-common.inc on line 298.
* user warning: Table 'menu_custom' already exists query: CREATE TABLE menu_custom ( `menu_name` VARCHAR(32) NOT NULL DEFAULT '', `title` VARCHAR(255) NOT NULL DEFAULT '', `description` TEXT DEFAULT NULL, PRIMARY KEY (menu_name) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /usr/local/www/data-dist/courses/includes/database.inc on line 514.
* user warning: Duplicate entry 'navigation' for key 'PRIMARY' query: INSERT INTO menu_custom (menu_name, title, description) VALUES ('navigation', 'Navigation', 'The navigation menu is provided by Drupal and is the main interactive menu for any site. It is usually the only menu that contains personalized links for authenticated users, and is often not even visible to anonymous users.') in /usr/local/www/data-dist/courses/modules/system/system.install on line 1739.The update process was aborted prematurely while running update #6021 in system.module. All errors have been logged. You may need to check the watchdog database table manually.
Reminder: don't forget to set the $update_free_access value in your settings.php file back to FALSE.
* Main page
* Administration pagesThe following queries were executed
system module
Update #6021* Failed: ALTER TABLE {menu} ADD `converted` TINYINT unsigned NOT NULL DEFAULT 0
* Failed: CREATE TABLE {menu_custom} ( `menu_name` VARCHAR(32) NOT NULL DEFAULT '', `title` VARCHAR(255) NOT NULL DEFAULT '', `description` TEXT DEFAULT NULL, PRIMARY KEY (menu_name) ) /*!40100 DEFAULT CHARACTER SET UTF8 */
The site started out as a 4.7 install, then was updated to 5.9 via the approved instructions, then updated to 6.3. The site, after breaking out of the erorr has no admin menu or page. 1/2 of the admin pages are accessible and the rest are not found.
Hampton
Comments
I would guess that you are
I would guess that you are getting those errors because the first update attempted #6021, and then when you restarted the update it tried it again but had already added the column `converted` to {menu} and created the new table {menu_custom} on the first attempt.
Here is the code run by the update http://api.drupal.org/api/function/system_update_6021/6. It tries to update the table in batches of 50 rows. I wonder if it is timing out on the first batch?. How may rows do you have in table {menu}? Do you have any errors in the {watchdog} table or in the Apache error log from your original update attempt?
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
50 to 200
I did something drastic based on your response and it worked! I found that there were over 100 menus for this user and decided to toss a bomb at the problem. I updated the limit of 50 rows to 200 in the code and it worked! The site upgraded fine and has no issues at current. Thank you for the pointer.
I would believe that the limit of 50 is not enough for those of us with menu abusers in our system.
Hampton
Hmm. Sounds like a bug...
Did you file it?
W
The batch API is supposed to
The batch API is supposed to handle the updating of the {menu} table when there are more than 50 entries ... it's done in batches of 50 but there shouldn't be a problem if there are 500 or 5,000. Maybe the batch functionality was misbehaving? This can happen IIRC if you alter your JS settings and don't destroy your cookies from the site. See e.g. http://drupal.org/node/168870.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk