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.