Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I did some testing tonight and found 2 problems to with the upgrade from D6 to D7.
1. The block_ips table is breaking the upgrade. Their is an exception which is being fired is being caught by something else, when drupal_bootstrap(DRUPAL_BOOTSTRAP_ACCESS); is being called. I did find that you can set in the conf to get the blocked_ips from a variable instead of the table.
2. The role_permission table is also breaking the upgrade, and by creating it, it fixes the issue.
I have created a patch and with a basic system it will upgrade with no problems.
Comment | File | Size | Author |
---|---|---|---|
#35 | dothtaccess.txt | 5.63 KB | cvdenzen |
#5 | 0001-blocked_ips-exception-not-caught.patch | 1.42 KB | gordon |
#3 | 0001-blocked_ips-exception-not-caught.patch | 1.42 KB | gordon |
drupal_upgrade.patch | 3.03 KB | gordon | |
Comments
Comment #1
Dave ReidNote this will need manual testing since the testbot does not do 6->7 upgrades.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe 'blocked_ips' part should be already taken care of. The change seems like a won't fix.
Not sure about the 'role_permission' part. The upgrade path has been manually tested a few weeks back, and there was no issue with that. I'm not sure what changed that could break the upgrade path.
Comment #3
gordon CreditAttribution: gordon commentedI have split this out into 2 patches.
If the blocked_ips table doesn't exist when you are upgrading then you get a WSOD.
There was an attempt to catch the exception un the update.php but this is not working because any exception raised during an DatabaseConnection::query() (specifically the PDO::execute()) are being caught there and not back in the update.php
What I did find in the drupal_is_denied() you can have a variable_get('blocked_ips') which will be used instead of querying the table. So I preloaded this directly into the global $conf so it doesn't save back in the database.
Comment #4
Dries CreditAttribution: Dries commentedThat seems to work. There is a tiny coding style error though. Need an extra space before '+='. I can fix that before the commit, once this is marked at RTBC.
Comment #5
gordon CreditAttribution: gordon commentedOops. I have fixed the formatting issue.
Comment #6
David_Rothstein CreditAttribution: David_Rothstein commentedI am not able to reproduce this bug. I just tried updating a D6 site to D7 and had no problems at all... I also did some debugging to verify that the exception was being caught in update.php as intended, and it was.
What are the specific steps needed to encounter this?
Also, if there is somewhere else further down that in some cases is catching this exception too early and doing something with it that it shouldn't, we should probably look at that code to see if the problem can't be fixed there...
Comment #7
gordon CreditAttribution: gordon commentedMy test is an upgrade of a more or less clean Drupal 6 install and then running the upgrade to Drupal 7.
Before I copy in my Drupal 6 database I make sure that all the tables are removed. As you should also be getting the error when the role_permissions doesn't exist.
Also I am running on PHP 5.2.5 (not sure if this will make a difference) but I know there are issues with 5.2.9, (I have not tested 5.2.10)
Now when I running the below code the exception is caught by the inner try and not the outer.
Lastly my solution I feel is much cleaner than using the exception catching as we can just turn off the requirement for the blocked_ips table.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commented@gorbon: the PDOException should bubble up to update.php... what makes you think there is a inner try/catch? can you pinpoint it?
Comment #9
gordon CreditAttribution: gordon commented1 thing that it may be is that I am running the upgrade as an anonymous user. I am having other problems with session as well.
Comment #10
gordon CreditAttribution: gordon commentedI have done some more investigation and I can catch the exception at every level and re-throw it right back to though the bootstrap.inc and it is caught everytime but once I get into the update.php the exception is not caught.
Any ideas? I am not able to work out why this would be happening.
Comment #11
catch@gordon - do you have devel module installed and enabled? The hook_boot() in devel calls user_access() which queries the role_permission table which blows up when it can't find it.
Comment #12
gordon CreditAttribution: gordon commentedNo the devel module is not enabled.
The problem that the exception is not being caught in update.php. The exception is caught in database.inc and bootstrap.inc (when I add the try...catch) but not in update.php
Comment #13
David_Rothstein CreditAttribution: David_Rothstein commentedI've tried reproducing this a number of times, and can't get it to happen for me.
However, I can (on rare occasions) get the role_permission problem to occur -- I posted more info at #524710: role_permission required to upgrade from D6 to D7. Another error am I also seeing (also only sometimes) occurs in system_update_7020() and is this:
Trying to allocate on the order of 2 GB of memory?... hm....
The fact that there are so many fatal errors that people are getting during update.php but that cannot be reproduced consistently is, to say the least, a little troubling :) I have not found any pattern to when I see the above errors; it appears to occur almost randomly.
Comment #15
gordon CreditAttribution: gordon commentedI have done some more work on this and I have found that in PHP 5.2.5 you get this problem where as this is resolved in PHP 5.2.6
I am not if we should the minimum requirement to run Drupal 7 should be 5.2.6 or 5.2.x.
The answer to this question will determine if this patch should be committed or not.
Comment #16
catchI'm getting this on PHP 5.2.6 now - there was some bootstrap refactoring with the cache patch recently which might have changed the situation slightly.
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedMarked #569410: Can't update D6 -> D7 table not found (drupal_blocked_ips) as duplicate.
Comment #18
int CreditAttribution: int commentedThe patch #5 still applys?
Comment #20
int CreditAttribution: int commentedSo, this patch is assigned to gordon, can you make this patch apply's to the current HEAD?
I want to test the update of my prodution site, to see the errors. Thanks..
Comment #21
mikl CreditAttribution: mikl commentedI have the same problem on Apache/2.2.13 (Unix) PHP/5.2.10:
This is with the version here: http://github.com/mikl/drupal/commit/d128180ae17ea511b7b8b5437b847a2cc04... – latest HEAD at this point in time.
Comment #22
Damien Tournoud CreditAttribution: Damien Tournoud commentedI confirm that the upgrade path is broken. Patch coming up.
Comment #23
int CreditAttribution: int commentedthat's nice, thank you
Comment #24
Damien Tournoud CreditAttribution: Damien Tournoud commented#583008: IP address blocking does not work on update.php is part of the problem. The patch in there is probably a solution too.
Comment #25
gordon CreditAttribution: gordon commentedIt seems to be an issue with the version of Drupal. 5.2.10 has problems as you can't run the testing, 5.2.5 also has problems, but I have had success with 5.2.6 which is why I haven't really done much lately.
Comment #26
int CreditAttribution: int commentedYep, we don't have this problem any more.. But we have others, now when I update show this:
PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
Comment #27
int CreditAttribution: int commentedComment #29
DaleEMoore CreditAttribution: DaleEMoore commentedThe block_ips table is breaking the upgrade from 6.20 to 7.0-rc3 as I have described here http://drupal.org/node/1006932#comment-3866950.
I wish it wasn't so,
Dale
Comment #30
Damien Tournoud CreditAttribution: Damien Tournoud commentedPlease do not reopen old issues like that. Your problem is most probably unrelated.
Comment #31
DaleEMoore CreditAttribution: DaleEMoore commentedIt's nice to hear from you Damien Tournoud. Did you look at my problem description? I mean, you might be right; but how would I know? Looking for some guidance from you other than SLAP don't do that. And any little hint would be appreciated!
Comment #32
cvdenzen CreditAttribution: cvdenzen commentedUpgrading from 6.22 to 7.10 gives (on one of my 2 sites, but not on the other!):
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'web49-a-drupa-7.drupal_blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 84.81.200.16 ) in drupal_is_denied() (line 1856 of /home/sites/vandenzen.nl/public_html/drupal/includes/bootstrap.inc).
Comment #33
Everett Zufelt CreditAttribution: Everett Zufelt commented@cvdenzen
Can you please let us know which version of PHP is running on the working and not working sites?
Comment #34
marcingy CreditAttribution: marcingy commentedComment #35
cvdenzen CreditAttribution: cvdenzen commentedBoth sites run php version 5.2. They both run on the same server (your-webhost.nl).
The difference is that the site that did not complain was a redirected site (http://arjan.vandenzen.nl -> http://vandenzen.nl/drupal1). The complaining site is the root site http://vandenzen.nl with a modified .htaccess file.
Both sites run from the same Drupal codebase in /drupal.
I will attach the .htaccess in root directory, but I am not sure whether that is the version I had during the upgrades.
Comment #36
clemens.tolboomI'm gettings this while upgrading through drush and some scripts.
There are two tricky parts
1. The ctools_include used by views causes a error 500 (as all modules are disabled per instruction)
2. system_update_7003 is ran without a successful system_update_7002() which should create the block_ips table.
Due to the batches ran by drush the first batch failed and thus the second batch too?
I fixed this by
then run
drush updb
again.Note that people claiming 'cannot reproduce' have probably truncated all D7 clean install tables then ran the upgrade again this way preserving the block_ips table. This is probably what @DaleEMoore reported through #27 link to a forum topic.
Further steps to investigate:
- are views hook_update_N ran earlier to system_update_N ?
- is a internal server error 500 allowing batch API to continue ?
Comment #37
clemens.tolboomI did not fixed it as ctools is now only enabled but not correct installed. The updates are ran until ctools wants to do it's business.
But the site is lacking a WSOD so disable and uninstall ctools then enable again.
Comment #38
Hari CreditAttribution: Hari commenteddrupal_upgrade.patch queued for re-testing.
Comment #39
marcingy CreditAttribution: marcingy commentedComment #40
eyersee CreditAttribution: eyersee commentedHi, I have just conducted an upgrade from v6.23 to 7.12 and have encountered issues as per this issues report. I would like to know how I can utilise the patch script to try and test this as a fix to the issue. If you can please supply me with instructions it would be much appreciated.
Thank you
Ian
Comment #41
hewhocutsdown CreditAttribution: hewhocutsdown commentedupdate.php won't even load for me, but if I go to the website root, it displays:
OException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[DBNAME].blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 10.8.2.21 ) in drupal_is_denied() (line 1895 of /var/www/includes/bootstrap.inc).
Attempting to apply the patch failed (HUNK #1 failed at state 528).
[Note: this is an upgrade from Drupal 6 to 7]
Comment #42
clemens.tolboomIn #36 I did not ran
drush sql-query "update system set status=1 where name = 'ctools'"
but I diddrush sql-cli
then executed SQLupdate system set status=1 where name = 'ctools';
Running the updates fails on comment update
Comment #43
clemens.tolboomToday I discovered my upgrade script failed to disable D6 modules due to a missing drush alias. (
drush @site.d6 pm-disable `drush @forgotten.d6 pml --pipe --status=enabled --no-core`
)After disabling all none core modules this error disappeared :)
@hewhocutsdown: are you sure all none core modules are disabled?
Comment #44
mgiffordThere are a few related issues I'm pointing to this. This looks like it's the closest.
I was also using drush @sites so perhaps it's related to that.
Comment #45
mntash CreditAttribution: mntash commentedCan someone please let me know what the latest is on this?
I am having this same issue when upgrading to D7:
I run upgrade.php and get this error: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'domain_front.blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 174.39.3.189 ) in drupal_is_denied() (line 1883 of /home/domain/public_html/includes/bootstrap.inc).
Comment #46
mgiffordIt should be possible to just add it, though not sure that's going to address the root problem. Worth trying though.
Comment #47
mstrelan CreditAttribution: mstrelan commented#46 works if you also put a return statement at the top of system_update_7002() in system.install, otherwise it will fail saying the table already exists.
Comment #48
vcrkid CreditAttribution: vcrkid commentedSo do #46 and #47 work? I'm afraid I have no real knowledge how to implement #47 apart from my own guess at it.
Any help? Has anyone figured this out yet?
Comment #49
KhaledBlah CreditAttribution: KhaledBlah commentedI've seen this error message as well:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxx.drp_blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 192.168.x.x ) in drupal_is_denied() (line 1895 of <path_to_drupal>/includes/bootstrap.inc).
It might be relevant to know that I use Drupal behind a reverse proxy.
#46 in conjunction with #47 seems to solve it.
NOTE: #46 is only for mySQL backends and there is no table prefix which users might overlook (I did).
Comment #50
KhaledBlah CreditAttribution: KhaledBlah commentedAs I said in #49 I use drupal behind a reverse proxy. The error message described in #49 went away once I set the "$base_url" variable in settings.php before I started the upgrade. Other may have similar problems.
Comment #51
vcrkid CreditAttribution: vcrkid commentedAlright, I seemed to have gotten it to work at the end. I followed #46 and #47 (I'm using Acquia Dev Desktop btw) and I was still having problems - I got an error that seemed to be connected with the Domain Access module, so I changed that version to the Drupal 7 one and voila!
I'm not sure if this is an isolated case or if that comment might help others. Good luck!
Comment #52
gtwa CreditAttribution: gtwa commentedHow do I do a return statement described at the top of system_update_7002?
I put the code from from #46 into my bootstrap.inc file (that seems right, could be wrong), I just don't know how to create said return statement described in #47. Please forgive me, I'm a beginner at this. Just learning my way through all the problems.
Here's my specific error code if it helps:
Comment #53
gtwa CreditAttribution: gtwa commentedWould you help a wee novice?
How do I do a return statement described at the top of system_update_7002?
I put the code from from #46 into my bootstrap.inc file (that seems right, could be wrong), I just don't know how to create said return statement described in #47. Please forgive me, I'm a beginner at this. Just learning my way through all the problems.
Here's my specific error code if it helps:
Comment #54
foxmarks CreditAttribution: foxmarks commentedFWIW, I was getting this error attempting an upgrade from D6.24 to D7.14
My site uses .htaccess to redirect its URL to the Drupal install in a subfolder. I copied all the files (including settings.php) into a new D7 subfolder.
In the first attempt at upgrading, Drupal recognized the previous install. When I clicked the “update” link, I got the WSOD. I then pointed my URL back to the D6 install and it was still functioning correctly. When I re-pointed back to the D7 subfolder I got this “1146 Table blocked.ips” error.
I recopied the D6 settings.php into the D7 install, and Drupal recognized the previous install again. This time, the “update” link worked. The upgrade has completed successfully.
I don’t know why…
Comment #55
babbage CreditAttribution: babbage commented@foxmarks, and almost certainly some others who will pass by here: you will get this error if you have a settings.php file that has already been updated to the Drupal 7 format, and try and run the upgrade process on a Drupal 6 database with the Drupal 7 codebase. The most likely scenario for this is if you are trying to upgrade to Drupal 7, encounter an issue that prevents it from successfully completing, roll back your database to the original Drupal 6 backup, but forget to roll back your settings.php file to Drupal 6.
In such circumstances, restoring the old settings.php file will fix the problem, and in my experience it is likely in many cases that you can just delete the new block of code at the end of the settings.php file that the upgrade has inserted, and this will achieve the same result.
Hope this saves someone some exasperated hair pulling. :)
Comment #56
drzraf CreditAttribution: drzraf commentedcan reproduce,
a (far from acceptable) workaround is commenting-out the "blocked_ip" conf directive present in stock D7 settings.default.php
Comment #57
hermes_costell CreditAttribution: hermes_costell commented@babbage:
GREAT TIP! Thanks very much - this was my issue. I was upgrading / downgrading / upgrading again, trying to figure out some migration issues and hadn't carefully wiped out the newly created settings.php file.
Comment #58
kumarprince CreditAttribution: kumarprince commentedPDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'ppp.blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 127.0.0.1 ) in drupal_is_denied() (line 1909 of C:\Users\GovGuru\Desktop\Working\subteampartners\includes\bootstrap.inc).
I am getting this error, Its been a week and I am unable to fix it. I have gone through the entire post but didn't find any solution. I am using Acquia Dev Desktop software
Comment #59
Andrew Schulman CreditAttribution: Andrew Schulman commentedIn MySQL, you can create the missing table by submitting the following SQL against your D7 database:
After that the upgrade should continue normally.
Comment #60
Celine Bessa CreditAttribution: Celine Bessa commented#3: 0001-blocked_ips-exception-not-caught.patch queued for re-testing.
Comment #61
Celine Bessa CreditAttribution: Celine Bessa commenteddrupal_upgrade.patch queued for re-testing.
Comment #62
kenorb CreditAttribution: kenorb commentedI had similar problem, but the problem was in Deploy module which was disabled and was trying to bootstrap core by it-self.
See: #2128231: Deploy breaks Drupal 6 to 7 upgrade when using drush
(backtrace available)
Comment #63
kenorb CreditAttribution: kenorb commented(removed)
Comment #64
kenorb CreditAttribution: kenorb commentedMore backtraces are needed.
Comment #65
dgtlmoon CreditAttribution: dgtlmoon commented(maintainer needs more info) ? It's clearly happening to a lot of people, the backtrace would be simply that the table is missing
Comment #66
Mutedhorn CreditAttribution: Mutedhorn commentedI am having the same issue, but it appears to be bigger problem than just blocked_ips table not being there. I imported from a D7 database still produced errors. It seems to a larger issue with the update.php failing. Tried from the update several times incase the files themselves didn't transfer correctly but it keeps producing the blocked_ips error. Or after a blocked_ips table has been imported it produces: Fatal error: Class 'SelectQueryExtender' not found in /nfs/c08/h03/mnt/153362/domains/gc.robohobo.net/html/includes/tablesort.inc on line 15
Please advise. All my other drupal upgrades have worked without a hitch but this one has me banging my head on the desk. Thanks!
Comment #67
clemens.tolboomJust a note: This blog post suggests a work around http://www.thedavidmeister.info/post/quick-tip-workaround-table-blockedi...
I haven't tested this but hope this helps people to update the summary.
Why is the issue version set to 7.22 ?
Comment #68
colanThis should probably be tracking HEAD.
Comment #69
whoislorenzo CreditAttribution: whoislorenzo commentedI'm having this same issue. What is the fix? O
Comment #70
Andrew Schulman CreditAttribution: Andrew Schulman commentedAs far as I can tell, there is no fix yet. I tried all of the workarounds described here, with inconsistent results. At no time was I able to finish the upgrade. I finally gave up and rebuilt my D7 site from scratch. More work, but at least it gives you a reliable path to a solution.
Comment #71
colan@whoislorenzo: Please don't change the version as this needs to be fixed in dev first, and don't assign it to yourself unless you plan on providing a patch which fixes the issue.
Comment #76
cilefen CreditAttribution: cilefen commented+1 for this issue. I remember having it on a few sites I upgraded last year.
Comment #77
cilefen CreditAttribution: cilefen commentedI saw exactly what was in #41.
For me, creating the table, something like what was shown in #59 fixed the issue. We should consider dropping this issue to major from critical because there is a workaround.
Comment #78
cilefen CreditAttribution: cilefen commentedI am dropping this to Major because there is a workaround that I personally used many times.
Comment #79
roynilanjan CreditAttribution: roynilanjan commentedUnderlying problem in the
includes/bootstrap.inc
line 2178. As in that line this is assumedthat PDO has loaded the database.inc but during this phase of bootstrapping still
the
system_update_7000();
yet to execute(which is basically responsible to create the blocked_ips table),hence the break happens during up-gradation.
So rather to patch in
update.php
(as suggested in #5), this'll be more efficient if we can provide a kind of solution asalthough this need to be tested more & let advise on this solution then I can provide it as patch.
Please remember this will be from D-7.5, probably for that reason line number from bootstrap.inc is not matching
from above comments
Comment #80
roynilanjan CreditAttribution: roynilanjan commented