- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Failed to upgrade from SmartConsole
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Failed to upgrade from SmartConsole
Hi,
I want to use the central upgrade for the first time in SmartConsole. The upgrade will be from R81.10 to R81.20 lates HFA
In SmartConsole when choosing a Gateway > Actions > Upgrade Version I have the following error
Failed to search for package Blink_image_1.1_Check_Point_R81.20_T631_JHF_T41_SecurityGateway.tgz on the Check Point Download Center. Reason: Unknown Error.
I then tried to import a package in the repository from cloud and get the following error
I've internet connectivity from the Management & SmartConsole: https://support.checkpoint.com/results/sk/sk83520
How can I troubleshoot the package download ? Is this download initiated by the Management ou the SmartConsole ?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
First of all "Unknown error" is never a good option so once we get the logs I'll try to find the best error that should be issued.
Secondly regarding your question - on your first attempt the Smart Console "asks" the Gateway to install the recommended package so the Gateway tries to download the package from the cloud and fails.
The second attempt was to download to the repository which is placed on the Management machine so the Management is initiating this action (and not the Smart Console)
To solve it I will appreciate if you can run (expert mode on Management machine) "collect_logs.bash" and send me the resulted tgz file to boazo@checkpoint.com
As a work around you can download the package from the SK and then upload it to the Package Repository locally
Thanks
Boaz
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you ! Sent via email
Unfortunately it means that with this Workaround all GW will download the file from the Management. We would prefer from cloud for performance reason (65 GW to upgrade)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I know there would be lots of people who will disagree with what I will say, but personally, I NEVER do any upgrades from smart console. I find its very unreliable (based on my lab tests) and doing it old school way from web GUI is what I always stick with and works totally fine.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Andy,
Can you list the "old school way" steps regarding cluster upgrade? Specifically hotfix patching?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Super easy. ALWAYS do these steps on whichever one is backup member first, which can be verified by cphaprob state or cphaprob roles commands.
-log into web UI, status and actions, confirm right jumbo
-right click, verify
-if all green, just hit install
-wait until reoots, run cphaprob state to make sure it still shows backup and and also cpinfo -y fw1 to confirm new jumbo
-do same steps on master, and once rebooted, it would show as backup member and to fail back (if you like), run clusterXL_admin down; clusterXL_admin up on first member (original backup)
-install policy
Thats it 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the comment.
Regarding the last step, I run both clusterXL_admin commands on the original backup? Or do I need to run admin_down on the original backup and admin_up on the original active?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You do it EXACTLY how I did it below (from my lab example) and if you get worried/concerned/confused or all 3, ping me and we can do remote.
Andy
****************************************************
Send automatic password
Access denied
admin@172.16.10.247's password:
Last login: Tue Jul 2 10:07:02 2024 from 100.65.16.1
[Expert@CP-FW-02:0]# cphaprob roles
ID Role
1 Non-Master
2 (local) Master
[Expert@CP-FW-02:0]# cphaprob state
Cluster Mode: High Availability (Active Up) with IGMP Membership
ID Unique Address Assigned Load State Name
1 169.254.0.112 0% STANDBY CP-FW-01
2 (local) 169.254.0.111 100% ACTIVE CP-FW-02
Active PNOTEs: None
Last member state change event:
Event Code: CLUS-114904
State change: ACTIVE(!) -> ACTIVE
Reason for state change: Reason for ACTIVE! alert has been resolved
Event time: Mon Jul 1 17:15:47 2024
Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: ADMIN_DOWN PNOTE
Event time: Mon Jul 1 16:47:00 2024
Cluster failover count:
Failover counter: 3
Time of counter reset: Thu Jun 27 20:23:48 2024 (reboot)
[Expert@CP-FW-02:0]# clusterXL_admin down;clusterXL_admin up
This command does not survive reboot. To make the change permanent, run either the 'set cluster member admin {down|up} permanent' command in Gaia Clish, or the 'clusterXL_admin {down|up} -p' command in Expert mode
Setting member to administratively down state ...
Member current state is DOWN
This command does not survive reboot. To make the change permanent, run either the 'set cluster member admin {down|up} permanent' command in Gaia Clish, or the 'clusterXL_admin {down|up} -p' command in Expert mode
Setting member to normal operation ...
Member current state is STANDBY
[Expert@CP-FW-02:0]# cphaprob state
Cluster Mode: High Availability (Active Up) with IGMP Membership
ID Unique Address Assigned Load State Name
1 169.254.0.112 100% ACTIVE CP-FW-01
2 (local) 169.254.0.111 0% STANDBY CP-FW-02
Active PNOTEs: None
Last member state change event:
Event Code: CLUS-114802
State change: DOWN -> STANDBY
Reason for state change: There is already an ACTIVE member in the cluster (member 1)
Event time: Wed Jul 3 08:35:00 2024
Last cluster failover event:
Transition to new ACTIVE: Member 2 -> Member 1
Reason: ADMIN_DOWN PNOTE
Event time: Wed Jul 3 08:34:59 2024
Cluster failover count:
Failover counter: 4
Time of counter reset: Thu Jun 27 20:23:48 2024 (reboot)
[Expert@CP-FW-02:0]#
*****************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot for this. I now got it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did it work?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did the upgrade using SmartConsole, but I used your example in order to failover back to the original active member. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good job!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any updates on this? I have the same issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recently used this method for jumbo update on R81.20 and was fine. Whats version you are upgrading from and to?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R81.10 Take 130 to R81.10 Take 139
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that CPUSE might provide more detailed error. Perhaps you can use it on a single GW and use verify on the package. If you have a lot of GWs this worth a shot.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Upgrade via SmartConsole finally worked with R81.10 Take 150 and SmartConsole 81.10.9600.423 as a basis.
And I don´t think there were related changes within our Checkpoint environment but I also didn´t notice anything specific in the changelogs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will say,my memory at 45 is not nearly as good as when I was 25 (lol), but Im fairly sure I had seen the post on here before where someone mentioned update to smart console would roll out based on the regions, but in R81.20, I would get an option to update same day it showed as released.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there any update to this topic? I´ve got exactly the same error when i try to download the Blink R81.20 T92 image. Everytime i get an unkwon error.
If i try to download a "normal" JHF package, i get the same error. If i download it directly with Gaia WebGUI and CPUSE, it works with no problems...
i have to upgrade about 35 clusters... manually it would take ages..