Okay... this is the same error that we encountered before... onto research!

Let's export the database from RHEL 6 again:

I ignored that warning before... but let's see if addressing the max_input_vars config solves the import issue on RHEL7?

Let's find where the php.ini file is located:

php -i | grep "Loaded Configuration File"

we will make a backup of the current one... call it php.ini.pre-rush-changes

now we can edit the php.ini without any worries — well.... but with caution:

Giving Apache the boot---

Let's do the same on RHEL7:

php -i | grep "Loaded Configuration File"

vim php.ini

It's commented; let's uncomment it and then give apache a boot.

Nope... still same error; I will revert the change in the php.ini file... as that had no impact it seems!

Try #5: This time, with Views caching disabled, because upon inspecting the import, it turns out that it has error'd out on the caching table each time:

So on the live site, we will not only disable Views caching, but also clear out the cache overall and then export the DB:

As can be seen, Views caching is not disabled... so let's disable it...

Alright, let's re-export and then import again, and see how it fares this time...

Prior to importing, need to drop the half-imported DB:

Alright... we get confirmation that prep DB been dropped... let's import the database again...

Let's check where it stopped...

Yep... it's the same table that is causing the import problem... each failed import has stopped at cache_menu — more research time!

I noticed that there is an option to flush all caches...

so let's try that:

And we export from RHEL6.... and then try importing it to RHEL7........ ......... again

So the file sizes between the previous try and the current one are definitely different... let's see what happens on import:

SAME ERROR... checking the progress (i.e. how much was it able to import...)—

Again, it stopped at cache_menu... so apparently, Flush all caches didn't do what I thought it would do...

There is a sub-sub-menu item "Menu"----let's see if clearing that has any effect?

Prior to clicking that option, here's the cache_menu table on RHEL6—

Clearing menu cache:

cache_menu table on RHEL6 now....

No change :-/

More research....

Try #? — Import using the SQL tab?

Let's drop the DB first--

Interesting:

The details didn't help... running the pasted SQL—this is with the hope that if it errors out, we have a detailed (which line in the script it failed on error) info:

Yea... no dice:

Looking at the SQL file, we know that the import always fails on cache_menu after inserting 7 records and so what's the 8th record? Check this out:

Yea... I am sure that is above the max setting... getting rid of that insert and trying the import again:

Note: removing that one query alone dropped the file size by a good chunk... Also note, we are not too worried about that one record — because it's a cache record anyways... so the system should be able to rebuild it.

AND..... .SUCCESSSSSS! We have the DB imported:

Now, comes the code....

rsync -av PREP rjb03001admin@phptst1.its.uconn.edu:/apps

Nice! The code has been moved off of RHEL6 and onto RHEL7—

Change the settings file, same as with other portals:

vim /apps/PREP/sites/default/settings.php

→ Change $update_free_access to TRUE

→ Add (for troubleshooting purposes)---

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
$conf['error_level'] = 2;

Save and quit; let's navigate to the portal and see what's up:

Nice! we are not going to login... instead, we will do the Drupal update process:

And we get:

Something is wrong........... must be the conf file....

So prior to making any changes to the conf file, let's back it up:

Let's open-up the prep conf file...

Sure enough... the AuthType is there and it shouldn't...

Here's how it should be:

Save and quit and then give Apache a boot...

Let's access the Drupal's update process—

Much better:

Let's create a user using phpMyAdmin---

Look at the settings file for the needed info—

Let's refresh Firefox and see what we get...

MUCH BETTER! Before following-through with the update process, let's update CAS and LDAP related modules and then re-load the Drupal's update process...

Okay...

We have encountered rules module related error before... so before we move onto the Front page, let's update the rules module and then re-run the Drupal's update process...