Installation failure: Missing configuration files

I was looking into this on @jenlampton's laptop and it doesn't seem to be related to a setting in PHP. It seems like a bug in Drupal\Core\SystemListing::scan().

There's this section of code in scan():

    // Search for the directory in core.
    $searchdir = array('core/' . $directory);
    foreach ($this->profiles($directory) as $profile) {
      $searchdir[] = $profile;
    }

The call to $this->profiles() is where things go wrong. If you look at the protected profiles method, it looks like this:

  protected function profiles($directory) {
    return $this->profiles;
  }

So the method profiles() does nothing but return $this->profiles, and it doesn't even use the single parameter that's passed to the method in the first place? This is really, really weird.

So I think what's happening here is that $this->profiles is both a VARIABLE and a METHOD. This is confusing PHP. When you say $this->profiles, it doesn't know what it is. I don't know how it's arriving at this result, but pretty much no matter what you pass into $this->profiles(), it will always return an array with a single value. i.e.

print $this->profiles('banana');

Results in:

array(
  [0] => '/banana',
);

So when "modules" is passed in, a search path of "/modules" is returned. The end result is that Drupal can't locate the core modules, which means it can't locate the config files they include, resulting in the error posted by @jenlampton.

This patch doesn't fix what is most likely a bug in the profiles() method. Surely that method is supposed to use the $directory variable that is passed in? But it renames the "profiles" method to "getProfiles", which avoids the PHP confusion and lets Drupal install and function normally.

SystemListing::profiles() was committed from #1831350: Break the circular dependency between bootstrap container and kernel in 6f3268.
Given the method comment, was implementation was never completed (I.e. listing profiles in the current directory).

SystemListingInfo overrides the profiles method

Go testbot go

I wonder if this works... I can not reproduce

I have this issue as well. I had removed the files folder in '/sites/default/files' folder and it resolved the issue.

I have this issue as well : I'm running wamp 2.2.22, php 5.3.13 and mariadb-5.5.24, the safe_mode is off and the open_basedir is commented. And I tried all the patches ; it failed.
I could install the d8 alpha4 with no issue, but not the d8 alpha5. Both fresh installs.

I am experiencing this issue on wamp 2.4 with php 5.4.16, and the patches don't fix it for me.

So I think what's happening is something like this - some exception is occurring somewhere and the theme system is trying to display the error but it can't. Looking at the "fix" in #2 I think the problem must be in SystemListingInfo::profile() (which is overriding SystemListing::profile()) and hence never called if the patch in #2 is applied.

@jenlampton I've tried to add some code to catch whatever is going on in there in the patch attached - if you get debug output if you can pastebin or something - thanks!

Also applying #2176105: Installer catches exceptions and manually re-prints them; does not use error/exception handler might shed more light on what is going on.

@jenlampton: Heya, some questions:

1. If I got it right, then you get this uncaught exception screen in the very first installer page, before you even see the installer - is that correct?
2. Do you have any custom installation profiles anywhere in your filesystem or is it a plain/unmodified core checkout?
3. Unfortunately, the error/exception handler is not working correctly in the installer and early bootstrap environment right now - could you try whether the patch in #2176105: Installer catches exceptions and manually re-prints them; does not use error/exception handler perhaps improves at least the error handling?

Alternatively, can you try once more with attached patch?

It contains the changes from aforementioned issue + some more error handler fixes.

It also forces the error level to be verbose in the early installer screens, which means that we should get a proper backtrace for the exception that you are seeing. → Given the backtrace, we can figure out where exactly the error is triggered from.

Note that the patch in #2194111: Error handler throws exception when service container is not (fully) available yet fixes the last remaining "errors caused by errors" problems. Once that has landed, we should be able to properly debug what's going here.