Keeping up with HFA installs would fill up lv_current

[Adam276]

With R81.20 after you install an HFA, it is kept on the lv_current partition.  If you were to update even every other HFA, that would start filling up your lv_current partition and stop you eventually from updating anymore without a resize of the partitions or exporting the management and installing it new.  I have seen mentions that you need to keep the previously installed HFAs on the management and the ability to remove them from Gaia web interface was disabled at some point.

While certainly it makes sense you would need them if you need to revert to an older HFA, but I have read some conflicting information mentioning that they are needed for future upgrades (not sure if that means future HFAs also).

There were around 47 HFA releases over the supported lifetime of R80.40 for example., That would be a problem if you wanted to install every HFA.  A have seen management take about 29 GB on the lv_current partition with only 2 HFAs installed.  It appears to take around 1.2 to 1.5 GB for every HFA install to be kept.  That would come out to be 54 GB (using 1.2GB per)  of just HFAs that were kept on the server if you upgraded to every HFA.  that would push the lv_current partition even bigger (83GB) than what the maximum is supported (68 GB if I recall correctly).  That is of course an extreme case, but with upgrades mentioning you should have 20 GB free, space can easily be used up quickly even with only a dozen of them installed.  Most default installs that I have done on open platform have defaulted to about 35GB for the lv_current partitions BTW.

How are people managing this now with newer versions?  At least with R81.20, It appears the ability to remove already installed HFAs in the Gaia web UI has been disabled.

My questions...

1. Is it required to keep all HFAs that have been installed on the system?

1a. If yes then how can we manage the space that would consume over time with many HFAs installed?

1b. If no then why was the ability to delete already installed HFAs removed from Gaia web UI?

Is there an article  I have missed that explains how to manage already installed HFAs?  It would be great to have an official article on it otherwise.  I am hoping the answer is not that they are all required and people that update every HFA will just have to export/import into another management at some point in time.

I specified Management forum but this would apply for gateways too at some point if enough HFAs are installed.

[the_rock]

1. Is it required to keep all HFAs that have been installed on the system? No

1a. If yes then how can we manage the space that would consume over time with many HFAs installed? not applicable

1b. If no then why was the ability to delete already installed HFAs removed from Gaia UI? No idea

P.S Just MAKE SURE NOT to delete anything from dir /Last Take, as that would prevent install of new jumbo fixes.

[Adam276]

I will try to find the article that states the opposite of that and says removing previous HFAs can impact being able to upgrade.  I found it the other day so should be able to find it again.

If the article is incorrect though and it is safe to delete older already installed HFAs and not impact future upgrades or HFA installs, then it would seem then that there should be a UI way to handle this over time (like there was before) instead of needing to find specific files to delete inside HFA update directories which could be problematic.

The fact that it was disabled in the Gaia web UI would seem to indicate that it was on purpose which would go along with the article that mentions that removing them can impact upgrades.

[Lesley]

Average life time of hardware is 5 years. New hardware means clean install. I would recommended to clean install after major upgrade. For example from R81.20 towards R82. We keep track when last clean install has been done. After some time so many changes are done on the system, old files, old captures etc etc it is better to have a fresh start. 

What you can do, is not remove the old JHF dir but only cut and paste them on local desktop. If CPuse complains about missing older versions you put them back. As far as I know you do not need all old JHFs only 1 previous one and you are good. 

Second option is to extend the space with lvm_manager if space is really getting an issue. 

[Lesley]

https://support.checkpoint.com/results/sk/sk60080

1. Remove previous Takes of Jumbo Hotfix Accumulator from CPUSE repository.

   Note: This suggestion applies to Jumbo Hotfix Accumulators mentioned in sk98028.

   1. Connect to the Gaia Portal and obtain the lock over the configuration database.

   2. Navigate to "Upgrades (CPUSE)" pane > click on "Status and Actions".

   3. Use the filter button near the help icon and select the "Installed" packages.

   4. Select the previous Take of Jumbo Hotfix Accumulator - on the toolbar, click on "More" button - click on "Delete From Disk".

      Also: https://support.checkpoint.com/results/sk/sk183770

[Adam276]

Yea, As I mentioned, That article doesn't apply anymore as they seemed to remove that from the Gaia web UI.  There is no more... delete from disk.  It appears they removed that feature.

[the_rock]

If you have an sk, please share it. Personally, I had done this probably 100 times and never had an issue.

[Bob_Zimmerman]

Jumbos aren't kept in lv_current, they're kept in lv_log (/var/log/CPda/repository). If your lv_current is going up by a gigabyte per jumbo, something is wrong with your system. That's not normal at all.

That said, agreed there should be better cleanup options for CPUSE packages.

Edit: Also, lv_current can be much bigger than 68 GB. I have a bunch of MDSs which shipped with 200 GB lv_current by default. The only real limit is that snapshots start at the full size of lv_current, then squeeze down, so if you don't have at least lv_current's limit in free space, you may not be able to take a snapshot or upgrade in place.

[Adam276]

EDIT: I forgot to mention this is for OpenPlatform if that matters.

There are backups of installed JHFA stored in /opt/CPda/backup/ which is on lv_current.

I just checked the /opt/CPda/backups/ directory on 2 different managements and for the directories there.

/opt/CPda/backup
CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#118
CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92

Both have a LastTake directoy which is about 1.2GB each.

The lastest installed one also has a Completely directory that is 1.2GB.

The LastTake are part of the problem.

[Expert@FW-MGMT:0]# pwd
/opt/CPda
[Expert@FW-MGMT:0]# du -h backup/
1.2G    backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#118/LastTake
1.2G    backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#118/Completely
2.4G    backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#118
1.2G    backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92/LastTake
1.2G    backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92
3.5G    backup/

So when I installed JHFA 118, the lv_current disk space went down by a few GB for the new directory under /opt/CPda/backup/

[Lesley]

mv -> CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92 to outside firewall and try upgrade :d 

You could also try, CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#118 but would not recommend i think this is needed if installation fails and systems does rollback

[Bob_Zimmerman · Accepted solution]

Only two are kept there. Since upgrading in-place to R81.20, this firewall has been updated to jumbo 41, 76, 92, and 105:

[Expert@SomeFirewall-1:0]# egrep "(Initiating install of Check Point Security Gateway R81.20 R81_20_JUMBO_HF_MAIN|R81_20_JUMBO.+was successfully imported)" /opt/CPInstLog/DA_UI.log
[2024-01-11 - 00:43:37]: <b>The package Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T41_FULL.tgz was successfully imported.</b><br><br>If the package is not visible - make sure that all the packages categories are expanded.
[2024-01-11 - 00:44:31]: Initiating install of Check Point Security Gateway R81.20 R81_20_JUMBO_HF_MAIN
[2024-09-16 - 05:41:04]: <b>The package Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T76_FULL.tgz was successfully imported.</b><br><br>If the package is not visible - make sure that all the packages categories are expanded.
[2024-09-16 - 05:42:45]: Initiating install of Check Point Security Gateway R81.20 R81_20_JUMBO_HF_MAIN
[2025-02-12 - 23:12:48]: <b>The package Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T92_FULL.tgz was successfully imported.</b><br><br>If the package is not visible - make sure that all the packages categories are expanded.
[2025-02-13 - 00:12:59]: Initiating install of Check Point Security Gateway R81.20 R81_20_JUMBO_HF_MAIN
[2025-09-10 - 12:16:38]: <b>The package Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T105_FULL.tgz was successfully imported.</b><br><br>If the package is not visible - make sure that all the packages categories are expanded.
[2025-09-15 - 02:24:02]: Initiating install of Check Point Security Gateway R81.20 R81_20_JUMBO_HF_MAIN
[Expert@SomeFirewall-1:0]# du -h /opt/CPda/backup/
761M	/opt/CPda/backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92/LastTake
761M	/opt/CPda/backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#92
865M	/opt/CPda/backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#105/LastTake
852M	/opt/CPda/backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#105/Completely
1.7G	/opt/CPda/backup/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#105
2.5G	/opt/CPda/backup/
[Expert@SomeFirewall-1:0]# 

I don't have any R80.40, R81, or R81.10 firewalls left to check, but my lab R82 boxes have been through every single released jumbo (I update them within a day of the jumbo being released so I can test), and they also only have two directories for jumbos in /opt/CPda/backup.

[Adam276]

Thanks.  That explains it and makes sense.  So I just need to worry about 2 on lv_current.  Thanks for checking your system.

I have plenty of space on the log partition so I don't care about that.

[Bob_Zimmerman]

It's certainly odd that this goes into lv_current at all, especially when there's a /var/log/CPda/backup directory as well. I thought the uninstallation files went there and /opt/CPda was a symlink to /var/log/CPda, but evidently I was mistaken.

Now, I do have the occasional problem of admins leaving CPUSE packages in /home after the jumbo has been imported. 😉 That definitely chews through lv_current and makes snapshots needlessly large.

[the_rock]

Yea, I found that super strange as well...

[Adam276]

I assume the reason for it is so that a snapshot will have previous install info in case you import the image into another freshly installed system.  It would have the needed data without relying on the logs directory.  Limiting it to only 2 seems like a good compromise.