- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello. We are running 81.20 HF76 and I have 3600 units that are seeing disk space issues. When I look in var/log I see old version from R81 and R81.10 taking up a lot of space.
CheckPoint#CPUpdates#All#6.0#5#2#BUNDLE_R81_JUMBO_HF_MAIN#65
CheckPoint#CPUpdates#All#6.0#5#3#BUNDLE_R81_10_JUMBO_HF_MAIN#110
CheckPoint#CPUpdates#All#6.0#5#3#BUNDLE_R81_10_JUMBO_HF_MAIN#130
The folder also has the HF bundles for R81.20.
Can I just delete these manually or is there a command to clean up old HF bundles? I don't want to brick the gateway by deleting a necessary file.
TAC said I could but I am wondering if there is a better way to do this and just using a rm -r command. They don't show up in the GAIA CPUSE section.
The SK they pointed me at didn't seem to apply to these files, but old log files.
Thanks.
TL;DR: Be careful when manually deleting packages in /var/log/CPda! You might not want to do this without careful consideration.
If these are jumbo hotfixes you've downloaded, but not yet installed, you can delete them in CLISH with "installer delete <tab>" for an auto-complete list of options.
However, if these are jumbo hotfixes you've installed in sequence, be aware that if you delete the packages manually in /var/log/CPda, you will no longer be able to uninstall the current hotfix bundle and restore to previous versions! A dependency chain is created each time you install a new jumbo hotfix after another.
If you have installed several of these over time, they can consume a lot of disk space. The only remedy is to get a full backup of your configuration and either re-install with the current version and start a new dependency chain with the latest hotfix. If you do a major version upgrade, such as from R81.20 to R82, this also starts a new dependency chain from R82. In this case, you can safely delete all of the older packages in /var/log/CPda.
When doing a full version upgrade, such as with the Blink images, the new OS is installed to a new LVM logical volume and the prior one is saved for a restore. If you don't need this older version anymore, you can delete that logical volume and reclaim that space into the volume group. You can delete this older volume with the CLISH command "delete snapshot <tab>" to see the options.
Do you see these old packages while trying to delete them using CLI installer? This should be the way to delete old packages:
> installer delete package <TAB>
Thanks. I spoke to TAC again and he said I could just rm them from the CLI in expert mode. I deleted the tgz files but the directory those were in are still there. I was looking for something like Cisco's remove inactive command to delete old packages, bin files, and configs that were no longer active. I will check out the command you listed.
TL;DR: Be careful when manually deleting packages in /var/log/CPda! You might not want to do this without careful consideration.
If these are jumbo hotfixes you've downloaded, but not yet installed, you can delete them in CLISH with "installer delete <tab>" for an auto-complete list of options.
However, if these are jumbo hotfixes you've installed in sequence, be aware that if you delete the packages manually in /var/log/CPda, you will no longer be able to uninstall the current hotfix bundle and restore to previous versions! A dependency chain is created each time you install a new jumbo hotfix after another.
If you have installed several of these over time, they can consume a lot of disk space. The only remedy is to get a full backup of your configuration and either re-install with the current version and start a new dependency chain with the latest hotfix. If you do a major version upgrade, such as from R81.20 to R82, this also starts a new dependency chain from R82. In this case, you can safely delete all of the older packages in /var/log/CPda.
When doing a full version upgrade, such as with the Blink images, the new OS is installed to a new LVM logical volume and the prior one is saved for a restore. If you don't need this older version anymore, you can delete that logical volume and reclaim that space into the volume group. You can delete this older volume with the CLISH command "delete snapshot <tab>" to see the options.
The headache is when you upgrade, all the old jumbos are left sitting there with no way to tell CPUSE to delete them. 'installer delete' only shows major versions you aren't running, and other packages for the version you are running. I have some firewalls running R81.20 with jumbos in /var/log/CPda/repository from R81.10, R80.40, R80.30, even R80.20. The old stuff no longer shows up in 'installer' commands, so it just clutters up lv_log for no good reason.
It has always been my understanding that as long as you're sure you will never revert to the old version (i.e, you have deleted the old snapshots), it's safe to manually delete jumbos for old versions you aren't running.
Yeah, totally agree! It's a pain that there's no "feel good" way to trash all those. I end up doing a "find /var/log/CPda -name '*R80*' -exec rm -v {} \;", etc. for whatever I don't want anymore. Otherwise, a total re-install from source media is the only other way to do it and "feel good" about it.
Yes, I am running into space issues due to old Jumbos just sitting there taking up GB of space. I'm surprised this has not been addressed. I keep seeing Threat Extraction shut off due to lack of disc space and having to hunt around for files to delete is not an ideal solution.
Thanks for the input!
So if I'm on R81.20 HF 99 can I delete this file?
installer delete package
** ************************************************************************* **
** Majors **
** ************************************************************************* **
Num Display name Type
1 R81.10 Gaia Fresh Install and upgrade Major Version
Also I see cpview_services.dat files for older versions.
-rw-r----- 1 admin root 804726784 Sep 12 2023 /var/log/opt/CPshrd-R81/cpview_services/cpview_services.dat
-rw-r----- 1 admin root 948372480 Jul 18 2024 /var/log/opt/CPshrd-R81.10/cpview_services/cpview_services.dat
If the R81.20 package is deletable (looks like it is), then yep, you can delete it safely.
Likewise, if you don't want the CPview data from that far back in time, you can delete it too. Make sure $CPDIR/cpview_services directory doesn't have a symlink to those files, either.
Just make sure NOT to delete anything from dir LastTake, as that would prevent install of new jumbos.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 18 | |
| 15 | |
| 13 | |
| 12 | |
| 10 | |
| 6 | |
| 5 | |
| 5 | |
| 4 |
Thu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY