Install profile is disabled for lots of different reasons and core doesn't allow for that

Same Notice

After upgrading to 7.2, i am getting the following notice
Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of ...\includes\install.inc)

I get the same notice; I'm not entirely sure as I used the standard profile installation (and I see that profile/standard/standard.info still exists). Does it now get seen as a module?

I think this error would be expected if you forgot to visit update.php (or at least clear your site's caches) after updating the code to 7.2.

Can anyone confirm if clearing the site's caches fixes the problem?

I had upgraded my site using drush (and have cleared my site cache multiple times since) - everything works, but I still get the undefined index coming up on the module installation page.

OK, thanks. Let's call this a bug for now, then.

What I see is that it seems to pick up the name of the profile just fine (in my case, 'standard' - I see that there is a standard profile in the profiles directory). But when it gets to the next line $info = system_get_info('module', $profile);, that's where it can't seem to find it. I'll do some more digging tomorrow to see if can figure out anything else that might be of help.

Ok, so I was taking a look at the system table and I saw that the profile was marked as having a status of 0. I noticed that the list being returned from system_list($type) would only return 'modules' with a status of 1. I'm not sure how or why the profile was marked with a status of 0, but once I changed it in the db table, the issue went away.

OK i have the same error.

The profile module is a normal module to expand the user module.
but you shouldn't use it anymore in drupal 7 . You can do the sam things with fields

I have an standart installation of drupal 7 and the profile name must be "Drupal" but he can't find it. but when I debug the function he found the right profile standard that is saved in a global variable but he don't find the the distribution name "Drupal".

Normally the function returns a list of all enabled modules or themes. I can't find where he wants to get the distribution name.

In my system table are only themes and modules.

@klaus66, the profile also looks at modules. If you have a standard installation of drupal, the 'module' name will be 'standard'.

OK thank you I didn't know this.

I find the standard module and it was disabled.

Now I have enabled it and the notice go away.

I hope everything is ok now but my question is now who has disabled my standard module, I not.

Thanks, I changed my profile status to 1 at system table and the notice go away.

Hello cpelham,

You should see the following row entry in the system table,

#filename - #name - #type
profiles/standard/standard.profile - standard - module

cpelham : the system table may have more rows than you are viewing. View more rows or click the next button near the foot of the page
-------------------

I'm getting the same error but in my case seems to be related to an acquia profile.

In the system table, all I can see is profiles/acquia/acquia.profile with a status value of 0. Changing the value to 1 does not appear to work.

I think my version 7.0 install was acquia, although I had forgotton this. The version 7.2 that I have installed is standard.

Would changing profiles/acquia/acquia.profile to profiles/standard/standard.profile resolve the problem for me or do I need to get hold of an acquia release?

Thank you Steve,

Can the patch just be applied on a live site? Or should the install.inc file be patched before the upgrade?

There is already code in _system_rebuild_module_data() to set "Drupal" as the default value. The undefined index error in this case is just a symptom of the real bug.

If install profiles are getting disabled after upgrading to 7.2, that's somewhat serious and should be tracked down (plus we'll need an update function to restore them). If the profile is disabled then any code (e.g. alter hooks) the profile has defined won't run, which is a problem.

Unintentionally disabling modules (installation profiles) sounds like a critical bug to me.

I think it'd be wise to keep this critical unless we have proof that it's not critical.

Lastly, #17 can likely be ignored.

Anyone have exact steps to reproduce this issue?

I just tried an upgrade from 7.0 to 7.2 and did not experience any problem. My install profile is still enabled in the database, and consequently I don't get the PHP notices when visiting the modules page.

I thought maybe this was a symptom of #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap (which was in Drupal 7.2 but since rolled back) but if so, I haven't been able to figure out how to trigger it.

If you upgraded from Drupal 6 I think that might be the real issue here.

/**
 * Rename 'Default' profile to 'Standard.'
 */
function system_update_7049() {
  if (variable_get('install_profile', 'standard') == 'default') {
    variable_set('install_profile', 'standard');
  }
}

There is nothing to actually enable the profile.

Here's a rough patch, it enables the standard profile if it's set as the install profile, and not found enabled already in the database.

We can't use module_enable() since in this case we don't want hook_install() or hook_enable() to run, so it does a db_merge(), then have to rebuild the theme data to get info rebuilt etc.

Could potentially generalise this so it gets the name of the profile, checks if it's enabled, then does a similar query if not, but that will only catch contrib profiles where they already did a similar update to system_update_7049() in the first place to change the variable, so we may just want to tell contrib profiles that change name between versions to copy the same code.

This time with the patch. This is a D7-only patch since it just adds a new update, since only one person on this issue mentioned upgrading from D6 I don't want to jump the gun and move it back to 7 though.

Should add a test for this, should be easy to add to the main upgrade path test.

Aha... It looks like you identified the problem for the most part.

However, I don't see why this would be specifically related to renaming the profile? It looks to me like this will occur for all sites that upgraded from D6, regardless of what profile they used. D6 did not store the profile in the {system} table, which means the only way it gets there during an upgrade currently is via system_rebuild_module_data(), which will never enable something it finds in the filesystem for the first time.

That also seems to be borne out by what @stevepurkiss said above (he's using Acquia Drupal, which did not rename its install profile from D6 to D7).

So putting it together, maybe like this is all we need:

function system_update_7072() {
  if (!db_query("SELECT 1 FROM {system} WHERE type = 'profile' AND status = 1")->fetchField()) {
    system_rebuild_module_data();
    db_update('system')
      ->fields(array('status' => 1))
      ->condition('name', variable_get('install_profile', 'standard'))
      ->execute();
  }
}

That's a good point, forgot that profiles were never in the system table ever.

There should be a system_list_reset() after the direct update to clear caches, but apart from that the proposed change looks good.

Not quite the same thing, but #1136820: Allow drupal_get_filename() to work with the installed profile. is similar install profile breakage.

Moving down to 7.x for now.

Uploading David's suggestion from #28 with an added test. Also a patch with only the test.

Didn't run these locally, sorry for the noise if they fail but otherwise this should be ready.

@cpelham: could you let us know which install profile you used, and what the content of the system table are for it if any?

There's not testing the patches, then there's not even looking at them before uploading, bah.

Opened #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles for this bug on new D7 sites, even if it's the same symptom, it has to be a different bug to the one the patches here fix. That's currently marked needs more info since there aren't steps to reproduce yet.

This should fail.

Out of time to look into this now, but #35 should have failed, so back to CNW.

This is why it doesn't fail, we have that code, it's just buried in includes/update.inc

http://api.drupal.org/api/drupal/includes--update.inc/function/update_fi...

Marked the other issue as duplicate, back to square one here.

Did you use drush to update or update.php?

I just tested this, and was able to reproduce the bug when using Drush to update from 6.x to 7.x (with the default install profile).

Per @catch's findings, I was not able to reproduce the bug when using update.php to update from 6.x to 7.x. (Although that update code still seems a bit problematic; after going through update.php you wind up with a ghost entry for profiles/default/default.profile in the {system} table that doesn't seem to go away, in addition to the correct entry for profiles/standard/standard.profile which is enabled.)

In that case I wonder whether this is #820054: Add support for recommends[] and fix install profile dependency special casing.

iirc drush has some code to disable modules when their dependencies aren't found. If that is running for install profiles, then there will be many, many times where someone has disabled a 'required' module for a profile - drush may then treat the profile the same way as a normal module and disable it.

Haven't yet found that code in drush though but I remember seeing the message.

Here we are:

#898768: D7: drush dis [module] can disable profile.

Couple of options:

- Add a new core update to re-enable the install profile - IMO this is a core bug that drush has had to work around.

- Ignore it, make people run drush en -y standard themselves, mark this as duplicate.

Let's do this. Leaving as critical because a lot of people use drush, and this is a core bug which drush has had to work around.

Even with this patch applied, we'll still get reports of this until people update their drush installs.

#43: fix_disabled_profiles.patch queued for re-testing.

@cpelham, OK I re-opened #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles. It looks like the drush issue is a definite one, even if there could be other causes of the same bug. Please post as much information as you can on that issue.

Getting the same notice after upgrading a fresh minimal D7.0 installation to D7.2 (on Windows, (thus) no Drush).

I think it must be a core bug.
I only install the newest dev version and I have this notice. No change on erverthing else.

For me I set the status to 1 in my system table and then it is ok. But I must do this every time I update the dev version and this is at the moment often.

I am having the same error.

#43 looks reasonable to me. This should only be an issue with drush 3.x as we implemented a workaround in 4.

Looks good to me as well - I essentially did what your patch does and that fixed the issue.

I am removing the needs test 'cos what do you want test here? That the query worked? That's DBTNG tests.

Summary: When profiles were made into modules, the modules the profiles need were put in dependencies. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, install standard and disable comment. It is possible that there are some real dependencies for a profile if it implements hooks and needs those modules. Also, there is no "discover my dependencies and enable them before enabling me" used while installing, just $modules = $install_state['profile_info']['dependencies']; the 'dependencies key here could be anything else and for D8, #820054: Add support for recommends[] and fix install profile dependency special casing indeed suggests changing it.

Now, due to this faux-dependency Drush earlier decided to disable the faux-module because it's dependencies were no longer met. We need to fix this. Whether there are more problems we do not know yet but this is a must.

The problem is in the update.php script. When I run update.php then the status in my standart module is set to 0. I think this cannot be ok.

Tomorrow I debug the update.php and try to find out why.

Hm. I'm not sure about this.

I just did a fresh installation of Drupal 7.x-dev. The row for "standard" has a type of "module", not "profile". It's the same in the two other D7 installs I have on this laptop from various times in the past. So this query:

+  if (!db_query("SELECT 1 FROM {system} WHERE type = 'profile' AND status = 1")->fetchField()) {

is always going to fail, as far as I can see? Shouldn't we be checking for name = variable_get('install_profile', 'standard') ?

That was the patch in #31 except we need this to run regardless of profile name, the new patch is broken then. I definitely didn't test it, looks like no-one else did either. Reminds me of #1006714: drupal_get_path doesn't work for profiles, the whole conversion of profiles to modules was half-arsed and we're still cleaning up.

If we had #1182296: Add tests for 7.0->7.x upgrade path (random test failures) we could write a proper test for this, I don't think it's possible otherwise or not without very nasty hacks in the test to reset schema version or call the function directly after manually putting the db in the inconsistent state.

Do not have motivation to re-roll this, should be easy enough if someone else does.

I'm currently able to reproduce this by just running drush updatedb (even without any database update required), on the tip of the 5.x branch of Drush. Is there an open issue about that in the Drush queue?

The only drush issue I know about is the 3.x one that was closed in September.

On a non-core profile (Commerce Kickstart) I can reproduce by simply visiting update.php.

Don't mind me, what was happening is that I removed the profile from the filesystem.

Friends. As always. TDD.

Attached patch fixes the bug for existing sites. Still failures for new sites.

Attached patch fixes all issues.

As I'm going to get a cup of sleep and don't see test results of #63 yet, extra safety patch without the install.core.inc change -- although I think that's valid.

Apparently, SimpleTest uses custom functions to install a Drupal site, for performance reasons. Which in turn means that especially the initial core installation does behave differently. Doesn't invalidate the final test assertions of this patch, but definitely the first.

Does that test actually fail without the rest of the patch?

Seems like it shouldn't, since so far no one has come up with a (reproducible) way to hit this issue by visiting update.php alone, only when using Drush. Still doesn't hurt to have the test, of course.

Fixing it in _system_rebuild_module_data() does seem reasonable if it works; it's a little silly to hardcode that because there's no legitimate way the profile ever should get disabled in the first place, but it's more robust than an update function and we already hardcode everything else about the profile in _system_rebuild_module_data() already, so why not.

@David_Rothstein: yes, #61 was a test-only patch.

I think I now understand what happens in #65: Since the profile module status is enforced in _system_rebuild_module_data() and module_enable() relies on that, hook_install() + hook_enable() are not invoked for the profile module, because... it's already enabled. :(

OK, #61 fails, but I think not in a way that reveals the actual bug (since the test results show that the 'Install profile is enabled' assertion fails both times, rather than only once). Once that problem is fixed my guess is the test will pass either way.

Hm, so regarding the issue with #65, short of a hack that only sets 'status' under certain conditions (e.g. when Drupal is not being installed), which is not so great, is there any way to get around that problem?

I'm not sure we should try to actually 'fix' this in this issue. We know that at least sites with Drush 3 are likely to hit this condition but no other steps to reproduce.

#1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles is there for any other occurrences of the bug that aren't due to drush - if we correct it for those too, we might never find those bugs (if they exist at all).

#61 fails, but I think not in a way that reveals the actual bug (since the test results show that the 'Install profile is enabled' assertion fails both times, rather than only once).

The cause for the first fail is that Simpletest uses a completely different routine to install Drupal. We should eliminate this difference: #1215104: Use the non-interactive installer in WebTestBase::setUp()

Same issue after manual upgrade (without drush)

Same. Subscribe.

Same issue after upgrading from D6 using update.php.

I used the German Drupalcenter version (available from http://www.drupalcenter.de) and the only installation profile entry in the system table after the upgrade was "profiles/drupalcenter/drupalcenter.profile" set to status "disabled" (0). After manually changing the status to "1" with phpMyAdmin the error went away.

hth
Frank

subscribing.

Unless we decide to close #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles again, let's focus this issue on the Drush case (which we know how to reproduce).

Subscribe
Got this trying to upgrade a site to D7.
It was originally installed as a Drupal 4.6 site, some time before installation profiles!

There's one more piece to this puzzle. I have a site that originally used an install profile but no longer uses it. I did a site upgrade using drush and started getting this error. I now have an entry in my system table for the non-existant install profile that is marked as disabled. Setting it to enabled fixes nothing because it doesn't exist.

The system entry is added by the upgrade process without checking to see if it actually exists, because it is still in the 'install_profile' variable. The system update set the status to active, which Drush fixed for me, but I still need to update the 'install_profile' variable to 'standard'. If I did not use Drush I think I would still have an error, the only difference is that the entry in the system table would have been marked as active.

I don't know how we can tell if the missing installation profile is intentional or by accident. If the missing installation profile is because the profile is no longer being used, we want to remove the system entry or at least mark it inactive and also reset the 'install_profile' variable. If the installation profile *is* still being used but didn't get added to the new site we want to leave the variable alone and set a message warning the user that it is missing.

I ran into this bug too. I'm hoping the following has some added value for this topic in fixing the bug:

My install was a 7.4 install (incrementally updated in time from a clean 7.0). After running the 7.7 update, I got the error mentioned in the OP (line 202 of install.inc). Found this topic, and ignored it for a bit.

Some time later, I was uninstalling a few modules and found the standard profile in the list of modules ready to be uninstalled. This triggered me to go look through install.inc and figure out what was going on.

Apparently, it first look for drupal_get_profile(). drupal_get_profile() get's its return value (in my case) from the variable install_profile (defaults to standard). Not a problem, I found the variable in my variable table and it was set to standard.

system_get_info('module', $profile), was the next line. Digging through, I found that it runs through a list of enabled modules. Somehow my standard profile got disabled (hence it showing up in the list of modules ready to be uninstalled). After manually setting the 'status' to 1 of the module 'standard' in the system table, the error is gone.

So, for me the fix was enabling the standard profile again. Somehow it got disabled. I did not delete a single drupal core folder (including the profiles folder) or muck around with any other core file. I just ftp'd the 7.7 update, and ran the update.php.

@Kiphaas7: did you use drush to riun updates? If so which version?

No, no drush.

EDIT: Stupid me. This topic is about drush. :/

I upgraded 7.2->7.7 via FTP

And got this:
Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of/path/to/site/includes/install.inc).

Also, this:
Notice: Undefined index: name in system_requirements() (line 39 of /path/to/site/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 of /path/to/site/modules/system/system.install).
http://drupal.org/node/679730

I too encountered problems that seem to be right to mention here.
Upgrading from 7.4.4 to 7.7 on Windows XP machine used for local development, so no FTP, no drush, nice and simple.

Received message:

Notice: Undefined index: name in system_requirements() (line 39 of /path/to/site/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 of /path/to/site/modules/system/system.install).

Wiped everything, did new install; no problems, then did security update, same error.
Wiped again, installed, did security update, but KEPT the "Profiles" module from the new install (did not use the one with the security package). Problem went away.

Hope this helps someone.

same here

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of /h/*******/htdocs/includes/install.inc).

I experienced the same problems as # 84, reinstalled and the errors reported by #84 were gone however I received the same error as #85 Uninstalled everything again. Reinstalled in this order: acquia-drupal-win7.4.4-5598.29386 with no errors but two security updates were required again. Upgraded Token 7.x-1.0 beta2 to 7.x-1.0-beta 3 with no errors. Upgraded Drupal Core Installed version 7.4 to version 7.7 this time with no errors the only thing different this time around was to download a fresh copy of version 7.7 zip(3.04MB) . Please Note " #84 had KEPT the "Profiles" module " I did not do this and everything worked ok regardless.

I too am using XP as a devlopment box... no drush and no FTP

@KarenS: I think that's another aspect to this that some people have run into, but hasn't been discussed yet (and definitely wasn't when install profiles were switched from run-once to required modules in D7). I opened #1242956: Allow install profiles to be switched for D8 but I'm now thinking we should backport this to Drupal 7 too.

I'm going to update the issue summary to try to summarize all of the possibilities, this is a real mess.

Created summary

After writing all that, here's my suggestion for what we do:

1. Fix the patch in #43 - just have a one off that enables the profile again.

2. Make core agnostic about whether the install profile is enabled or not, #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() is related to this.

OK here's a start on part 2 of that.

Re-titling. The more I think about this, #83 is enough to make this non-critical for Drupal 8 I think. Then we need to restore mistakenly disabled profiles in an update for D7. Then there are several outstanding bugs and tasks for cleaning up install profiles already which handle the things not covered here.

Also now there's reasonable documentation of the ways this can occur this feels more major than critical.

At the moment the only problem is the error message. The underlying problem is that the system thinks you need a profile that doesn't exist or isn't enabled and somewhere down the road that might lead to other problems. We need to either make sure the profile is available and enabled or reset the system so that it knows there is no profile.

See #20. There are definitely consequences if your profile implements Drupal hooks that are supposed to run during normal site operation.

If it doesn't (e.g., the core install profiles) I'm not sure if there are actually any other noticeable side effects.

Right. New Drupal 7 profiles can implement hooks etc. and if the profile is disabled those won't run, same as any other module. If you have a highly customized distribution then this could break it. However all install profiles in Drupal 6, and likely many Drupal 7 ones are just supposed to run once and that's it - so it doesn't really make any difference if they're enabled or not, just the current code always assumes they are - there might be some other side-effects similar to these notices maybe, for example where install profiles are special cased elsewhere, but not aware of specifics.

JFTR
The German language version available from http://www.drupalcenter.de (which supposedly most German users will use) comes with its own installation profile which besides the translation contains a module for a block.

Hey. I did the *exact* same thing when updating a Commerce dev machine to D7.7 (manually). Completely forgot that we started with Commerce Kickstart. Were you able to fix this somehow?

subscribe

Adding 'quick fix' tag for issues where the patch is quite straightforward. This issue has a long history but the fix is simple.

I marked #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() as duplicate. It was the older issue but this has a lot more background on the various causes at this point, and the fixes have to touch exactly the same lines of code.

I still got the same error messages as #84 after upgrading from 7.7 to 7.8. Applying the patch from #89 got rid of the error messages, but not of the installation profile entry in the system table in the database which still points to "profiles/drupalcenter/drupalcenter.profile" (see #96 which is long gone from the installation.

@Frank. Yeah the patch does not attempt to clean up the system table because profiles can be both intentionally and unintentionally missing. Sounds like it works for you. Would be good to get more reviews here.

subscribe

Sorry, I now get the same error message as #85 (the first part of #83 while the second part of #83 disappeared after applying the patch).

Catch told me its ready to RTBC, therefor marking it RTBC. Having "no profile" should be totally possible and not throw errors.

#89: profiles.patch queued for re-testing.

Re-rolled, if this patch doesn't apply to D7 then the one from #89 should since it was just stuff added to system.test wot broke it.

Assigning to webchick - this is my patch so I can't commit it and it needs backport so makes sense for webchick to sign off.

Re-uploading #89 for 7.x/testbot.

Just had a LONG discussion about this in #drupal-contribute.

At first I was very opposed to this patch because it's merely sweeping details under the rug instead of actually fixing anything. Then catch explained that it's not really possible to fix it, because once this value is missing (regardless of which way it happens), there's no way of rebuilding the information on what it used to be.

The patch as outlined in #108 addresses the notice on the status page by hiding the block about the installation profile on the status page if it can't find one. However, now that installation profiles are modules in D7, it's reasonable for a distribution author to assume that they can put hooks in there that should execute at run-time, and that they can put updates in the .install files and those will run. That's, after all, why we made the change in the first place. #509398: Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x)

If the status message is gone entirely, a distribution author has very limited ways of troubleshooting why some of their users are getting DB updates and others are not. It involves asking users to dig around in the DB and check for a variable value and all sorts of other nonsense.

So. What I think we should do instead of hiding the message entirely is display the profile name as "Unknown." Then this could be an easy troubleshooting step for distribution authors to ask their users to take in this situation, and we're not "faking" them with some other profile (e.g. minimal) that isn't actually correct.

Also, since this is just about a notice fix, this is no longer 'major'. Additionally, since the actual fix should be pretty straight-forward re-roll/adjustment of #108, I'm tagging as Novice.

Ahem.

Updated issue summary.

Is it intentional that #108 removes the version string from the info printed on the requirements page?

Based on #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() (which was marked duplicate of this issue) we need to do something about that, since we can't assume all profiles have version info actually defined. However, if it is defined, I would think we should print it. (It goes along with the idea that this is a troubleshooting tool for distribution maintainers, who might need to know what version of the install profile a particular site is running off of.)

This is a fix for a notice that will appear on every page of your site on every page load that provides no clue about how to make it go away. That's a bit more major than a one-time notice.

[Edit] Er, I guess it is not actually on every page on your site. I take that back.

Subscribing

subscribe

subcsribe

people stop subscribing and start following already! see top of all issue queues for the follow button. 1<3

My only concern with displaying 'Uknown' is that it's annoying to still have to see this error message on all admin pages forever until one fakes an installation profile. Is there a way to simply set it to 'standard' in the case of no other profile during an upgrade?

I was trying to figure out how to fix the problem on an installation that already has it, since we need some sort of update hook for those situations (we can't ask someone with a functional, ported site to start over again).

Here are the things that end up broken and how to fix them:

1 - There should be a .profile module in the system table. It should either be standard.profile if you aren't going to use a profile or MYPROFILE.profile if you used a custom installation profile. And the .profile's status should be set to '1'. I have seen two problems, depending on the original source problem. Either the right profile is there and it's status is not set to '1', or the expected profile is missing and the wrong one is there. If you have MYPROFILE.profile and you wanted to be using the standard profile you need to create the standard.profile (or change the values in the one you have) and mark it active.

2 - There is a variable called 'install_profile'. It should be set to 'standard' if you don't want to be using an install profile or the name of the profile you want to use. The value should match the .profile that you set to active.

I have two installations that broke for different reasons. One (a drush site-install that used the standard profile) had the right variable and the right profile and just needed it to be set to active. The other (an upgrade from a site that originally used an install profile that has no D7 version) had the wrong variable and was missing the right profile (had a profile for the non-existant custom install profile). In that case I needed to change the variable and create the standard.profile and set it active. After doing that and clearing the caches both sites seem to be working fine with no error messages.

Getting this into an update hook requires some knowledge about what was intended. I have no idea how to do that.

Hi KarenS. Thanks for the very detailed response. I think the last paragraph says it all: requiring information about what was intended.

I saw in another thread how someone simply used drush on the command line to re enable the standard profile... thus adding it to the tables. The problem with this approach is that enabling the profile this way caused the system to try and recreate various input formats, default theme options, etc.

I was thinking of a way to hack it by simply commenting out the entire profile and then enabling that from the command line... then uncommenting after. Not very elegant!

Perhaps the best solution: a 'placeholder' or 'dummy' profile. This was, someone could enable it through a hook update, but it wouldn't actually install a blessed thing. That way the system is happy because there is SOMETHING technically set as a profile, but it doesn't do anything besides act as a placeholder.

Considering the quantity of D6 to D7 upgrades on the horizon, this seems like it would help a lot.

Thoughts?

I just did a

drush vset distribution_name my_value

on a D7 fresh install with own profile which made the pain go away.

I already chimed in on this issue, so I don't believe it's blocked on me anymore. Unassigning.

#110: profiles.patch queued for re-testing.

Subscribing

Having same issue. Used Acquia Drupal 6 for college website and we're looking into an upgrade path to D7. Tried the upgrade on a development server and seeing the Undefined index errors for name and version. I used Acquia D7 with the profiles folder there. Would rather not hack core to fix this, but it's throwing a lot of errors and preventing a clean upgrade path, which hinders our ability to move forward with a few projects we have in mind for the site.

Can confim that KarenS fix (#121) got rid of the notice,

"Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() "

on my install, with a custom installation profile.

1. Set the custom install profile (profiles/custom/custom.profile) status to 1 in the system table.
2. Added install_profile variable 'custom', with drush (drush vset install_profile custom)

#121 and #128 fixed it for me. Thanks

Changed the value of profiles/standard/standard.profile in the Systems table to 1

"Changed the value of profiles/standard/standard.profile in the Systems table to 1"

Same worked for me.

Yep thanks a lot !
"Changed the value of profiles/standard/standard.profile in the Systems table to 1"

Same worked for me.

Well if it's truly a matter of toggling a 0 to a 1, would a simple hook_update fix this issue entirely so we can close it out? I know there are some additional considerations in #121 and before... are there any hidden gotchas for this toggle?

Yeah the problem is the actual install profile may not even be in the install any more, for example on a site upgraded from 6.x. You can't enable a profile that doesn't exist.

I would suggest creating a 'dummy' profile which was nothing more than a .info and a .module file and then assign it to that... because then it handles the error but doesn't fake the system into thinking the styles/preferences of standard or minimal are being used, etc.

Well if it's truly a matter of toggling a 0 to a 1, would a simple hook_update fix this issue entirely so we can close it out?

It's not that simple. That is the right fix for one permutation of the problem, but there are other permutations that won't cover.

I would suggest creating a 'dummy' profile which was nothing more than a .info and a .module file and then assign it to that... because then it handles the error but doesn't fake the system into thinking the styles/preferences of standard or minimal are being used, etc.

I don't see how that is any better than just setting it to use the standard profile. You've left the system in an unsupported state that indicates it is using a non-existant profile and not even a warning any more. What would then happen when they upgrade to D8?

There is no 'harm' in leaving the system set up to use the standard profile if it can't find any other profile to use. The system will work fine. What would be lost is any connection to a custom profile going forward.

So I propose that the upgrade path does the following, and that we add an update hook to double check this on systems that have already upgraded:

1) Check the value of the variable. If the variable says there should be a custom profile, see if there is actually a profile that matches it in the codebase. If the profile exists, make sure the system table entry has been created and is enabled.

2) If the variable says there should be a custom profile but there is no custom profile in the codebase, alter the variable to use the default profile. See if the standard profile exists in the system table. If it does, enable it. If it doesn't, create it. Create a new variable for the lost installation profile and set that to the original value. That would provide something that could be used later by custom code or a contrib module to go back and reset the profile to the right value again.

3) If the variable indicates that the default variable should be used, make sure the default profile exists and is enabled.

The above process would fix every one of the possible problems except one. The only thing that would not be fixed correctly is if the system should be using a custom profile and it still couldn't find that profile anywhere in the codebase. I don't think there is any automatic way to fix that problem, so we have to be sure everyone understands that any custom profile must exist in the system when you do the original upgrade (or before you run this update code). If we add a variable that contains a missing profile that got reset, it should be possible for someone to create a contrib module or custom code to reset those values later, as a final fallback.

Also, I'm not sure this is a quick fix or a novice issue. There is some complexity here.

After diving into the profile of open atrium, I rescind my suggestion of just the dummy (or minimal or standard) profile in #134. KarenS suggestions in #135 makes sense. Further explanation

standard.install basically does the following:

Defines default modules to install (in the .info file)
Creates text inputs (filtered, full html)
Sets default theme (bartik)
Sets initial Block configuration (navigation, etc)
Creates initial content Types (page, article)
sets default variables (node submissions, etc)
taxonomy (tags)
default fields (image, etc)
permissions and Roles

It's quite possible for a site to have none of these defaults left unchanged by the time the site launches (least likely to be removed is the input formats.. but even then). In that case, would it be smart for other modules to depend on these values knowing that they are not fixed in code but rather initiated once and then left to change by the user?

In the case of custom, you're completely right... especially if there are non-configuration functions (see open atrium as an example). So the checks listed would be totally valid.

In short:
1) If the installation came from minimal or standard, just toggle on minimal because there is no custom code beyond configurations in either...
2) If the installation came from a custom profile, use the custom profile if still available.
3) If installation came from custom profile that doesn't exist anymore, then send a system warning stating that they need to download/add this profile back in.

These are similar suggestions to KarenS' in #135... but it didn't click for me the first time around... so I thought I'd share.

I also agree that this is not necessarily quick/novice!

#43 is ready to be committed. It is a D6-to-D7 upgrade fix (to a problem that is not Drush-specific, attested to by myself and other commenters).

It only does anything if there is not already an enabled profile and if there is a profile that matches what is in the site profile variable.

This is a bug in the D6 to D7 upgrade path that this fixes, and so a D7-only problem. Once it is committed, the much rarer issue shared in D7 and D8 of insufficient feedback should there be no valid enabled profile can be taken care of. (Or alternatively allow sites to not have any profile enabled. Point is those are changes unrelated to fixing the bug in the D6 to D7 upgrade path.)

#43 does not fix all the problems noted, and #56 indicates that the patch in #43 is broken and not tested. I see no comments that indicate #43 is 'reviewed and tested'. I tend to agree that fixing the upgrade path in D7 is something that needs to be fixed separately from any D8 issues, but that is not the usual order of things.

#108: install_profiles.patch queued for re-testing.

I tested #43 (on multiple sites that had this undefined index notice, upgrades with Drush, without Drush, and most recently on a Gardens exported site) and the fix was also confirmed in #51 by msonnabaum and #52 by BTMash.

I got the same notice when installing the Minimal profile of a fresh checkout of D8.

The attached patch fixes the problem for me; ymmv.

Fixed typo modules_list() --> module_list()

Note that writing a test for this is blocked by #279515: setting an installation profile for a test doesn't run hook_install_tasks()

EDIT: Apparently not, according to sun's comment.

Will try to write a test.

Wrote a test, but it passes, even though it's doing (afaict) the same thing I do to reproduce the bug manually.

Help, anyone?

Moved test to core/modules/simpletest/tests/minimal_profile.test as per catch on irc.

Truncating the {cache_bootstrap} table makes the error go away.

Steps to reproduce:

1. Install Drupal 8 with Minimal profile

2. Immediately visit the admin/modules page. Note the following error:

   Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 106 of /var/www/core/includes/install.inc).

3. Refresh the page. Note that the error persists.

4. Truncate the {cache_bootstrap} table, e.g. by running mysql d8 -e 'delete from cache_bootstrap' from the command line.

5. Refresh the page. Note that the error goes away.

@pillarsdotnet, Looking through DrupalWebTestCase, setup() calls on $this->resetAll() which flushes out the cache. So its doing the same as your truncating the cache_bootstrap table and thus the error doesn't come up.

I can kinda see why it is doing what it is but its not helpful in our scenario :( The other way I see to do this is to basically replicate what is there setup() but that seems like a poor way to approach this issue. The other option I see is to do what we're attempting in #1364798: Impossible to generate meaningful diffs of upgrade db dumps where we install version X of drupal in a subdirectory using the webrunner which would give us better control on what is going on.

Ok, seems like resetcache might not be the culprit. But I do see variable_set also occurring and since that also clears out the cache bootstrap, I'm wondering if that is the other area this might be coming in from.

It is not clear why or how the distribution_name error is related to this issue. I concur with it perhaps being a related symptom, but that is not guaranteed. The recently submitted tests and code changes only attempt to workaround that symptom, but do not attack the actual cause.

To fix this issue, we need clear steps to reproduce how the installation profile can get disabled without intention, so we can re-implement those steps in an automated test. -- if there actually are any ways unrelated to Drush to trigger this issue.

As outlined in #135, nothing will be able to fix existing broken sites where this issue occurs, as we're unable to restore the original install profile name in case it got lost.

Help, what should I do? I am trying to following this thread but am lost. I was directed here from other posts. I get the starting message when trying to add a calendar module to my hosted version of my site.

Here is my set up. D7.12 works fine on my local computer which uses Acquia Desktop control panel. Works great, love it!

But once I uploaded the site to my client's host, I get the above message when trying to add the calendar module and can not upload the new module.

In trying to understand these posts, I looked in the mySQL database and found both entries in the System table: modules/profile/profile.module and profiles/standard/standard.profile. And of course find both in my file directory. From here, I am lost. What can a designer/builder (not developer) do to solve this problem?

Thanks in advanced.

add to post #153. I changed the Status value from ) to 1 for filename profiles/standard/standard.profile in mySQL. The message did not display first thing when accessing module page but still crashes when trying to add module.

Apparently the fact that a normal installation with Minimal profile throws a user-visible PHP warning is not a bug?

Well, for a "novice" issue this has turned into quite a time-consuming headache for me. My problems started when I was assigned to update Drupal core and contrib modules for a website that was originally built a year ago using Pantheon for hosting. Since then, Pantheon has made some changes to its hosting setup. A year ago, they were putting an extra installation profile named "pantheon" inside the profiles directory. That installation profile contained a function named pantheon_install().

Subsequently, Pantheon has deprecated the installation and replaced it with a module named "pantheon." When we migrated to their new hosting setup, they applied a patch which created the new pantheon module inside the sites directory. However, their patch did not remove the old profile. This meant that when I ran update.php, I was getting a fatal error because there were now two functions named pantheon_install(). (One was in the Pantheon profile. The other was in the Pantheon module.)

"Well," says I, "I'll just delete the Pantheon profile, and all will be well." The folks at Pantheon agreed that this was the way to go. As soon as I did that, however, I started seeing other problems on the modules update page, including the "Undefined index: distribution_name" notice. My website also began failing when I attempted to check for new module updates at http://mysite/admin/reports/updates/check. Moreover, I realized that was unable to see the pantheon module listed when I went to admin/modules/update. Presumably this is because D7 regards it as a "required core" module and therefore hides it.

I was able to get rid of the "Undefined index: distribution_name" notice by restoring the deprecated Pantheon profile and simply commenting out the duplicate pantheon_install() function so that I could run update.php without getting a fatal error. However, I still can't see the pantheon module from admin/modules/update, so I can't disable or enable it there.

I got a similar error and reading through this node as a designer, I am a bit lost in what I should do...
I upgraded from version 7.12 to version 7.14 and now I get the following error:

Notice: Undefined index: name in system_requirements() (line 39 af /var/www/domaine/www/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 af /var/www/domaine/www/modules/system/system.install).

I hope someone will be able to point me to a solution that I understand.
Thank you.

As with #157 I have started getting this issue upgrading from 7.12 to 7.14. I have roled back and tried going to 7.13 and still get the issue. Again the error is lines 39 and 41.

Any help would be appreciated.

Fixed my issue! I was using a commerce_kickstart build and had not copied the commerce_kickstart folder to the new profiles folder (copied from the core upgrade). Once done I no longer get the error described in #157 and #158. Unfortunately, I think you need this folder in place before you run the update.php otherwise it didn't appear to cure the problem.

I'm also getting

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of .../drupal-7/includes/install.inc)

after upgrading 5-> 6 -> 7.12 -> 7.14

I have experienced the same issue - Upgrade from 6.x to 7.x -

Is there any conclusive fix for this? It appears there are many
suggestions however nothing seems to be final.

If you need a fix for a current D7 site before this patch gets worked out, see my comment at http://drupal.org/node/1170362#comment-5218718. Those things also need to go into some sort of update hook in any fix.

Just wanted to post my experience in case it helps others.

I had this issue after upgrading a commerce-kickstart install from 7.12 > 7.14

Running drush vset install_profile standard solves the issue for me.

@BrendanP: #163
My install profile is also set to "default" instead of "standard".
I am trying to change the variable value, but with no effect. It says it is changing the variable value, but then it still has the old value. Duh.

---------

@others:
I understand we want to solve the structural issue here, not just fight symptoms.
BUT, most people on Drupal 7 having this problem just see the two annoying and confusing error message fired in system_requirements(). Maybe no further effects whatsoever.
Notice: Undefined index: name in system_requirements()
Notice: Undefined index: version in system_requirements()

I would strongly suggest that we produce a "low-hanging-fruit" D7 patch, that simply turns the confusing error message into a more useful one. Instead of "undefined index" it should say sth like

Your install profile is set to 'default' (or whatever), but there is no module with this name. The developers of Drupal core are trying to find out why this happens, and will hopefully fix this in a future Drupal release. More information on ... (link)

This message can be shown in the status report, and can be ignored on any other pages.

@donquixote: I agree, let´s make drupal speak like HAL 9000. Maybe it´s worth one whole major version...
But to be serious: messages could in fact be more friendly sometimes.

Duh, why do I know nothing about HAL 9000. Yes, i can google it :)

The point is, currently we do not show a message, we let php do it. And this is wrong.
If we already know that something could break, then we should define the damage behavior, not let PHP do it.

Whether we openly admit in the product that this is a bug in core, and how we phrase that, is a different question. At least this would be honest, and not leave the user in a position of "what did I do wrong".

(side note) Similarly, we could report other inconsistencies, such as, "the active theme is disabled", or "the active theme does not exist", or "the following enabled modules do not exist" etc, that may be triggered by bugs in Drupal core, broken upgrade path, or just by checking out a different git branch. (/side note)

I like donquixote's suggestion. I don't care about the exact wording, but an explanatory message from Drupal certainly would have helped save me some time when I ran into this, as I noted in comment #156.

Re-rolled for Drupal 7. No test's in this patch though.

Commerce_kickstart looks to be my problem too. I actually thought it might not be needed (after the initial install) and so didn't upload (via source control) when I updated core from 7.12 to 7.14. I then tried editing the db table for status 0/1 and another trick suggested elsewhere. Both failed.

I've now re-uploaded the commerce_kickstart profile folders and re-run update.php but I'm still getting:

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of /home/peachydev/xxx.xxx.com/includes/install.inc).

Will have to come back to this later as I'm now spent way too much time on it.

@donquixote after all this, is it safe to say we can actually just ignore this message and that no harm is being done?

Thanks.

Q

@quantos pls. try patch #168

thanks @steinmb, looks like I need to read of installing patching next then. Makes designers like me very nervous. :)

and "oh dear" @earnie. That doesn't sound good.

Q

Patching is safe and if things don't work just roll it back :)

I had this problem. After much (!) reading, I have come to the conclusion that the source of the problem was that I did a localhost install of D7 using Acquia. I then updated to 7.14, but not through Acquia. My speculation is that the install profiles got messed up in that process. At any rate, I applied patch #168, and got this:

File to patch: /Users/cecrs/Sites/acquia-drupal/includes/install.inc
patching file /Users/cecrs/Sites/acquia-drupal/includes/install.inc
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file /Users/cecrs/Sites/acquia-drupal/includes/install.inc.rej

However, it worked! No more error on the modules page. I went and looked at install.inc.rej, but I'm too much of a noob for it to have had any meaning. ;) For what it's worth, I have attached install.inc.rej...
:)
-cecrs

Update:
The error on the modules page was fixed, but I was still getting the line 39/41 errors on the administration page. I did some more digging around, and found http://drupal.org/node/1186196. I added the acquia profile folder to the updated profiles folder, changed the value in the system table from 0 to 1 (for the acquia profile), and the problem was totally fixed.

Out of pure curiosity, I reverted to the original, unpatched install.inc file and ran update.php. No errors.

:)

Patch in #158 applied cleanly to drupal-7.15 without offsets and solved my issue: no more annoying messages. TL;DR about the root of the problem, though, so not touching the issue status.

For the record, I was experiencing the "Undefined index: distribution_name" error, and eventually I ran drush rr and noticed this in the output:

$ drush rr
Manually deleted 1 stale file from the registry.                                                               [success]
A file has been declared in a module's .info, but could not be found. This is probably indicative of a bug. The missing file is profiles/dbcreate/dbcreate.profile.                                                                            [warning]
The registry has been rebuilt.                                                                                 [success]

'all' cache was cleared

By now, seems that the error went away.

You ment patch in #168, and yes it also solved the issue for me :)

This path fails on Version 7.17. Could you please make an updated Version of this patch that will work on Version 7.17

@oerjann - Yup; just as soon as the 8.x version gets fixed and applied.

I have installed to install profiles picked up from features
I am getting the menu rebuild error. runnin update.php,gives a PDO.
when we have such instances there will be some code clashes in system, and install
what will be better is a
1.standard default
2. order of priority i.e which profile is 'master' and which is slave.
3. the one initially selected while installing should act as master and other as salve,
then the dependencies priority should prevail in that order.in the even of uninstalling the master then the slave should prevail.

in the event of uninstalling both then a fall back to standard should happen

Reroll of steinmb's Drupal 7 patch in #168. This patch will apply to 7.17.

Ok, so will this patch work? What about the method in post #8 which changes the status of the profile in the database? I tried that and it reverted back to 0.

#108: install_profiles.patch queued for re-testing.

Trying to update Commerce_2.0-rc4 to 2.0 with drush or via Web, getting the error in drush: "The commerce_kickstart directory could not be found within the modules directory [..../path/to/]/profiles/commerce_kickstart, perhaps the project is enabled but has been deleted from disk"; and "Downloading updates failed: commerce_kickstart-7.x-2.0-core.tar.gz does not contain any .info files." from Web update/

drush up lists: [Commerce Kickstart 7.x-2.0-rc4 7.x-2.0 Update available]. Can't find any profile listing in the system table in the database. Everything else is up to date. Is the only solution to copy across all the latest modules from profiles/commerce_kickstart/modules/commerce_kickstart directory from a fresh download?

#181 also work for version 7.18

I recently upgraded from an acquia 7.16 local install to 7.18 using the drupal.org download and encountered the same line 39/41 issued noted in comment #157. After reading through the responses, I (a very green drupal novice) opened my database, opened the system table, found the only entry that ended in .profile, and changed the number in the status field from 0 to 1. I restarted the drupal stack, reopened my local site, and the error messages were gone.

Is there anything else that I need to do to see if this solved the problem or created additional problems that will plague me later?

Same here. I got done upgrading from 7.18 to 7.19 and got the same errors. I found the profile entry in the systems table, set the status to 1, cleared cache, and the errors are gone.

In reply to #189: carefully though. I carelessly followed your advice and my site got PDO'ed and things looked quite sinister with notices like "Additional uncaught exception thrown while handling exception". Could get it all back by running update.php luckily enough.

But your advice does work though. You only have to make sure you apply it to the right record. In my case there are two profile records in the system table:

• The default one (modules/profile/profile.module)
• The one that my theme uses (profiles/MYPROFILE/MYPROFILE.profile)

The status that had to be changed according to your instructions (and those of KarenS in #121) is the one of the profile you're using (the second one in my case).

Ading a blurb at the top for novices.

add work-around to lessen the number of "me too!" comments.

Just FYI for anyone who might be helped by this module - I made the mistake of removing an installation profile and was getting the error message. This Profile Switcher module allowed me to switch to the standard install profile and fixed the error:

https://drupal.org/project/profile_switcher

Another FYI on this: I just wrote a blog post on how to go from an install profile to vanilla drupal. It's a bit more fleshed out than the one liner workaround above... includes moving all the code out of the profile, updating module/library locations, and using drush to update the saved install profile.

It's a good place to start if you're trying to get out of a relatively simple install profile... I'm working on a followup post for a complex use case (Commons).

Thank you to #190 and all the previous replies it builds off.

I had two entries in the (profiles/MYPROFILE/MYPROFILE.profile) section and wasn't sure which I should change.

So just as a quick FYI the profile your site is using is listed at the top of the page under Admin>>Reports>>Status Report

(admin/reports/status)

I made the change and touch wood this error has gone away. I was getting mighty fed up of manually hacking the .inc files after every update!

+1 for #191 and profile_switcher module.

it was pretty simple...

1) enable module
2) configure > switch to standard
3) disable and uninstall

ps - just make sure if you have custom profile, to move any 'modules' from within the profile folder to /sites/all/modules
that way you can just dump the custom profile for good and just use drupal standard script.

warning: some modules dont play well when you switch folder location so make sure you take backups :) in general if you move location and flush cache the modules path should refresh and work.

+1 for #194. Switching from to Minimal then back to standard solved the issue for me!

After upgrading from D6 to D7, the profile entry in the system table was totally missing. Following suggestion in #191 and #194 I installed profile_switcher that told me it was set to standard. I switched to minimal and from then on the PHP Notice disappeared.

I got the same error after upgrading from d6 to d7. I had no profile available inside my new d7 installation that fit, except for "minimal", "standard" and "testing". The one that drupal demanded was "drupalcenter". #191 (profile switcher) did it for me. The warning messages went away.

This is the easy fix that I have found to work:
https://www.drupal.org/node/1170360

Insert: if ( ! array_key_exists('distribution_name', $info)) $info['distribution_name'] = 'Drupal';
BEFORE the existing line that says: return $info['distribution_name'];

Normally between 202 and 207
~cheers!

https://www.drupal.org/project/profile_switcher can now fix this as well on D7 sites.

Ran into this after a D6 Acquia site update to D7. Profile Switcher fixed this by easily allowing me to change from Acquia to Standard profile.

looks that does not affect migrations

Per the notes in the issue summary and webchick's guidance in #112, here's a patch that applies to the latest D8 release candidate. This issue hasn't seen much love recently and there's been some effort to focus on the D7 patch instead, but this needs a definitive fix in 8.x before a backport, I think.

Well, I tried adding the patch, however, now I am getting a new error:

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name()

Just in case someone else need this - attached is my backport to 7.43 of patch by @bradjones1, comment #204. I am using this approach in a project for a while.

dpovshed's backport patch for Core 7.43 works and eliminates my error! Thanks!

Support still needed: I don't know if I messed something up (and it would be great if someone could please verify), but this issue only started upon upgrading from Core v7.27 to v7.43. After copying the core files, I ran update.php and it gave me errors saying my profile modules were missing. So I proceeded to move my profile folder's modules to the regular sites/all/modules folder, (which rid update.php of the missing module errors) and then I decided to delete my profile folder altogether if Drupal isn't going to recognize my profile anymore. This error came after completing this 7.43 upgrade. My database system table had the profile "status" field set to 0; I tried changing it to 1 but it did not work. Then I tried deleting that profile row to try and delete the profile. Nothing has changed and I don't know why Drupal continues to say I have this fictional ("Version Unknown") install profile enabled. Will it cause any issues on future Core updates? The only place in the database the profile name still exists is in BLOB format in the "cache_bootstrap" and "variable" tables.

Should I continue to try and remove the profile or is that stupid?
More importantly, is there a way to just switch it back to Standard?

I just don't want there to be any future issues about this on Core updates. If someone can verify, I would really appreciate it! :)

@ownage, this isn't the best place to get support for an individual site, but if the old value is still in the variable table then presumably the system is still configured to use the old profile. Try setting that variable to the standard install profile (drush vset install_profile standard, using Drush) which should fix it. You could clear caches afterwards to make sure the old value is totally gone.

And yes, after doing the above it might also be necessary to mess with the rows in the system table to make sure the "standard" profile is there (and enabled/installed) and the old profile is gone. Definitely make backups before doing any of this :)

Karen's fix at #121 worked for me. In database, find System table, find standard.profile, set status to "1"

This is an update script for D7 that makes sure there's an installation profile configured, and then enables it. Food for thought.

Patch #204 by @bradjones1 works perfectly for me

patch 212 not working: it duplicate the 7081 update function (which is bad)
Here is the result after applying it:

/**
 * Ensure there's a installation profile configured and enabled.
 */
function system_update_7081() {
  $profile = variable_get('install_profile');

  // If there is no installation profile available, select the 'standard' one.
  if (empty($profile)) {
    $profile = 'standard';
    variable_set('install_profile', $profile);
    drupal_set_message(t('No installation profile was configured, so the "standard" one has been selected.'));
  }

  // Force the installation profile to be enabled.
  db_update('system')
    ->fields(array(
      'status' => 1,
    ))
    ->condition('name', $profile)
    ->execute();
}

/**
 * Ensure there's a installation profile configured and enabled.
 */
function system_update_7081() {
  $profile = variable_get('install_profile');

  // If there is no installation profile available, select the 'standard' one.
  if (empty($profile)) {
    $profile = 'standard';
    variable_set('install_profile', $profile);
    drupal_set_message(t('No installation profile was configured, so the "standard" one has been selected.'));
  }

  // Force the installation profile to be enabled.
  db_update('system')
    ->fields(array(
      'status' => 1,
    ))
    ->condition('name', $profile)
    ->execute();
}

@DuneBL it looks like you applied the patch twice. the patch util can't always see it's already applied.

But still the name system_update_7081 was introduced in #2762241: Missing default.profile from the file system so here's an updated patch to rename it to system_update_7082

Patch #204 by @bradjones1 also worked for me.

The patch in #204 still applies cleanly for 8.2.x, and it resolved the

Notice: Undefined index: name in system_requirements()
Notice: Undefined index: version in system_requirements()

messages I was seeing for an 8.2.3 project.

Updated patch against 8.2.x HEAD attached - also fixes the code style issues in this array (missing trailing commas).

I hit this with the Acquia Lightning distribution: #2839593: Undefined index: name and version on Status report.