in #1784312: Stop doing so much pre-kernel bootstrapping introduced a BootstrapConfigStorageFactory which I don't understand at all. It references $conf['drupal_bootstrap_config_storage'] but is the only place in core to do so. I also don't see that part discussed in this issue at all.

I'm hitting this in the D7 -> D8 upgrade path. BootstrapConfigStorageFactory is called from DrupalKernel::registerBundles which is called (a couple levels up in the stack) from DrupalKernel::boot() right in update_fix_d8_requirements(). Most importantly this is called before checking if settings.php exists. Excerpt:

  // Bootstrap the kernel.
  // Do not attempt to dump and write it.
  $kernel = new DrupalKernel('update', FALSE, drupal_classloader(), FALSE);
  $kernel->boot();

  // Check whether settings.php needs to be rewritten.
  $settings_exist = !empty($GLOBALS['config_directories']);

Therefore in BootstrapConfigStorageFactory the call to config_get_config_directory() happens with empty global $config_directories and everything blows up. I have no idea how the upgrade path even remotely works at this point (it doesn't for me locally). The reason I am not opening a new issue is that I am not able to make any sense at all of BootstrapConfigStorageFactory.

The attached patch resolves the fatal at least, but update.php still doesn't spit anything out.

CommentFileSizeAuthor
#4 1943726_4.patch3 KBchx
#4 interdiff.txt632 byteschx
#2 1943726_2.patch2.32 KBchx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Status: Postponed (maintainer needs more info) » Postponed

I think this comes from http://drupal.org/node/1856972 . The call chain is update_fix_d8_requirements, update_module_enable, config() , kaboom.

chx’s picture

Priority: Normal » Critical
Status: Postponed » Needs review
Issue tags: +Needs manual testing
FileSize
2.32 KB

Wait, no, update_prepare_d8_bootstrap runs first, and that calls kernel before the config dir is set. It's not update_fix_d8_requirements(). Comments say:

drupal_install_config_directories() calls into install_ensure_config_directory(), which calls into file_prepare_directory(), whichs calls into file_get_stream_wrappers(), which attempts to invoke hooks with a non-existing module/hook system.

Not anymore, no:

function file_prepare_directory(&$directory, $options = FILE_MODIFY_PERMISSIONS) {
  if (!file_stream_wrapper_valid_scheme(file_uri_scheme($directory))) {

file_uri_scheme($directory) returns a FALSE and

function file_stream_wrapper_valid_scheme($scheme) {
  return $scheme && class_exists(file_stream_wrapper_get_class($scheme));

shortcuts the stream wrapper call. This has been accidentally fixed on December 29 in #1874612: Simplify file.inc by file_stream_wrapper_valid_scheme(FALSE) return FALSE.

Status: Needs review » Needs work

The last submitted patch, 1943726_2.patch, failed testing.

chx’s picture

Status: Needs work » Needs review
FileSize
632 bytes
3 KB
andypost’s picture

@chx Please provide a steps for manual testing. Which modules should be enabled.

Also there's related issue #1919002: Upgrade to D8 broken when D7 has more then one language enabled

chx’s picture

Well, if you have a D7 site and you try to upgrade it to D8, it would seem that the update currently can't work, at all, and that's what tstoeckler reported. I am not 100% how to reproduce it myself. I am not sure either why the automated testing is passing because UpgradePathTestBase::setup calls TestBase::prepareEnvironment which calls $this->prepareConfigDirectories() but that is overridden in UpgradePathTestBase to do nothing. And config_get_config_directory() have a special case which uses the configuration directory prepared in prepareConfigDirectories for all tests. This probably needs further research, if someone can post detailed reproduction instructions, that'd be helpful.

andypost’s picture

There was 2 kernels #1885964: Avoid the creation of more than one DrupalKernel instance because of drupal_verify_profile()

alippai’s picture

Before applying the patches I get errors:

PHP Fatal error:  Call to a member function get() on a non-object in /var/www/core/includes/theme.maintenance.inc on line 59
PHP Fatal error:  Call to a member function get() on a non-object in /var/www/core/includes/config.inc on line 106

The patch fixes these errors however I get stuck here, so I can't complete the installations. The php error log is clean, a bunch of watchdog entries say that Theme hook %hook not found.

Testing environment: Debian Squeeze with dotdeb.org repository, Apache 2.2, PHP 5.4, MySQL 5.5, APC enabled. D8 and D7 works without problems. Used 'Standard' installation profile, only the default modules enabled. Upgrade run in maintenance mode.

alippai’s picture

Status: Needs review » Reviewed & tested by the community

After cache clear and theme registry rebuild it works. I think it needs a follow-up issue, but this is RTBC.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Well that certainly seems to clean up a lot of ugly code! The testing instructions around this (or even what the bug itself is) seem a bit sketchy to me though, and I'm worried this might introduce some problems elsewhere. But I guess I'm ok with committing this to get it in front of more people and see what happens. :)

Committed and pushed to 8.x. Thanks!

YesCT’s picture

Issue tags: +D8 upgrade path

tagging.

sun’s picture

+++ b/core/includes/update.inc
@@ -131,24 +135,6 @@ function update_prepare_d8_bootstrap() {
-    // @todo Race-condition: drupal_install_config_directories() calls into
-    //   install_ensure_config_directory(), which calls into
-    //   file_prepare_directory(), whichs calls into file_get_stream_wrappers(),
-    //   which attempts to invoke hooks with a non-existing module/hook system.
-
-    include_once DRUPAL_ROOT . '/core/includes/module.inc';
-    include_once DRUPAL_ROOT . '/core/includes/cache.inc';
-    $module_handler = drupal_container()->get('module_handler');
-    $module_handler->setModuleList(array('system' => 'core/modules/system/system.module'));
-    $module_handler->load('system');

I doubt that this change was sufficiently tested.

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

Anonymous’s picture

Issue summary: View changes

Updated issue summary.