Cannot add "system list" because "system" already exists

I know it's confusing, but "update.module" is for the part of core (added in 6.x) that checks for available updates to your modules and themes. You're talking about update.php for DB updates, which is the "update system" component...

I don't think this should be critical until someone else can reproduce it, but it's major enough to seriously consider before 7.0. Can you provide more steps on how to trigger this? A partial and/or scrubbed DB dump that demos it in action?

I'm fairly certain that this system_list index error is not an issue in itself -- what has happened is that update_fix_d7_requirements() ran into a fatal error, never managed to variable_set('update_d7_requirements', TRUE), and the system_list error is the result of update_fix_d7_requirements() being called again after some changes have already been made. At this point, the upgrade is corrupted and you must revert back to your clean D6 backup and try again.

To prevent confusion, we might be able to variable_set('update_d7_requirements', -1) when we start the function, and check for that in update_prepare_d7_bootstrap() so we can set a requirements error and let them know the upgrade failed and to read UPGRADE.txt, etc. and try again.

@eigentor, in theory there should've been an error message before you started getting the system_list error. Could you try again from scratch and see about that?

Great, glad to hear it. Thanks.

The same issue. I can't upgrade drupal 6.19 to drupal 7 beta2 or -dev.
I disabled all modules (except Core and Core - optional) and when upgrade starts, I get this error:

DatabaseSchemaObjectExistsException: Table <em class="placeholder">cache_path</em> already exists. in DatabaseSchema->createTable() (line 621 of D:\site-directory\includes\database\schema.inc).

When I try again, I get another error:

DatabaseSchemaObjectExistsException: Cannot add index <em class="placeholder">system_list</em> to table <em class="placeholder">system</em>: index already exists. in DatabaseSchema_mysql->addIndex() (line 433 of D:\site-directory\includes\database\mysql\schema.inc).

@zxs, see #934634: Upgrading a Pressflow site fails because cache_path table already exists.. Applying the patch there should get you a successful upgrade.

I have this problem

DatabaseSchemaObjectExistsException: Cannot add index system_list to table system: index already exists. in DatabaseSchema_mysql->addIndex() (line 433 of /site/includes/database/mysql/schema.inc).

P.S. I disabled all contrib modules, and cheked in table system (phpmyadmin)

I encountered this in upgrading from DP6 to DP7. It occurs in update.php when trying to take the (normally correct) upgrade path from DP6 to DP7.

I think the cause may have been that I first tried to upgrade directly from DP5 to DP7, maybe messing up some tables in the meantime, but here is what solved it:

1. Remove the "system_list" INDEX from your system table
2. Remove the "alias" field from your "url_alias" table
3. Remove the "source" field from your "url_alias" table

You need to perform all three actions at once, using your favorite database editor (e.g., phpMyAdmin.) Then, run update.php again and it should go through.

If you get more error messages about fields or indexes not being able to be created, just make a note of which ones, and try again. Remember to remove them all at once before trying to run update.php again.

If you only fix one at a time, you will just end up hitting the earlier error, somehow the update script wants to upgrade a number of fields and indices all at once and doesn't consider if that operation previously only partially completed (e.g., when you failed during an upgrade from DP5 to DP7.)

Hopefully this is helpful to somebody.

In my case, from what I can tell, I accidentally uninstalled "update status", mistaking it for "upgrade status" (which doesn't have an uninstall option...)

@PsySal

same case here.. really a weird problem!. had to remove some more fields..

why there is no "DROP TABLE IF EXISTS" feature in drupal 7?

Hi, I have the same error on upgrading from drupal 6.26 to drupal 7.14:

DatabaseSchemaObjectExistsException: Cannot add index <em class="placeholder">system_list</em> to table <em class="placeholder">system</em>: index already exists. in DatabaseSchema_mysql->addIndex() (line 437 of /var/www/vhosts/fly7/includes/database/mysql/schema.inc).

I do not know what this means from the instructions above:

Remove the "system_list" INDEX from your system table

I searched w/ phpmyadmin for system_list but could not find anything.

Thanks!

@j9

follow PsySal suggestion (#13 post), your problem will be solved..

system_list is in "system" table, its not field its an index..

give this in phpmyadmin to remove index

drop index system_list on system;

The drops and alters i had to do:

drop index system_list on system;
alter table url_alias drop column alias;
alter table url_alias drop column source;
alter table menu_router drop column context;
alter table menu_router drop column delivery_callback;

since system_list is a core part , all the core DB updates should happen automatically without error(no matter how many times you run update script) , and this still exists in the current stable 7.14 version,

I am marking this as a bug.

You can only run update.php once - if you get failures, you need to restart the upgrade process from the beginning (for this reason you should make a backup of your site, and upgrade the backup then switch it over when it's completed successfully).

@madhusudan and lasac -- sweet thanks! much appreciated!

drops and alters i needed to get it going:

drop index system_list on system;
alter table url_alias drop column alias;
alter table url_alias drop column source;
alter table menu_router drop column context;
alter table menu_router drop column delivery_callback;
alter table menu_router drop column theme_callback;
alter table menu_router drop column theme_arguments;
drop table role_permission;
drop table date_format_type;

I didn't do update.php before.

Same problem, same solution as #22.

I also had this problem and the solution as it was in other cases was to simply drop any index or field that was throwing the error. The tricky part is that you may have to drop multiple fields and multiple indices as people above have had to do, but each time you run the updater, it re-creates those same indices and fields that you needed to drop in the first place. So where this gets frustrating, is that each time you find a new error that prevents your upgrade from succeeding, you have to backtrack and repeat every single step that you already applied, plus a new one to remove the new obstacle that you discovered.

To save you time, maybe you should just try the drops that are in # 22, but it's possible that even that solution leaves out some potential problem fields that are in your installation, but not other peoples.

Point of clarification:
The problem is caused by the extra tables that are created during the upgrade process. There are essentially two solutions...

1. roll back your database, or
2. manually remove the extra tables.

Just in case anyone experiences the same trouble I had:
Rolling back the database is only an option if it is "clean"...
...it wasn't working for me, and I couldn't figure out why. It turns out, that I had attempted to upgrade at some prior date without rolling back the database at that time. The extra tables that had been created had no adverse effect on the d6 installation, so I had forgotten the previous attempt to upgrade. So when it came time to attempt an upgrade again, rolling back the database was no longer an option because the database I was using already had the extra table in it... the only remaining option was the alternate solution of removing the extra tables manually. I took the advice in #24, and started with the drops in #22, which worked fine for me.

Extending from #22, I had to use these queries:

DROP INDEX system_list ON system;
ALTER TABLE url_alias DROP COLUMN alias;
ALTER TABLE url_alias DROP COLUMN source;
ALTER TABLE menu_router DROP COLUMN context;
ALTER TABLE menu_router DROP COLUMN delivery_callback;
ALTER TABLE menu_router DROP COLUMN theme_callback;
ALTER TABLE menu_router DROP COLUMN theme_arguments;
DROP TABLE role_permission;
DROP TABLE date_format_type;
DROP TABLE d6_date_formats;
DROP TABLE d6_date_format_locale;
ALTER TABLE locales_source DROP COLUMN context;
ALTER TABLE sessions DROP COLUMN ssid;

Relating to that last query with the sessions table, mine had nearly 16M rows, so truncating it helped also.

Wasted a whole day, trying to prepare a D6 site for a upgrade to D7. Ran ./update.php once, immediately was hit by crude error messages like the following, all on the same page:

1)

The website encountered an unexpected error. Please try again later.

2)

DatabaseSchemaObjectExistsException: Cannot add index system_list to table system: index already exists. in DatabaseSchema_mysql->addIndex() (line 445 of /var/www/{mysite}/includes/database/mysql/schema.inc).

3)

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => 9cda2e1efa6aca6ea4ad5993e63b8b6b [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /var/www/{mysite}/includes/session.inc).

Multiple errors at once? Which one ist it that kills ./update.php, no. 2 or no. 3? Does it really help to "try again later"?

Tried suggestions from #18, then #22 and finally #26. None of these allowed me to proceed with the Drupal core upgrade which is important, everybody keeps telling me.

Especially interesting is my last attempt (#26), which started with:

DROP <strong>INDEX system_list</strong> ON system;

And resulted in this error:

DatabaseSchemaObjectExistsException: Cannot add <strong>index system_list</strong> to table system: index already exists. in DatabaseSchema_mysql->addIndex() (line 445 of /var/www/{mysite}/includes/database/mysql/schema.inc).

If ./update.php recreates this table and then dies because of the table it just created, I'd consider this a BUG!

If this is "normal behaviour" for Drupal, just shoot me dead.

However, this nonsense makes it impossible to upgrade from Drupal 6 - which is EOL - to the next supported major release.

Reset issue status.