Cannot upgrade from Drupal 6 to Drupal 7 - meta issue

confirm error on wamp new install drupal-7.x-dev.tar.gz dated 8/29/2009

shows:
* Warning: filectime(): stat failed for modules/search/search.extender.inc in _registry_parse_files() (line 127 of C:\wamp\www\drupal-7.x-dev\includes\registry.inc).
* Warning: filemtime(): stat failed for modules/search/search.extender.inc in _registry_parse_files() (line 128 of C:\wamp\www\drupal-7.x-dev\includes\registry.inc).
* Warning: file_get_contents(modules/search/search.extender.inc): failed to open stream: No such file or directory in _registry_parse_files() (line 132 of C:\wamp\www\drupal-7.x-dev\includes\registry.inc).

add missing file, fixed

I'm sorry, I should have left it as it was. live and learn.

Hmm.. Not with an upgrade, but ran into this issue trying to generate content with the Devel module and wondered if it might be related -- /batch?op=start&id=7

This may not be close enough.. I do yearn for the good old days of simple SQL errors rather than this PDO stuff which makes no sense!

Haven't quite figured out netbeans utility for producing a proper diff so enclosed are the changes I made to get through the first issue with the system table and PDO out of range exception. I've attached a patch (first attempt), probably isn't drupal format but i'm getting there

// $Id: update.inc,v 1.11 2009/09/29 15:13:54 dries Exp $

Line 159

I'm not sure if this is the proper place but it converts a 6.14 table to the 7.x equivalent.

Damien

Update.php $Id: update.php,v 1.305 2009/09/28 22:16:32 dries Exp $

callls these lines around 266

the problem I was experiencing had to deal with the system tables in 6.14, the weight was valued at tinyint(2). Where I ran into problem was trying to update 6.14 to 7.x. Every time I tried it, it fatal errored with a PDO excpetion. the weight array value I could see was 1000 which would cause the out of range error. If I run a 7.x install to setup the database I don't get this with update.php

If you look in update inc for

when I added the code to update a 6.14 system table to match 7.x the problem disappeared. The error was only on the weight field but I went ahead and changed all but the type fields lenghts to match. Maybe when I upgraded from 6.12 to 6.14 something broke. But with the 6.14 weight field I had at a value of tinyint(2) the change was necessary to get update.php to the next step which is still broke with missing tables.

@ctmattice1: This issue needs to remain a meta-issue, so I opened a separate bug for this: #601642: Old databases might have a small {system}.weight.

another issue for d6 and d7 #603498: Book {blocks.cache} upgrade path

Apply #612920: {url_alias}.source required for upgrade and #585628: Cannot use update.php as anonymous user I can get updates to run.

Remaining issues once this patch is applied, don't have time to open separate issues for each one:

This is from system_update_files_database().

Now that update.php gets to the end, this is the output we actually get from it - several errors in there, probably most of these were introduced when update.php was broken, so easier to find the issue those were updates were committed and re-open I think. No time for that now, but would be great if someone could take it on.

Tagging 'novice' since this is mainly an issue queue farming task at this point, although it'll be quicker to use cvs annotate to track down where commits happened.

This is an intermediate patch which fixes some of the update functions (but not all). No time to split it into the appropriate issues but hopefully it can help someone getting started with it. This patch worked for me and I was able to upgrade a few dozens of node to the D7 field API :). I haven't fixed taxonomy because it requires to be run before the node update. Make sure to remove the taxonomy record from the system table before attempting any update with this patch.

I would like to commit this, but there are a bunch of commented-out lines. Should these be deleted, or are they just parts that haven't been fixed yet?

Patch should take care of the

Here's an improved patch that makes it so that Node module can run its updates without tripping over Taxonomy. I'm not sure if it's a good approach, but I got around Taxonomy module's requirements by setting the weight of Node module to "1" in update_fix_d7_requirements(), then setting it back to "0" in node_update_7000(). It's a bit hacky, but it definitely allows node.module to run last after other modules have gotten their Field system adjustments in place.

There's still a couple of TODOs that need to be cleaned up, so I'm moving this to needs work.

This patch is fully working, with all TODOs removed. In my testing Upload.module does not upgrade itself properly, but I'd like to just say "screw upload.module" and fix that problem by removing it entirely in #563000: Provide upgrade path to file, which I also have working now when applied in combination with this patch.

Just tried with 'clean' Drupal 6.14 install, and somehow this patch requires the upload module to be removed otherwise the ordering of the modules is messed up and node gets executed before taxonomy. Although the weights are applied correctly in the db, drupal_get_installed_schema_version() returns a different ordering depending on whether upload module is present in the code base or not. I find this odd. Anyone care to enlighten me? that makes this patch dependant on #563000: Provide upgrade path to file.

@quicksketch, could you repost your instuctions from #563000-41: Provide upgrade path to file with whether the order of the update is correct or not please (in the collapsed fieldset at the selection step)? I tried with an old Drupal 6 site and it broke everything. I suspect there are other modules causing the same type of problems as upload.

Oh dear, I thought modules would at least be updated according to their weight, but it looks like that is not the case. Are we really going to be trapped without an upgrade path until #211182: Updates run in unpredictable order is finished? Perhaps we can implement a basic "updates follow their module weight" for starters so we can get our basic upgrade working. It looks like the circular dependency checking in #211182 is not exactly ready.

Well... regardless here's a patch that now makes our upgrade path work by adding an ORDER BY clause to our retrieval of upgrade modules. This should now work except for the error caused by Upload module, but that won't be a problem if you've never enabled the upload module in you sandbox sites. It'd be great if #211182: Updates run in unpredictable order gets done, but at least this will make updates run like everything else in Drupal, by weight then by name.

I would absolutely love to commit this patch!

However.

That temporary re-weighting of node module in update_fix_d7_requirements() is a no-go. That function runs by just *touching* update.php, and needs to be non-destructive. Someone should be able to back out D7 files and go back to their D6 site, perhaps with a few extra tables/indexes, but not with a core required module's weight suddenly shifted around, which I'm quite sure would break tons of contrib modules that make the assumption (reasonable or no) that node.module's weight is always 0.

Another forgotten table "semaphore"

#627338: Add a cache_bootstrap bin removed the cache_registry table so the system_update_7006() hunk fails. rerolled patch.

add beta blocker tag for the patch here.

The list of issues are :

1) typo in node.install :
db_upddate to db_update

2) incorrect usage of UpdateQuery fields method
fields(status, 1) to fields(array(status, 1))

3) missing db_change_field
was incorrectly removed in http://drupalcode.org/viewvc/drupal/drupal/modules/node/node.install?r1=...
the 'module' column was not being renamed to the base column

4) a bunch of incorrect modifications of a non-existent 'user' table in user.install
it is now, and has always been 'users'.

5) taxonomy_update_7002 needed to be run before node_update_7006
i fixed this by adding a taxonomy_update_6002_run variable, and calling the update
function directly from node_update_7006.

@sun do you know that other issue?

I found an issue with comment module update. The error was "Call to undefined function field_attach_create_bundle()".

field is a new and required module. Is it enabled out of the box?

Subscribe

1) The inline comment is a bit sparse.

2) Additional parenthesis not required in the condition.

3) Should call the reset function.

Wrong PHPDoc indentation.

Could also use a separate, more lengthy PHPDoc description about what this function is for, where the defined value is going to be checked, and when it is intended to be used - and when NOT.

A @see to the reset function wouldn't hurt either.

Wrong @param syntax.

I don't see how the second condition could ever be not met. Which in turn means that the entire condition is superfluous.

Why not

drupal_session_ttl()

?

And why 15 minutes? The inline comment should explain.

I'm on crack. Are you, too?

Adding #450540: Upgrade instructions recommend enabling stark in D6 to this meta issue to track.

In case you forgot: Upgrading from D5 to D6 required users to perform very tricky preparations and contrib to invent some nasty hacks to get the upgrade path only remotely right. Upgrading to D7 will have a lot more problems like that, especially when considering the module namespace clashes we purposively introduced as well as renamed modules and the entire CCK upgrade path.

@clemens, at the moment, contrib module authors can't even test the most basic of upgrade paths because core's throws errors all over the place. I don't see any harm fixing this critical bug using the existing, albeit a bit crappy, API. Then fix the API in it's own issue, which is also marked as a critical bug, so shouldn't slip through the cracks unless it's reclassified.

For now, let's be honest with the status here, nothing happening until either the update order bug gets fixed, or it ceases to be a blocker here.

I think I'm going to give the dependent issue until Thursday the 14th to get fixed, and if it isn't, we're going to go with Adrian's solution, and document it as a workaround. I agree with him that this is ridiculous.

Re-test of drupal7_update_work_563106_53.patch from comment #53 was requested by webchick.

Here is re-roll with changes:
1) I see no reason in drupal_session_keep()
2) taxonomy_update_7004() adds taxonomy_term_reference not taxonomy_term
3) sequences table used by batch so moved to reqiurements
4) node_update_7006 set $info->old_type = $info->type; else no content types are available after update
5) filter_update_7004() tabs replaced by spaces

Batch totally broken after #629794: Scaling issues with batch API

subscribing

Another round, now update process completes with only one warning

But after another run update.php it works

Still problem with viewing node body

Node body was broken because my D6 setup was multilingual and field_multilingual_valid_language() returns only one (default) language for body field... but this for another issue.

comment_update_7005() seems totally useless because:
1) runs before node updates
2) does nothing because original comment_node_type_insert() still holds @todo and uses _comment_body_field_instance_create()

so creating comment fields and bundles in comment_update_7005() should run after node_update_7006()

Suppose we should commit this changes because mostly there's typos and lost code pieces and continue after #211182: Updates run in unpredictable order or after inventing ordered updates :(

i'm adding #606730: provide a helper function for block delta updates to this list -- it's a major upgrade PITA for module developers who use blocks, and it's tested and ready to go.

adding #684084: node_update_7006() broken after 'node titles as fields' rollback to the list.

added #685416: filter table renames aren't recognized by a later update

Some more fun: #685572: system_update_7008() is broken.

#686128: Body-to-field conversion is too slow

The patch at #211182-140: Updates run in unpredictable order should give you an almost working upgrade path.

RTBC per #63, I'm sick of that other issue, this is holding up contrib modules and random site db testers far, far more than dependent updates.

added comments to where taxonomy_update_7002 is called directly linking to the ordering issue.

removed the loop around the format column update as only the block custom table was still being updated.

The changes should be reviewed.

1. @@ -336,7 +336,7 @@ function filter_update_7005() {
   // instances (in Drupal core) to explicitly use the appropriate format.
   // Note that the update of the node body field is handled separately, in
   // node_update_7006().
-  foreach (array('block_custom', 'comment') as $table) {
+  foreach (array('block_custom') as $table) {

   The format column of the {comment} table is being removed from core, but its data is not. When does its data get the equivalent of filter_update_7005() performed on it if not here?

2. @@ -2246,6 +2246,7 @@ function system_update_7027() {
   $module_list = array('text', 'number', 'list', 'options');
   db_delete('system')
     ->condition('type', 'module')
     ->condition('name', $module_list)
     ->execute();
+  system_rebuild_module_data();
   module_enable($module_list, FALSE);

   This defeats any purpose of calling module_enable() with the FALSE parameter, right? Also defeats the purpose of calling the db_delete() query right above it. I believe that db_delete() query was added in #490074: 6/7 upgrade path broken as an attempt to make the D6->D7 field updates work nicely for sites that have D6 contrib versions of CCK modules lying around... however, doesn't seem like that's effective anyway.

The existing patch at #211182: Updates run in unpredictable order fixes #1 by adding a correct dependency between the filter and comment updates, and #2 by removing the db_delete() altogether. If we want to get a quick patch to commit here, I think it would be best to use the same approach already worked out there.

They were field-ified as far as i can tell. The columns were summarily dropped entirely.

I think that's true. But the process of fieldiying them means that their text formats were copied to a fields database table. I don't believe there's update code anywhere else that would perform the equivalent of filter_update_7005() on them once they are in that table, meaning that some comment text formats would not wind up being correct.

1) old records for previous versions of those modules (from cck) need to be purged
2) after this is called records for the new modules with the correct status and possibly schema version (although none of these modules have .install files) need to end up in the table.

I agree that's the (ideal) goal, but neither current core nor the patch here does that. The issue is that if you call:

then system_rebuild_module_data() just puts back in the database exactly what db_delete() took out (this is because CCK is typically going to be in sites/all/modules or somewhere, which takes precedence over the core module locations)... so you still can't upgrade your site with D6 CCK modules lying around.

That's not for this issue to fix (it might not be fixable without manual intervention), but my point is just that the above two lines of code do nothing when combined together. Instead of adding system_rebuild_module_data(), this patch could remove the db_delete() instead, and it should work just as well.

Failed: SQLSTATE[42000]: Syntax error or access violation: 1170 BLOB/TEXT column 'location' used in key specification without a key length

I cant reproduce this, which update throws this?

Ok, DamZ pointed me to the issue. The problem is that i18n adds an index to that table, and indexes on TEXT columns need a length.

@adrian, yeah, that sounds like it might work - although not totally sure how we prevent it from being overridden, since it seems like that would happen again as soon as someone rebuilds the module data, which could be done by more or less anyone.

In any case, it seems like there should probably be a separate issue for getting the upgrade to work for people with D6 CCK in their installations, since there are at least other workarounds for that? - and this patch isn't going to make the situation any worse if the current technique being used was already broken :)

For now, here is a reroll of the previous patch with minimal fixes for the issues I identified above.

Subscribing

Quick question about D7 dev download. I would like to test #101. The download says it was produced January 26, 2010 - 10:04. #104 mentions a commit and is dated January 26, 2010 - 07:33. Do these commits go straight into the dev download?

RT #105: I guess there might be a delay between a commit (for example #101) and it being available in the tarball (Drupal 7.x-dev tarball).

You should definitely use CVS to work with the dev version. You would always have the latest code.

That being said, I really don't know how fast tarball are generated.

Upgrading my Drupal 6 to Drupal 7 CVS of today, give this errors.:

Some warnings that don't break the site...

And run all updates(113) very fast, at the (111 update) and give lots of time..

At linux shell executing TOP command:

So, I restart the update and show me:

I have 5167 nodes, and 1411 users..
What is the problem with update the user module?

The upgrade process don't give any error, neither timeout error...

I press Esc, and click in show errors:
Give:

# Drupal 6.15 to Drupal 7 CVS Today
# PHP 5.2.10-2ubuntu6.4
# Apache/2.2.12 (Ubuntu)
# Versión del cliente: 5.1.37
# Ubuntu 9.10 Server

fix the poll_update_7002

Can any one give a review of this simple patch in #112, the bot was allready pass this one 6hours ago...

User 7004. That continue; has got to go. It makes the code loop if the last user goes through continue because of a missing file. I changed if (!file_exists($user->picture)) { to if (file_exists($user->picture)) { and wrapped the if down to the end of db_update('users'). The change makes users all users, including those with missing files, go through the position update. No more infinite loop in user 7004.

I haven't been able to test this patch, but looking at the code, it looks good to me.

One question though; if the $user->picture does not exist, is that because we have an invalid path or because we have an empty path? If it happens to be the case that the path is wrong, one could argue that the $user object is in an inconsistent state. Should we consider empty-ing $user->picture when that is the case?

#116 looks fine too visually, didn't test it. Suggest we commit both that and #112 to keep this moving.

#112 needs committing as well.

my patch in #112 was not been committed yet.. (pool_update_7002_02.patch)

Well that was quick:

"An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://localhost/webchick.net/update.php?id=4&op=do StatusText: OK ResponseText: Fatal error: Call to undefined function field_attach_create_bundle() in /Users/webchick/Sites/webchick.net/modules/comment/comment.install on line 149"

Call Stack:
0.0071 163140 1. {main}() /Users/webchick/Sites/webchick.net/update.php:0
4.0619 15155836 2. _batch_page() /Users/webchick/Sites/webchick.net/update.php:388
4.0633 15157192 3. _batch_do() /Users/webchick/Sites/webchick.net/includes/batch.inc:81
4.0633 15157480 4. _batch_process() /Users/webchick/Sites/webchick.net/includes/batch.inc:163
4.9624 15272576 5. call_user_func_array() /Users/webchick/Sites/webchick.net/includes/batch.inc:286
4.9624 15272576 6. update_do_one() /Users/webchick/Sites/webchick.net/includes/batch.inc:0
4.9625 15274308 7. comment_update_7005() /Users/webchick/Sites/webchick.net/includes/update.inc:689

@webchick error in #125 should be fixed by #211182: Updates run in unpredictable order (the comment update are run before system.install had the chance to install the field module.)

#112 applies cleanly, latest change for poll.install was Dec 4th, and it still contains db_add_field('poll_votes', 'timestamp', $field); which is what #112 fixes.

RTBC #112 again? :)

Today #251792: Implement a locking framework for long operations commited to 6 so updates should be changed

using todays head and #211182: Updates run in unpredictable order latest patch http://drupal.org/files/issues/211182-updates-180.patch I get the follwoing php error

Initial database does not contain a field table.

Hm. Nope, I can't see that causing a problem. That'd only be if the sentence contained an apostrophe.

Could you elaborate a bit more? At what point do you get an error? At the main update.php page, or after starting the upgrade process, or..? And what is the error?

@webchick

"Could you elaborate a bit more? At what point do you get an error? At
the main update.php page, or after starting the upgrade process, or..?
And what is the error? "

WSOD on update.php, error is the same as above

[03-Feb-2010 15:59:31] PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column 'value' in 'field list'' in C:\sites\d6d7\includes\database\database.inc:1940
Stack trace:
#0 C:\sites\d6d7\includes\database\database.inc(1940): PDOStatement->execute(Array)
#1 C:\sites\d6d7\includes\database\database.inc(586): DatabaseStatementBase->execute(Array, Array)
#2 C:\sites\d6d7\includes\database\mysql\query.inc(37): DatabaseConnection->query('INSERT INTO {s...', Array, Array)
#3 C:\sites\d6d7\includes\update.inc(522): InsertQuery_mysql->execute()
#4 C:\sites\d6d7\update.php(378): update_fix_d7_requirements()
#5 {main}
thrown in C:\sites\d6d7\includes\database\database.inc on line 1940

Tracing PDO Exceptions is a ROYAL pain!

On a side note my D6 database also has a sequences table.

This particular database is a copy of a d5 site, brought to my local environment, updated to 6.15 then attempted to update to d7. I've been using this database and found #601642: Old databases might have a small {system}.weight which is now RTBC.

db_create_table() auto-checks db_table_exists(), so that's not the problem. The problem is that the D5 and D7 versions of {sequences} are different and I think we'll need to to a drop table if it exists before the db_create_table().

Dave Reid - February 3, 2010 - 16:45

"db_create_table() auto-checks db_table_exists(), so that's not the problem. The problem is that the D5 and D7 versions of {sequences} are different and I think we'll need to to a drop table if it exists before the db_create_table()."

Was {sequences} used in d6?

Where we're changing the code from my understanding is in a place where if the update fails, d6 will still run from the database

The sequences table was explicitly left in Drupal 6, unused by core, so that contrib could transition away from it. I don't think anyone expected to put it back in, or that modules would keep using it.

A handful of Drupal 6 modules are using sequences, I've excluded ones where it only shows up in the .install file in the hope those are upgrade paths away from it:

delete_all/delete_all.module
devel/devel.module
marc/marc.module
phpbb2drupal/phpbb2drupal.module

Note there's an existing issue about this here #198987: Remove {sequences} table.

Given the number of modules (discouting mentions in .install) is so few, I'd suggest just dropping the table and adding a note in the 6/7 upgrade docs that it's been removed/refactored and they need to handle their own upgrade path by selecting MAX(id) from their own tables or whatever - modules have had two years to stop using it.

Downloaded from this morning. Loaded database. Deleted sequences table. Ran update.php. Reached update page with 106 pending updates and:
Strict warning: Only variables should be passed by reference in update_selection_page() (line 33 of H:\home\example.com\public_html\update.php).
Continue produced:
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'name' in 'field list': INSERT INTO {queue} (name, data, created) VALUES

Back to the start. Reload database. Drop sequences and queue. Create queue using SQL form a D7 test site. update.php. Ran through to completion. Really nice having the extra line of information telling me which update is in progress. Two failed messages.
filter module Update #7004
* Failed: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '3-0' for key 'PRIMARY'
block module Update #7003
* Failed: SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP 'list'; check that column/key exists

Logged in as administrator. No theme. No menu entries. I went to admin/appearance and set the admin theme to Garland. I like Seven but Seven was disabled.
Admin by task is empty. Admin by module has many entries.

block_update_7003() starts by dropping index list but there is no index named list. I removed the line. The next line creates index list but the index exceeds 1000 characters when you use fields theme and module as UTF8 so I put module in a separate index. The block updates run to completion. Blocks appear in Garland. When I try to allocate blocks in the blocks page, there are no regions listed.

There's a D6 backport of queue module which is likely what's causing peterx's problem, that should have the same schema as D7, so we should just do db_table_exists() there before trying to create it.

For sequences, maybe do db_table_exists() too and rename it to sequences_old?

Also marking this back to active since there's no current patch. I think it'd help if we opened individual issues for actual patches and linked from here from now on, otherwise it's easy to end up with multiple conflicting patches for different issues all in various stages in the one issue.

You must have at least one, I found:

@cmattice - it looks like your patch includes hunks from the system weight patch which are already in HEAD, so it won't apply.

Only comment issues otherwise - should start with a capital letter, end with a full stop/period. I'd also remove the TODO - if a contrib module salvages data from that old table, it can also take care of dropping it.

Before I reroll, here are my findings

Set access bypass to TRUE in settings.php, started up the update process from where I left off.

Required 111 update steps

it ran through

node
comment
system

picked up

user at step 80
profile at step 100
search at 104
and tracker at 111

Proceeded about another 30-45 second then fataled with

Fatal error: Call to undefined function field_attach_delete_bundle() in C:\sites\d6d7\modules\comment\comment.module on line 321

Checked the database found several content_type_"modules" all with 0 rows
There is no field_ tables.

Possibilities system did not install complete D7 schema or there is a problem with core's field module not enabled.

Any Ideas? Though system was suppose to update first but this may not be what's happening. It could be that the update processes is not installing required tables first.

Berdir: Actually, I think this should now be using hook_update_dependencies()?

So the issue is that update.php cannot be bootstrapped multiple times, and every single operation performed in update_fix_d7_requirements() can lead to an error.

We therefore have to make sure that we can at least get behind a WSOD in case of a previous error.

Additionally, db_index_exists() doesn't seem to be used anywhere yet? How comes that the database-specific methods use an entirely different function signature? ;)

That's very possibly a stupid remark, but instead of making sure update_fix_d7_requirements() is idempotent by adding lots of lots of if (!db_column_exists()), if (!db_index_exists()) code
- can't we make sure that it gets called only once in a lifetime ? a variable or something ?
- or cant we use one single tell-tale criteria to determine it has already run and should just return ?

In my last attempt on todays head
I used

It ran for 4 minutes then fatal error-ed with

The variable does get set when this function completes

@yched: We set a variable already, but naturally, it's only ever set if the code reaches the variable_set() line.

My guess is that the "queue" table only existed, because update.php was bootstrapped more than once.

Regarding the sequences table, my patch uses db_column_exists() to directly check for the old {sequences}.name column of D5. Only if that column exists, the table is renamed.

I grepped throughout core and db_index_exists() indeed doesn't seem to be used anywhere yet - thus, no one realized the wrong function signature.

Additionally, I commented out that ini_set('display_errors', FALSE); because I think we should be a bit more verbose - at least until we're out of alpha. Only after doing so, I was able to see the PDO exception that lead to a WSOD.

#607238: Permissions are assumed to be unique among modules, but uniqueness is not enforced caused the user module fatal error, attached one line patch there.

Started update from where I left off and it completes.

There is still a problem though. on the completion page I get

* Notice: Undefined index: update_success in update_results_page() (line 159 of C:\sites\d6d7\update.php).
* Warning: reset(): Passed variable is not an array or object in update_results_page() (line 163 of C:\sites\d6d7\update.php).
* Warning: array_pop(): The argument should be an array in update_results_page() (line 163 of C:\sites\d6d7\update.php).

adding #706842: Improve comments for the taxonomy upgrade path

The last submitted patch, fixupdate_0.patch, failed testing.

here's a patch i used to test the newly merged drush updatedb command in drush head.

drush is a lot less error tolerant about updates , so it catches more problems.

mostly it was about the order of the updates that weren't quite right :

before filter 7005 can run, you need to run user 7006 and taxonomy 7002 and system 7037
but before you can run user_7006 you need to have run filter_7002

We were also creating the system_list index in duplicate, once in update.inc and then in system 7018.

Looks good apart from the quotes around 7006. Fixed those and committed to HEAD.

Back to active.

Er... So this doesn't look like a meta issue at all. :) From my understanding, a meta-issue is used to track *other* issues and patches are submitted there. If we keep on addressing every single upgrade problem here, the issue is going to get horribly big and it makes it harder for new people (like me!) to get involved easily. I'll try to tackle some of those now anyways.

I'm okay with that, but what's happening with that is that we're processing a lot of particular details, it's exactly the problem we're having here. :)

For example, by reading through this issue quickly, I missed the discussion about the sequences table, and filed a separate bug about it: #719730: drop the sequences and queue tables from D5 during the D6 -> D7 upgrade. I hereby encourage people to take the discussion about that issue to the other place.

I will file other issues regarding the upgrade process in separate issue (if i still have time) and keep this issue to general discussions regarding overall strategy.

combined patch from #719850: errors in update.php during bootstrap yield a blank page with {queue} and {sequences} table fixes. I did get the update to process to completely empty the {queue} table (284 entries) but only after changing update.php to not clear the cache.

patch attached but updating is still not completely there yet, now I get a error trying to log into the site. Tried clearing cookies and cache but didn't help.

Excellent, let's kill this issue. I have opened a new meta-discussion issue in #722074: Drupal 6 to Drupal 7 upgrade path meta discussions in case there's any followup. I made it very clear in the new issue that patches and issue-specific discussions should not take place there so I hope it doesn't degenerate the same way as here.

@vindesh: This issue is closed. You need to open a new one or search for an issue that is still opened about the same subject.