Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
AaronW
Participant
Jump to solution

Old version HF bundles taking up disk space, best way to remove?

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. 

1 Solution

Accepted Solutions
Duane_Toler
MVP Silver
MVP Silver

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.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack

View solution in original post

9 Replies
JozkoMrkvicka
Authority
Authority

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>

Kind regards,
Jozko Mrkvicka
AaronW
Participant

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. 

0 Kudos
Duane_Toler
MVP Silver
MVP Silver

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.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
Bob_Zimmerman
MVP Gold
MVP Gold

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.

Duane_Toler
MVP Silver
MVP Silver

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.

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
AaronW
Participant

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!

AaronW
Participant

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

0 Kudos
Duane_Toler
MVP Silver
MVP Silver

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.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
the_rock
MVP Gold
MVP Gold

Just make sure NOT to delete anything from dir LastTake, as that would prevent install of new jumbos.

Andy

Best,
Andy

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events