R77.30 to R80.10 upgrade issue

[Pedro_Boavida]

Hi,

I'm trying to upgrade Management from R77.30 (with Add-on package) to R80.10.

I have a fresh installed R80.10 management and I'm trying to do a migrate import of the file exported from the original management with R80.10 pre-80 upgrade tool. 

This procedure fails in the "Importing files..." step. The error produced in the migration log looks like this:

(...)

[21 Jun 17:45:11] [DbUpgrader::ExecuteCpdb] Executing cpdb using the following arguments: "/opt/CPsuite-R80/fw1/bin/cpdb" up --no-ngm-db-drop --no-ngm-stop --src_version 6.0.4.0 --src_hfa_level 30 --src_path "/opt/CPsuite-R80/fw1/tmp/migrate/main_db/" --db_path "/opt/CPsuite-R80/fw1/conf/" --default_path "/opt/CPsuite-R80/fw1/conf/defaultDatabase" --db_type regular --db-migration
[21 Jun 17:45:11] [runShellCommand] Executing command: '"/opt/CPsuite-R80/fw1/bin/cpdb" up --no-ngm-db-drop --no-ngm-stop --src_version 6.0.4.0 --src_hfa_level 30 --src_path "/opt/CPsuite-R80/fw1/tmp/migrate/main_db/" --db_path "/opt/CPsuite-R80/fw1/conf/" --default_path "/opt/CPsuite-R80/fw1/conf/defaultDatabase" --db_type regular --db-migration'
[21 Jun 17:49:53] [runShellCommand] Execution result: 1, exit code: -1
[21 Jun 17:49:53] [DbUpgrader::ExecuteCpdb] ERR: cpdb completed with error code '-1'
[21 Jun 17:49:53] ..<-- DbUpgrader::ExecuteCpdb
[21 Jun 17:49:53] .<-- DbUpgrader::UpgradeMainDatabase
[21 Jun 17:49:53] [DbUpgrader::exec] ERR: Failed to upgrade main database
[21 Jun 17:49:53] <-- DbUpgrader::exec
[21 Jun 17:49:53] [ActivitiesManager::exec] ERR: Activity 'DbUpgrader' failed
[21 Jun 17:49:53] [ActivitiesManager::exec] WRN: Activities execution finished with errors
[21 Jun 17:49:53] [ActivitiesManager::exec] WRN: Activities 'DbUpgrader' have failed
[21 Jun 17:49:53] [ActivitiesManager::exec] Designated exit code is 1

(...)

The Pre-Upgrade Verifier tool reported several "Warnings" but they were all solved. At this point I only have one "Information" produced by this tool related to LTE gtp_v2_default unsupported service which is actually not used at all but I cannot remove it by any means. I tried the solution provided in sk117237 however I still got that reported by the tool.

Did anyone been through something like this ?

Cheers!

[PhoneBoy]

We probably need the entire output of the migrate import to see what it's actually failing on.

I also recommend engaging with the TAC.

[Pedro_Boavida]

Hi Dameon,

Thanks for your help. 

The entire migration log file is to big to paste here and it doesn't have any other errors.

However I'm engaged with TAC and hopefully I will share the results soon. Just wondering if someone ever been through this.

Regards,

[PhoneBoy]

FYI, the GTP_v2_default service should be removed by the upgrade process, so I'm not sure that's the issue.

The lack of an obvious error message is definitely concerning.

[Prabulingam_N1]

Dear Pedro,

Try and remove these services which were already in R77.30 Dashboard_Services.

gtp_additional_v2_default, gtp_mm_v2_default, etc (serach by GTP in services column - you can find few more)

Before deleting these service please note down the ports being used. so that once R80.10 is done you can create those again.

Regards, Prabulingam.N

[Pedro_Boavida]

Hi Prabulingam,

Like I told, one cannot remove this service, neither through SmartDashboard nor Guidbedit. You can try it....

However, I don't think should be the problem. It's only informational statement and the script tells you that it will be removed on the upgrade process:

Information:
============

Title: LTE Services are not supported yet
-----
* Description: Database contains LTE services that are not yet supported in R80.10

These LTE services will be deleted during the upgrade to R80.10:

Unsupported LTE services are:
gtp_v2_default

Regards,

Pedro Boavida

[SD_Networking]

Hello Pedro,

did you resolve the issue, I am also hitting same issue, opened a TAC Case now.

Regards,

Yasir

[Pedro_Boavida]

Hi,

Still not solved because several issues had been found.... R&D is looking into it.

However I'd recommend you to take a look into the the $FWDIR/log/cpm_for_cpdb-YYYY-MM-DD-HH-MM-SS.ELG. It contains more detailed messages and you might figure what is the problem.

Regards,

PB

[SD_Networking]

For me R&D was quick, they found issue in license file and resolved it,

I have migrated to R80.10.

[PhoneBoy]

Was it just an invalid license or something else?

[Pedro_Boavida]

Finally I've got the problem solved. Some low-level corrections had to be done on R77.30 database before importing to R80.10.

Like I told previously the file $FWDIR/log/cpm_for_cpdb-YYYY-MM-DD-HH-MM-SS.ELG is very important as it points to details.

1) In this case there were syntax errors ( double brackets '}}' ) on a couple of files, namely sem_event_views.C and sem_views_collections.C. Solution is to correct the syntax by eliminating the redundant bracket.

2) Also there were some null references on some objects of anti_malware_rulebase_rules table. One can either try to delete those objects (through guidbedit) or recreate the antimalware policy from scratch on smartdashboard, whatever suits best.

3) However, after that I also needed to run a script (CleanMalformedEntities.sh) as per sk117167.

Et voilá ! It worked. I must thank TAC for the support provided.

Just one last remark:

I've been doing several R80.10 upgrades recently and I've been successful and autonomous in almost everyone (>90%).

Regardless of that, I must say that the problems encountered here were not manually induced by humans and I must say that the upgrade process / verification tools should take care of it, and therefore it should improved.

I guess/suspect this might been caused by very old databases that were subject to several upgrades along the way. 

Regards,

PB

[PhoneBoy]

Part of the reason we have the R80.x Validation Service is to ensure the upgrade process runs smoothly.

And yes, that means using the findings to improve the automatic parts of the upgrade process.

Your feedback is definitely appreciated.

[Martijn]

Hi All,

I have the same issue, but I am importing the R77.30 database in a Domain Server on a R80.10 Multi Domain Server.

Also get the error: Failed to upgrade main database.

Already performed several procedures I got from support and the knowledge base, but no luck.

This also is a database which has been upgraded in the last couple of years from previous versions.

The customer I am working for at the moment does not allow for information to leave the company, so cpinfo files, log files cannot ben send to Check Point support. And the Validation Service cannot be used.

So any tips and tricks are very welcome.

In MDM the file $FWDIR/log/cpm_for_cpdb-YYYY-MM-DD-HH-MM-SS.ELG is not there. The file $FWDIR/log/upgrade_log-YYYY-MM-DD-HH-MM-SS.ELG is. Is this the same file?

Regards,

Martijn.

[PhoneBoy]

It's a different file, but should contain similar information.

[Martijn]

Hi,

This is what I see in the upgrade log file. Any idea?

[24150 4084520720]@MDSSRV[11 Aug 14:07:15] [CUpgCPMIInterface::Save] ERROR: Failed to update some of the tables. The resulting DB will be corrupted.

[24150 4084520720]@MDSSRV[11 Aug 14:07:15] [CUpgradeMgr::PerformCPMIUpdate] WARNING: Failed to save the DB.

[24150 4084520720]@MDSSRV[11 Aug 14:07:17] [CUpgradeMgr::PerformUpgrade] ERROR: Failed to perform cpmi update

[24150 4084520720]@MDSSRV[11 Aug 14:07:17] [writeUpgradeResult] The path to result file is: '/opt/CPmds-R80/customers/CMA/CPsuite-R80/fw1/log/upgrade_result'

[24150 4084520720]@MDSSRV[11 Aug 14:07:17] [writeUpgradeResult] Wrote the following to the result file: '80004005'

[24150 4084520720]@MDSSRV[11 Aug 14:07:17] [CCPDBMain::Run] cpdb ended with result '0x80004005' (Unspecified error).

[24150 4084520720]@MDSSRV[11 Aug 14:07:44] [main] FATAL ERROR: Operation failed.

The R80.10 upgrade guide from May 2017 tells me you cannot migrate from a R80.10 SmartCenter to a R80.10 Domain Server. Is this still the case?

The reason I am asking is: Importing the R77.30 SmartCenter database in a R80.10 SmartCenter is succesfull. It only fails when I am importing the R77.30 database in a R80.10 Domain Server on MDM using the cma_migrate tool.

Regards,
Martijn

[PhoneBoy]

SKs that mention this error suggest a file is corrupted.

May need to go several lines back in the log output to see what file that is.

Have you opened a TAC SR on this by chance?