migrate_server import issue: not proceeding past 4%

[Simon_Macpherso]

migrate_server import not proceeding past 4%

4% Importing server configuration ... \

migrating from r80.40 jhf take 49 to r81.10 jhf take 45

export from source management has been done with and without log indexes

--ignore_warnings flag was run with export command to bypass warning related to change in def files. 

Have checked sk176603 and verified all conditions

No errors in cpm.elg

Output of ps -aux | grep upgrade shows upgrade_client.sh is running

admin 7579 0.0 0.0 2644 576 pts/8 S+ 04:12 0:00 grep --color=auto upgrade
admin 16922 0.5 0.0 9151108 114740 ? SNLsl 03:15 0:20 /opt/CPshrd-R81.10/jre_64/bin/java -D_RFL=TRUE -Xdump:directory=/var/log/dump/usermode -Xdump:heap:events=gpf+user -Xdump:tool:none -Xdump:tool:events=gpf+abort+traceassert+corruptcache,priority=1,range=1..0,exec=javaCompress.sh RFL %pid -Xdump:tool:events=systhrow,filter=java/lang/OutOfMemoryError,priority=1,range=1..0,exec=javaCompress.sh RFL %pid -Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec=kill -9 %pid -Xaggressive -Xshareclasses:none -Xgc:scvTenureAge=1,noAdaptiveTenure -Xmx1024m -Xms96m -Dorg.terracotta.quartz.skipUpdateCheck=true -Dupgrade.cores.count= -Dfile.encoding=UTF-8 -DreportingServer.conf.dir=/opt/CPrt-R81.10/conf -Dlog4j.configuration=file:/opt/CPrt-R81.10/conf/rfl.log4j.properties -DReportingServer.log=/opt/CPrt-R81.10/log -cp /opt/CPrt-R81.10/jars/* com.checkpoint.core.LogCore -type jms
admin 36308 0.0 0.0 3768 1556 pts/2 T 03:20 0:00 /bin/sh /opt/CPsuite-R81.10/fw1/scripts/migrate_server import -skip_upgrade_tools_check -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz
admin 36316 0.0 0.0 4300 2196 pts/2 T 03:20 0:00 /bin/sh /opt/CPupgrade-tools-R81.10/scripts/upgrade_client.sh import -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz
admin 36869 0.0 0.0 3768 1560 pts/2 S 03:21 0:00 /bin/sh /opt/CPsuite-R81.10/fw1/scripts/migrate_server import -skip_upgrade_tools_check -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz
admin 36877 0.0 0.0 4300 2224 pts/2 S 03:21 0:00 /bin/sh /opt/CPupgrade-tools-R81.10/scripts/upgrade_client.sh import -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz
admin 37930 3.1 0.0 4300 1536 pts/2 S 03:25 1:28 /bin/sh /opt/CPupgrade-tools-R81.10/scripts/upgrade_client.sh import -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz
admin 41077 0.0 0.0 4300 1416 pts/2 S 03:26 0:01 /bin/sh /opt/CPupgrade-tools-R81.10/scripts/upgrade_client.sh import -v R81.10 /var/log/Export_for_Upgrade_from_R8040_to_R8110.tgz

TAC is open 

[Chris_Atkinson]

A similar case was recently discussed here:

https://community.checkpoint.com/t5/Management/migrate-server-import-stuck-on-4/m-p/146171

Are you using the latest upgrade tools from sk135172 i.e. ngm_upgrade_wrapper_996000398_1.tgz ?

[Simon_Macpherso]

Yes as mentioned all pre-requisite conditions are met per sk176603.

This includes deploying latest version of the upgrade tools to build 996000398 on both source and destination management servers.

We've since deployed a r81.10 build 335 base instance from an ISO in a lab and have been able to run a successful import. 

We have not tested an import with a new r81.10 build 335 instance built from ISO rolled up to JHF take 45. 

The target server that is failing to import was rebuilt via CPUSE R81.10 clean install. The server was rebuilt after a previous import which was successful. The server was originally built via a R81.10 clean install ISO from a USB. 

So the cause appears to be either

1) a server rebuilt with CPUSE R81.10 clean install, base or with JHF takes deployed.

2) GA JHF 45, or possibly even an earlier take. 

Based on testing so far, I suspect it's point 1. 

[Chris_Atkinson]

Thanks for sharing your experience, hopefully it is helpful for others.

[Simon_Macpherso]

So the question is why is this impacting R81.10 clean install builds deployed via CPUSE.

Our previous Diamond engineer informed us it would be fine to perform a clean install rebuild of the instance from CPUSE.  

Anyway, we have another TAC open for Checkpoint to replicate this in their lab and determine the cause. 

[Simon_Macpherso]

Update: the cause is not GA JHF 45

[Simon_Macpherso]

I can replicate this issue if I rebuild the server using the R81.10 CPUSE clean install tar image. 

So nothing wrong with

• source export
• importing to base
• importing to jhf 45
• latest build version of import tools

 We will have to use ISOmorphic or other option to rebuild the server with clean install ISO.