I have performed R75.10 to R75.20 upgrade on UTM 27x yesterday for one of my customers. It was not smooth.
The customer has a "classic" UTM cluster: both MGMT HA and FW ClusterXL HA are configured.
The upgrade went smooth on the secondary node, but failed on the primary one.
Short troubleshooting has shown it failed because of lack of free space on the main partition. I have mentined several disturbing issues:
1. HD space is apparently not monitored.
Root partition only contains binaries and configuration files. On this particular system HD is partitioned to provide around 10 GB for root partition and around 80 GB for /var/opt/log one. In our case root was used for at least 70%, and in the middle of DB conversion it jumped to 100%. Apparently you should have this partition used for not more then 50-60% to succeed with upgrade to R75.20. It does not seem that the upgrade script monitors this particular part of the hard drive at all.
2. Upgrade script does report cause of the failure.
The appliance can only be upgraded via WebUI. You cannot even un-cjeck safe upgrade option. If failed, it automatically reverts to the pre-upgrade image, and there are no logs left to see what went wrong.
This issue is quite similar to IPSO flash based upgrade troubles, which is bad considering that IPSO usually fails an upgrade with 1 GB flash but succeeds with 2 GB. Come one, Check Point, how comes you need 3-4 GB of free space on the main partition to upgrade a standalone UTM system? That should not be right.
The log should be at /var/log/CPupgrade.elg. Quite cryptic however.
ReplyDelete