If you have a "pre-apocalypse" copy of D8 hanging around (git checkout 3629b1fd8bd) it's impossible to move from there currently.

You go to your front page and you'll get a WSOD. When you go to update.php you'll see that is because:

Warning: require_once(/Users/abyron/Sites/8.x/modules/entity/entity.controller.inc) [function.require-once]: failed to open stream: No such file or directory in _registry_check_code() (line 3059 of /Users/abyron/Sites/8.x/core/includes/bootstrap.inc).

Running through update.php though, because there are no DB updates, means no caches ever get cleared so you still have that problem after running update.php.

catch pointed me at http://drupal.org/node/534594#comment-4583592 but that didn't help anything (presumably because I'd need to be able to clear cache to get that alter to take effect).

This is a HEAD -> HEAD upgrade, so I'm not sure we care, but it's certainly going to make re-rolling those 10,000 patches a lot harder. :\


Dave Reid’s picture

Um, I care. A lot.

webchick’s picture

An immediate workaround is just adding this to system.install:

function system_update_8002() {

but that of course will leave your D8 install out of sync with whatever 8002 actually is, so is not recommended.

quicksketch’s picture

Yeah, to be clear the only real problem here is that the cache tables contain a bunch of old paths. Just running TRUCATE on your cache tables will clear everything up. Or make an empty update like webchick suggests. I personally think this is the perfect "no d8 to d8 upgrade path", since it's trivial to get working again and doesn't cause a problem on d7 to d8 upgrades or on new installs.

webchick’s picture

Status: Active » Closed (won't fix)

We discussed this in IRC and decided that since #3 is a reasonable, non-data-destroying workaround, there's no real point in making an empty update function for this.

Marking "won't fix" and documented the workaround in the change notice at http://drupal.org/node/1327978.

sun’s picture

claudiu.cristea’s picture

Status: Closed (won't fix) » Active

Still getting WSOD after truncating all cache* tables:

[01-Nov-2011 21:53:19] PHP Fatal error:  require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/Users/clau/Documents/development/d8/html/includes/database/select.inc' (include_path='.:/Applications/MAMP/bin/php/php5.3.6/lib/php') in /Users/clau/Documents/development/d8/html/core/includes/bootstrap.inc on line 3081

What else?

claudiu.cristea’s picture

The registry still keeps old paths. How to rebuild?

EvanDonovan’s picture

Try http://drupal.org/project/registry_rebuild. I think this can be closed again, right?

plach’s picture

neclimdul’s picture

Seconding this as a serious problem. I'm currently trying to bisect across the core move hosing and yuck... we really need to deal with this. Its a problem with #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap and a number of other d7 issues and all we do is say "tread carefully", "we don't support that" when really we're saying "sorry we don't support our own development"

neclimdul’s picture

dope, sorry about tag.

also, @EvanDonovan i just confirmed registry_rebuild doesn't work on 8.x so that's not even an option...

claudiu.cristea’s picture

@neclimdul, Registry Rebuild tries to include entity.inc which was moved to a module. This is the first reason why is not working. The second might be the "/core" exodus.

neclimdul’s picture

@claudiu.cristea yes, it includes every file directly rather than using the drupal bootstrap because it can't trust it to work. Each path is hard coded to /include so it definitely is broken by the /core move. Feel free to discuss it here #1332950: Support 8.x post /core move

webchick’s picture

I haven't tested it, but there's a D8 version of Registry Rebuild at #1328718: D8 port. Does that help?

catch’s picture

Issue tags: +D8 upgrade path

@neclimudul and @Dave Reid - if people want to start trying to support the upgrade path I'd be happy for that to happen during the 8.x cycle and treating unrecoverable breakage like this as critical bugs.

I've opened #1333898: Support unstable2unstable upgrades? [policy, no patch] to discuss that properly, and I'm happy leaving this as a critical bug until we've had that discussion.

webchick’s picture

Status: Active » Fixed

There is now a system_update_8002(), and in addition update.php clears the cache / rebuilds the registry now when you submit it. That was the problem before; there was no way to trigger this short of using the Registry Rebuild module.

Therefore, while there are other problems with the D8 upgrade path atm, I think this particular one is fixed.

Automatically closed -- issue fixed for 2 weeks with no activity.