Upgrade Reporter Progress (R80.30->R80.40 Standalone) - Stuck on Importing IPS Data ...

[Jerry]

hi chaps

got an interesting one,

I've attempted yesterday to migrate two R80.30 Standalone to R80.40 via CPUSE

one of the boxes (single appliance not VM) got stuck on Importing IPS Data ... and won't move since literally 24h.

I've tried everything except interception, I've rebooted the box, same thing, I've made cpstop's etc. - same thing

any ideas? I'd like this upgrade to finish but it has stuck on IPS whilst all other things has been processed already.

[Jerry]

also constant pop-up message when accessing WebUI:

"Upgrade is still running. Log in to the Status and Actions page to see the progress."

any idea guys how to "push" that upgrade forward and stop IPS Import ... ?

[Jerry]

Importing the Management Database
Operation started at Tue Jun 2 11:13:45 BST 2020

[==================> ] 36% Importing IPS Data ... \
Upgrade progress information is available at /opt/CPsuite-R80.40/fw1/log/upgrade_report-2020.06.02_11.57.02.html

[Youssef_Obeidal]

Hi,

My name is Youssef, and I am the team leader of Threat Prevention on the Management

We would like to collect upgrade logs to see why the upgrade stuck.

Please send me the following logs: /var/log/upgrade-export*.tgz & /var/log/upgrade-import.*tgz  to youssefob@checkpoint.com

[Jerry]

[Expert@cp:0]# /var/log/upgrade-export*.tgz & /var/log/upgrade-import.*tgz
[1] 27533
-bash: /var/log/upgrade-export*.tgz: No such file or directory
-bash: /var/log/upgrade-import.*tgz: No such file or directory
[1]+ Exit 127 /var/log/upgrade-export*.tgz

[Youssef_Obeidal]

From today's session, we see that there is a disk space issue that causes the import to fail why extracting the IPS packages during the import.

The instruction was to revert to R80.30, make more disk space before the upgrade, and to perform it again.

In addition, we asked for the exported.tgz database, so we can also perform the import in our LAB, to see that there are no issues.

[Jerry]

yup. thanks guys, I found the problem and it wasn't df -ahl (disk space) but instead it was CPUSE obsolete old migration files on the flash which causes the obstructive behavious of devices heading towards R80.40. I'm gonna make this weekend my housekeeping on the appliances and attempt advance migration via TGZ rather than CPUSE and update you due course. So far so good! thanks for all your time and effort - I really do appreciate that 🙂

Cheers

J.

[Boaz_Orshav]

Hi

  My name is Boaz and I am the Team Leader responsible of CPUSE.

  Can you please clarify what you mean by "CPUSE obsolete old migration files on the flash"?

Thanks

Boaz

[Jerry]

hi Boaz, thanks for your remark, let me clarify what I meant exactly.

Device(s) in question were in the past multiply times "upgraded" starting from R80.10, via R80.20 towards R80.30, before attempted recently with R80.40. What does it mean, it means that with no clean-up done on the internal flash (rather HDD) the whole migration processes left many obsolete and no longer necessary files. Now I have cleaned them up (it took me few long minutes) but before attempted R80.40 2 days ago all these files were literally obstructing log partition as well as some of the /usr nested folders. This is what I meant only and sorry for the confusion. I'm going to make advance upgrade shortly and let you all know due course if CPUSE is on the table again or rather migrate_export is the only possible path. IMHO CPUSE should work with the CPUSE TGZ. package.

[genisis__]

If you have out of band access and can mount an ISO, really suggest a clean R80.40 build and then import.

[Patrick_Gahan]

exact same issue here 

R80.30 --> R80.40 .. stuck at 36% Importing IPS Data ... 

..indefinitely it seems. I note that sduuGo process seems to run very high CPU on one core, and gets stuck (or at least stuck for a period, then stops, then tries again) - i've read this process relates to IPS updates. The target appliance has no internet access so i wonder if that is the reason... lsof -p <sduuGo_PID> shows the below ...same list of temp files on every attempt.

R80.40 tools package ngm_upgrade_wrapper_994000389_1

sduuGo  5365 admin    9r   REG              253,0   8333487  52284995 /home/admin/temp-export/a0bbbc99-adef-4ef8-bb6d-cebcebcebceb/ips_package.temp/sd_updates_vpn1_dir/object_updates_634.C

sduuGo  5365 admin   10r   REG              253,0   3893279  52284993 /home/admin/temp-export/a0bbbc99-adef-4ef8-bb6d-cebcebcebceb/ips_package.temp/sd_updates_vpn1_dir/object_updates_618.C

sduuGo  5365 admin   11r   REG              253,0   3798663  52284994 /home/admin/temp-export/a0bbbc99-adef-4ef8-bb6d-cebcebcebceb/ips_package.temp/sd_updates_vpn1_dir/object_updates_632.C

sduuGo  5365 admin   12r   REG              253,0   7540590  52284996 /home/admin/temp-export/a0bbbc99-adef-4ef8-bb6d-cebcebcebceb/ips_package.temp/sd_updates_vpn1_dir/object_updates_635.C

[Dimitris_Androu]

Hi I have the same problem when upgrading from r80.40 to r81.

Upgrade is still running. Log in to the Status and Actions page to see the progress.

[Obiwan1968]

I got the same problem as Jerry above, TAC told me that 4GB of MEM is not enought, therefore the problem. Altought a pre-verifier is checking the system before upgrade, it tried from 80.30 to 80.40 knowing that 4GB is not enought? BTW, even 80.30 should not run on a 4400 appliance with 4GB. Also the 4400 is not possible to upgrade to 8GB, so  buying a new appliance is the idea.

[Swordfish]

At first, I thought we would face the same issue today during the cpuse management upgrade from R80.30 to R80.40, because the IPS Data import took quite a while and we saw also high CPU utilization by sduuGo process.

The IPS data import finally took 26 minutes, which was the longest step in the complete upgrade process. So if you are nervous right now because you are impatient as I was – maybe just give it a bit more time 🙂