Hi,
the Installer of D7,actual HEAD fails after entering the DB and the DB login with
Warning: fopen(/var/www/d7test/drupal/sites/default/default.settings.php) [function.fopen]: failed to open stream: No such file or directory in /var/www/d7test/drupal/includes/install.inc on line 345
Warning: Cannot modify header information - headers already sent by (output started at /var/www/d7test/drupal/includes/install.inc:345) in /var/www/d7test/drupal/includes/install.inc on line 802
Warning: Cannot modify header information - headers already sent by (output started at /var/www/d7test/drupal/includes/install.inc:345) in /var/www/d7test/drupal/includes/install.inc on line 803
it's possible to workaround this by the attached patch, but i've no idea if this doesn't break other stuff like multisites...
Comment | File | Size | Author |
---|---|---|---|
#101 | default-settings-312144-101.d6.patch | 3.83 KB | arhak |
#88 | default-settings-312144-88.patch | 2.98 KB | tstoeckler |
#86 | default-settings-312144-86.patch | 2.98 KB | David_Rothstein |
#82 | drupal-312144-81.patch | 2.55 KB | EvanDonovan |
#78 | drupal-312144-78.patch | 2.72 KB | EvanDonovan |
Comments
Comment #1
Dave ReidThat's weird. What files do you have listed in the sites folder of your drupal install?
Comment #2
CorniI CreditAttribution: CorniI commentedI talked to dave on irc about this, and we came to the conclusion that the installer needs default.settings.php and settings.php, I renamed the default.settings.php to settings.php instead of copying it...
The new bug is now that the installer needs to issue an Error of default.settings.php doesn't exist. I'll try to come up with a patch for this tomorrow.
Comment #3
Dave ReidFixed title spelling error. Once you get your patch written, I'll help test!
Comment #4
CorniI CreditAttribution: CorniI commentedI've a patch present but it needs #312677: drupal_verify_install_file sometimes issues a php warning resolved first, so I'm marking this as postponed. Also this is not critical anymore (the installer doesn't fail always), so I'm marking this as normal.
Comment #5
CorniI CreditAttribution: CorniI commentedAs #312677: drupal_verify_install_file sometimes issues a php warning should get in soon, I'm pposting my patch for review here. The warning when default.settings.php is fixed after applying my patch from the other issue.
Comment #6
earnie@drupal.org CreditAttribution: earnie@drupal.org commentedThe error message should mention the fact default.settings.php needs to match the one that is delivered with Drupal. One that exists and is empty or a modified settings.php is of no value.
Comment #7
CorniI CreditAttribution: CorniI commentedThis reroll fixes some whitespace issues of my code and adds a md5-check of default.settings.php with an extra message. This needs to be updated every time default.settings.php changes...
Comment #8
CorniI CreditAttribution: CorniI commentedno comment -.-
Comment #9
XanoBoth the default Drupal message about a missing settings.php as the new settings.default.php are talking about permissions, but only the first message actually provides a link to a handbook page about settings those permissions. I would use this link as a separate message that is being displayed if either settings.php or settings.default.php are missing.
I also think the original message could then be made smaller. Before:
More details about installing Drupal are available in INSTALL.txt.
After:
$file would be 'settings.php' or 'settings.default.php' or a combination of the two, depending on which of them cannot be read/found.
Comment #10
CorniI CreditAttribution: CorniI commentedI talked to catch, and we decided to move the md5 thing in another patch. Also, I removed the is readbale by the webserver, cause when the webserver can't read that file (and not fix it!), all is borked anyway. this is hopefully the final patch ;)
Comment #11
catchI reviewed this in irc with Cornil, and tested manually. This last patch looks great to me.
Quick summary of the issue:
If you do $ mv default.settings.php settings.php drupal's installer simply fails with nasty warnings.
This patch ensures that the file exists in update_check_requirements() and allows you to install.
It's got a couple of interesting side-effects which we should deal with in the md5 followup patch.
So, if I do
- the error message goes away and everything proceeds as normal.
If I do
The error message goes away and I can install Drupal, but I get a settings.php with just the database connection information. That's what the md5 patch will attempt to deal with, I don't think we should concern ourselves about it here - since we're only helping people who aren't really following the instructions here anyway.
Comment #12
XanoI wouldn't think so lightly about this. The installation is part of the first impression new users get. If this fails the first impression won't be good, no matter whose fault it is.
Comment #13
catchWell, the patch stops the installer from failing in this particular edge case. A side effect is that it also stops it from failing in sub-set of that edge case where we might not want it to - which is what the md5 of default.settings.php attempts to deal with. However, adding the md5 is a lot of extra work, and work that's easy to forget we need to do, every time we want to edit default.settings.php - so it seems sensible to break the patches up.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedBut
'Please make sure that %default-file exists.'
needs to read'Please ensure that %default-file is not modified in any way from the orginal download.'
regardless.Comment #15
CorniI CreditAttribution: CorniI commentedhere you go, I merged both sentences ;)
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #17
dropcube CreditAttribution: dropcube commentedThis patch no longer applies after #281446: Add 'status report' for installer requirements
Comment #18
keith.smith CreditAttribution: keith.smith commentedAlso, the patch in #15 uses "orginal" rather than "original".
Comment #19
CorniI CreditAttribution: CorniI commentedi'll have a look at it soon, thanks for the report :)
Comment #20
CorniI CreditAttribution: CorniI commentedPatch completly redone in a way like the stuff from #281446: Add 'status report' for installer requirements
Comment #21
dropcube CreditAttribution: dropcube commentedDidn't worked for me. I renamed the file default.settings.php but did not get the requirements error. The problem was that the check was included in a condition, and only executed if a settings.php exists. The attached patch based on #20 fixes it.
Comment #22
CorniI CreditAttribution: CorniI commentedWould you mind exactly describing your problem? The check is executed in the conditional is sies/default directory exists, nothing else.
If you don't get the warning, please describe exactly what you did. In my opinion, still #20 should be valid
Comment #23
Anonymous (not verified) CreditAttribution: Anonymous commentedI agree with @dropcube but if we move the $default_exists to just before the if why not just use the result of drupal_verify_install_file directly in the if condition? There is no use of the variable any further.
Change
To
Comment #24
dropcube CreditAttribution: dropcube commented@CorniI: The first time I reviewed the patch I tested but didn't get the error report. Now I see that the check is executed in the conditional is sites/default directory exists.
Attached a new patch based on #20, adding some comments and cleaning up.
Comment #25
dropcube CreditAttribution: dropcube commentedOops, there was a slash missing.
Comment #26
XanoDon't have enough time to test this patch thoroughly since I'm working on another patch, but I though I'd mention that with a fresh checkout I get both the "The settings file does not exist." and "The settings file is not writable." errors. I think the latter shouldn't be shown if the former is.
Comment #27
catch@Xano, that was introduced with the new status report for the installer. webchick requested they be split in the issue, and I was planning to do the same with the files directory when some of the other installer cleanup patches are in.
Comment #28
XanoIt's logical Drupal hasn't got permission if the file doesn't exist, but for novices this might be confusing, since they can see both errors as separate problems while in this case they are one.
Comment #29
catchXano, please open a separate issue for that if you think it's a problem.
Comment #30
Anonymous (not verified) CreditAttribution: Anonymous commentedThe last submitted patch failed testing.
Comment #31
dman CreditAttribution: dman commentedDuplicated effort of some sort over at http://drupal.org/node/208662
Comment #32
beginner CreditAttribution: beginner commentedNote that the current instructions are misleading anyway if you have already created a sites/example.org folder .
It says:
but the code requires
./sites/default/default.settings.php
to exist. (I had removed the default directory as I didn't want any default).Comment #33
XanoThat's why it says "copy". This means you will have to leave the original intact.
Comment #34
beginner CreditAttribution: beginner commented@xano: read better #32. Even by copying (i.e. following the instructions to the letter), it fails in that specific configuration.
Comment #35
dman CreditAttribution: dman commentedSo it doesn't count as renaming because you actually copied first, then deleted the original. But that's different from renaming, and is actually copying, even though the original was destroyed.
Hm.
I guess the lesson to be learned here is that yes,
if you delete configuration files that were distributed as part of the core of an application package just because you think you had no use for them then yes, unknown things can break.
[insert story here about uncle who decided he was tired of looking at that
boot.ini
file - which he clearly never used...]Does the file have to be called
default.settings.php.do.not.delete.me
?Those instructions do need to be worded more strongly, just to cover the cases of other things that people should NOT do when following the instructions.
Alternative wording suggestions welcome...
Comment #36
Anonymous (not verified) CreditAttribution: Anonymous commentedI need to look at this more but I'm not so sure why we should be so dependent on a file that is seemingly a template in the first place. If you ask me a template configuration file is to be used once (on initial installation) and requiring default/default.settings.php when a settings.php is found is a bit overboard in the saneness checking.
Comment #37
Dave Reidearnie, it needs to be re-used for multisite installations.
Comment #38
Anonymous (not verified) CreditAttribution: Anonymous commentedIf the need for default.settings.php is so great perhaps it needs to be moved to the system module folder. This would make it look less like an unimportant file that can be deleted.
Comment #39
hansfn CreditAttribution: hansfn commenteddman wrote:
I agree, but the problem here is that the file is named default.... and you are asked to copy it, indicating strongly that the default file is really just a sample. Sample config files are very common, and in all OS-es I have tried they can be removed without any side-effects what so ever.
Something has to be done with location/naming of that file - I agree with earnie on that.
Hans
PS! I normally like Drupal a lot and I use it for all classes I teach (at college), but that the installer (in Drupal 6.9) simply failed when I moved default.settings.php to settings.php, without any explanation, was a very bad experience - in front of my class. I and my 70 students found Drupal extremely stupid when we realized that it actually required the sample file to be present to work.
Comment #40
topper910 CreditAttribution: topper910 commentedComment #9 gives the best advice here. There was no need for a patch just simply making sure I had a copy of settings.php and default.settings.php This fixed worked. Thanks!
Comment #41
Anonymous (not verified) CreditAttribution: Anonymous commentedResetting fields to more appropriate values. Unfortunately I can't revert the Assigned field to the previous value.
Comment #42
Bojhan CreditAttribution: Bojhan commentedI spoke with DamZ this weekend about this issue, and we should remove the default.settings.php copy step and just let it be rename. Which means that it doesn't have to check for default.settings.php and we just move the php settings and all that stuff in an other file or in the database.
Comment #43
Anonymous (not verified) CreditAttribution: Anonymous commentedMy opinion is that such things belong in a file in the system module.
Comment #44
webchickMarked #479006: Cannot rename sites/default/default.settings.php a duplicate of this bug. That is pure ugliness. I'd sure like to see this fixed.
Comment #45
Anonymous (not verified) CreditAttribution: Anonymous commentedBeginner in comment #32 has a good point. He/she correctly identifies that the documentation instructs the installer to create a copy within the target directory (note that it doesn't say default directory). In a multi-site implementation I would suggest that using a "default" directory is not a best practice. By defining each of the domains, you better control risks associated with later installations. Consider the following environment:
(an established domain/directory)
(an established domain/directory)
(target directory containing original, unmodified default.settings.php and settings.php files)
Because the default.settings.php file must exist in the "sites/default" directory as required (hard coded) by line 176 of "includes/install.inc" ("$default_settings = './sites/default/default.settings.php';")(Drupal 6.12), the following must also exist:
(directory only containing original, unmodified default.settings.php file)
So besides the issue with the install not checking for the existence of the file, I propose that it isn't even looking for it in the correct place. It is searching outside of the scope defined by the installation in a multi-site environment. I have given thought to the process of creating all environments within a default directory that can be renamed to the correct site name but consider the following objective:
(an established domain/directory)
(target directory containing original, unmodified default.settings.php and settings.php files)
Starting the process by initially naming "sites/subdomain.mydomain.tld" as "sites/default" and running the install process has the unfortunate effect of going to the "sites/mydomain.tld" directory and the "sites/default" directory is never touched. The only way to mitigate this is to also rename the "sites/mydomain.tld" directory, thereby breaking that environment.
My suggestion would be to also change the "includes/install.inc" file to search for the file in the same location as the "settings.php" file. Perhaps with a change similar to the following:
- $default_settings = './sites/default/default.settings.php';
+ $default_settings = './' . conf_path(FALES, TRUE) . '/' . $prefix . default.settings.php';
$settings_file = './'. conf_path(FALSE, TRUE) .'/'. $prefix .'settings.php';
(Not sure how the "$prefix" variable is used so am not sure if it should be excluded.)
Comment #46
Damien Tournoud CreditAttribution: Damien Tournoud commentedWith this patch, Drupal makes writes settings.php based on itself, without trying to use default.settings.php. This:
* allows mistakes in the workflow (you can either rename or copy default.settings.php)
* solves the issues described in #45
Comment #47
catchWhat happens if you do touch sites/default/settings.php?
Comment #48
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks for the contribution Damien (#46). I would agree that your suggestion would make more sense from a design perspective but I hadn't taken the leap to make the statement that default.settings.php was unnecessary in the overall flow. I would have thought that using a copy of this file, renamed to "settings.php" which would then be updated within the install process, would have sufficed. In fact this was how I thought it would have worked and resulted in early install failures until I noticed that you had to have both files.
Catch (#47), I'm not sure which senario you are referencing from your question. If you are asking about the one where installing a multisite instance for a subdomain, any objects in the "sites/default" directory will not be part of the process because of the cascading nature of directory selection found in the Drupal environment. The subdomain is tried first, followed by the main domain, before any default directory is tapped. If this isn't the question that you are asking please let us know.
Comment #49
catch@james.tank - usually I install by creating an empty settings.php - i.e.
touch sites/default/settings.php
- simply because it's less typing thancp sites/default/default.settings.php sites/default/settings.php
.This is documented as an option in INSTALL.txt
I should probably just try it to see if it breaks, but about to head out.
Comment #51
catchjames.tank I'm aware of the original bug, just want to make sure there's no regressions elsewhere. I tested Damien's patch with an empty settings.php and still ended up with a proper settings.php afterwards, so no objections here.
Comment #53
Damien Tournoud CreditAttribution: Damien Tournoud commented@catch: nothing should break in that case, you will just end up with a settings.php containing only the database credentials.
The only two ini_set() we have in default.settings.php are useless in most case, and we should move them out.
Comment #54
Damien Tournoud CreditAttribution: Damien Tournoud commentedAnd I should have read #51 before writing.
Comment #56
YesCT CreditAttribution: YesCT commentedI'm confused. What is the next step for this patch? Is the approach valid? (I originally came to this patch, because I did a mv instead of a copy, and I thought it should have given me a warning message that default.setting.php needed to be there.)
I dont understand why it failed the testbot.
I tried the patch on cvs, and it applies (with 3 line offset), and it installs with the patch [both when "copy" default.settings.php and when "mv/rename" default.settings.php.
I set to needs review to have the testbot try again. Maybe it was a testbot problem?
Comment #58
webchickOh, slave #26. Why must you be so buggy?
Comment #60
deekayen CreditAttribution: deekayen commentedtrying out a new testing bot that apparently wasn't working
Comment #63
carlmcdade CreditAttribution: carlmcdade commentedI just downloaded and tried to install D7. The install fails because settings.php is not seen regardless of the permissions (set to everyone 777). This is on a Macbook Pro using Xammp with PHP 5.29
Comment #64
aspilicious CreditAttribution: aspilicious commenteddid you coppied and renamed default-settings.php to settings.php??
Comment #65
carlmcdade CreditAttribution: carlmcdade commentedYes, copied using the command line. Since this is on a Mac I also tried to use sudo and root with no effect. So the problem is not in the naming or the permissions but rather in the code somewhere. D7 is not seeing the "settings.php" file or is choking on the template file being in the same directory.
Comment #66
carlmcdade CreditAttribution: carlmcdade commentedOkay it seems that this problem is particular to running Xampp on a Mac. Mac os x Leopard does not set the right ownership permissions on the files that are created in the GUI. You have to sudo and create in the command prompt. For some reason being logged as root and creating the file only makes things worse.
Comment #67
dman CreditAttribution: dman commentedOff-topic to this thread - but since folk not getting their permissions right is such a FAQ...
@carlmcdade FYI this tip may help, I figured it out on OSX myself recently.
I add my own user to the 'www' group, and get the www daemon to share everything with its group by adding
umask 0002
to/etc/launchd-user.conf
. This means the webserver doesn't make things I can't change.This also applies to files I create in the GUI, so by default, things I write are readable by the group.
Comment #68
carlmcdade CreditAttribution: carlmcdade commentedPerfect! Thanks Dman! This makes things so much easier. Maybe this should be part of the Handbooks installation section.
Comment #69
dman CreditAttribution: dman commentedFlagged #208662: Missing default.settings.php produces no warning as duplicate.
Based on http://drupal.org/node/418302#comment-2500118 I'd like to bump this priority if the automated solution (copy the files for you) is now dead in the water.
Comment #70
iantresman CreditAttribution: iantresman commentedHaving reached the "Set up database" part of the install, I had renamed "default.settings.php" to "settings.php" and set the permissions to 777. On entering the database information and clicking "Save and continue", I also get the error messages:
Warning: fopen(/mysite/public_html/sites/default/default.settings.php): failed to open stream: No such file or directory in /mysite/public_html/includes/install.inc on line 428
and
Failed to open sites/default/default.settings.php. Verify the file permissions.
I was able to resolve the issue by ensuring that my sites/default directory contained:
Comment #71
fabianogoos CreditAttribution: fabianogoos commented#7: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #72
LT-1 CreditAttribution: LT-1 commentedinstallpatch.patch queued for re-testing.
Comment #73
LT-1 CreditAttribution: LT-1 commented#5: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #74
LT-1 CreditAttribution: LT-1 commented#15: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #75
LT-1 CreditAttribution: LT-1 commented#20: install_check_for_defaultsettingsfile2.patch queued for re-testing.
Comment #76
EvanDonovan CreditAttribution: EvanDonovan commentedThis still happens as of CVS checkout of Apr. 3rd, if you
mv default.settings.php settings.php
. And it doesn't fail till after you've gone through the database configuration step. :(Let me try the patch to see if it resolves it.
Comment #77
EvanDonovan CreditAttribution: EvanDonovan commentedPatch doesn't apply now that install.php has a include. Going to re-roll.
Comment #78
EvanDonovan CreditAttribution: EvanDonovan commentedPatch applies now & has been tested to properly throw a requirements error when default.settings.php is missing. Once it exists again, installer proceeds as expected.
Pretty please webchick, can this get in? :)
It's the least we can to help mitigate the problem #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) was intended to fix...
Comment #79
EvanDonovan CreditAttribution: EvanDonovan commentedFirst ever patch of mine to pass SimpleTest. Yay! :)
Comment #80
chx CreditAttribution: chx commentedYou have added empty lines with just spaces in it. Please don't.
Comment #81
EvanDonovan CreditAttribution: EvanDonovan commentedchx: OK.
I'll try again.
Comment #82
EvanDonovan CreditAttribution: EvanDonovan commentedSame patch. Now with no unneeded whitespace :)
Comment #83
chx CreditAttribution: chx commentedBetter :)
Comment #84
David_Rothstein CreditAttribution: David_Rothstein commentedNice, it would be great to fix this! But this patch still needs some work.
If adding this variable, we should also reuse it in the other part of this function (see
$requirements['settings file exists']
) which currently has code that duplicates this definition.Here, and in two or three other places in the patch, should be "throw an error".
This entire code block occurs within an else() statement such that it only runs when the settings.php file already exists... however, since the instructions for creating settings.php say to copy this file, those instructions won't be complete if this file doesn't exist either, right? So, I would recommend that this code move above the
if (!exists) {...} else {...}
block; that way the error messages make sense even in the (admittedly unlikely) case of someone who doesn't have either default.settings.php or settings.php."Settings" should be lower case.
Drupal is no longer polite - see #679890: Using "Please" in the interface :) By analogy with other messages in the installer (and the fact that we already told them in the main message here that the file does not exist, so therefore don't need to say it again), I'd recommend rewording this as:
"The @drupal installer requires that %default-file not be modified in any way from the original download."
Comment #85
EvanDonovan CreditAttribution: EvanDonovan commentedDavid_Rothstein:
Thanks very much for the review! Your comments are all very specific and actionable. This is my first time helping out with re-rolling a core patch, so I am still learning the ropes to a large extent.
I probably won't be able to work on this more for a few days, but I'll definitely try to come back to it.
If someone else wants to re-roll with these issues fixed, that would be great. I just would really like to see this issue fixed, even though it won't be a full solution to the pitfalls with the necessity for a file copy.
Comment #86
David_Rothstein CreditAttribution: David_Rothstein commentedOK, well I might as well just reroll it while it's fresh in my mind, then :) Hopefully someone can mark this one RTBC.
This will indeed not be a full solution, but it will help a lot, and I also have some hope that we might be able to reopen #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) with a (partial) fix for D7. But in order to do that, this patch needs to get in first.
Comment #87
tobiasbComment #88
tstoecklerUnneeded whitespace.
Patch attached. Leaving at RTBC, because I literally deleted one character in the patch file.
Powered by Dreditor.
Comment #89
DanielMendle CreditAttribution: DanielMendle commented#5: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #90
EvanDonovan CreditAttribution: EvanDonovan commentedDanielMendle: That patch no longer applies. The patch to test is #88, which has already passed just about a week ago. Please post a review of whether it resolves this issue & hopefully we can get this committed soon.
Comment #91
EvanDonovan CreditAttribution: EvanDonovan commented#88, which is tstoeckler's re-roll of David_Rothstein's patch still applies (with slight offset). Dreditor review indicates no whitespace issues. The patch solves the problem originally reported in the issue, and does it in a cleaner way than my re-roll did.
Thus, I second the RTBC :)
Comment #92
David_Rothstein CreditAttribution: David_Rothstein commentedBumping because it's been RTBC for a month and would be great to get fixed :) Patch still applies.
Comment #93
EvanDonovan CreditAttribution: EvanDonovan commentedDavid_Rothstein: Thanks. I've mentioned it on IRC a few times, but I know that webchick & Dries are busy :)
Comment #94
navidoes CreditAttribution: navidoes commentedinstallpatch.patch queued for re-testing.
Comment #95
navidoes CreditAttribution: navidoes commentedinstallpatch.patch queued for re-testing.
Comment #96
navidoes CreditAttribution: navidoes commented#5: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #97
navidoes CreditAttribution: navidoes commented#7: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #98
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #99
arhak CreditAttribution: arhak commentedwouldn't this need to be backported?
just found this forum topic Error When trying to install drupal 6.17
Comment #100
Damien Tournoud CreditAttribution: Damien Tournoud commentedAgreed on the need to backport.
Comment #101
arhak CreditAttribution: arhak commentedComment #102
EvanDonovan CreditAttribution: EvanDonovan commentedThanks so much, Dries! Legions of newbie Drupal users are grateful :)
Thanks, arhak and Damien, for agreeing to work on a backport. I will try to test in the next few days.
Comment #103
christian.neu CreditAttribution: christian.neu commentedinstallpatch.patch queued for re-testing.
Comment #104
christian.neu CreditAttribution: christian.neu commentedinstallpatch.patch queued for re-testing.
Comment #105
nitnut CreditAttribution: nitnut commented#15: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #106
EvanDonovan CreditAttribution: EvanDonovan commented@nitnut, @csn102: The patches you queued for testing are D7 patches, and this issue has been fixed for D7. The D6 backport is in #101.
My apologies for not testing it yet myself.
Comment #107
klausitrailing white space
Powered by Dreditor.
Comment #108
shiyaodou CreditAttribution: shiyaodou commentedinstallpatch.patch queued for re-testing.
Comment #109
shiyaodou CreditAttribution: shiyaodou commented#10: install_check_for_defaultsettingsfile.patch queued for re-testing.
Comment #110
mustafalx CreditAttribution: mustafalx commentedinstallpatch.patch queued for re-testing.
Comment #111
bhaskarinfy CreditAttribution: bhaskarinfy commentedrename the default.settings.php to settings.php and then restart installation process. The error is rectified.
Comment #112
amargaikwad1986 CreditAttribution: amargaikwad1986 commentedinstallpatch.patch queued for re-testing.
Comment #114
pirso CreditAttribution: pirso commentedinstallpatch.patch queued for re-testing.
Comment #115
pirso CreditAttribution: pirso commentedinstallpatch.patch queued for re-testing.
Comment #116
_12345678912345678 CreditAttribution: _12345678912345678 commentedI am on linux mint 13 cinnamon and had this issue as well. I found that moving the file and copying it worked fine. How is the patch coming ?
I ran these commands.
mv default.settings.php settings.php
cp settings.php default.settings.php