- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: R81.20 Azure CloudGuard management upgrade pac...
- 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
R81.20 Azure CloudGuard management upgrade package bug
R&D folks, you have another bug:
# da_cli get_status_of_action actionID=117
{
"Action ID" : "117",
"Action Type" : "Import",
"DAService State" : "ready",
"ExtendedMessage" : "N/A",
"Message" : "The following results are not compatible with the package:\n\n - Your partitions are not in Check Point standard format, and an upgrade is not possible. Reinstall your system and verify correct partitioning.\n\n\nThe upgrade package you have imported is supported only on AWS/Azure/GCP instances with a 64bit CPU",
"Package" : "aio_Check_Point_ivory_main_T631_R81.20_Gaia_3_10_Install_and_Upgrade.tar",
"Progress" : "0",
"Status" : "failure"
}
# fw ver
This is Check Point's software version R80.40 - Build 156
# cpinfo -y FW1 |grep Take
This is Check Point CPinfo Build 914000236 for GAIA
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 197
Azure CloudGuard:
# file /etc/waagent.conf
/etc/waagent.conf: ASCII English text
Standard Azure disk deployment, from marketplace template:
# parted -l |grep sd
Disk /dev/sda: 752GB
Disk /dev/sdb: 34.4GB
Management only, not a gateway:
# cpprod_util FwIsActiveManagement
1
# cpprod_util FwIsFirewallModule
0
I upgraded another customer from R80.40 to R81.20 in-place with Blink on their Azure CloudGuard SmartCenter and it worked just fine, as I expected. For this customer, the Blink package to do upgrade wasn't available (yes their software subscription is current), and I found sk177714 indicating I had to download a package manually (what?!). I downloaded the package, and did a local package import. That's when I got the above non-sensical error about incorrect partition format. 🙄
Anyone want to weigh in on this one?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will comment on the upgrade part, thats actually known that in place upgrade via blink image is not available yet for Azure environment. I confirmed this with PS folks, Sales, as well as TAC. You have to manually download the package from that sk and then upload to web UI.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like they're moving away from Blink to some other mechanism for CloudGuard in-place upgrade. I'm nearly-certain I did this for another CloudGuard customer of mine with Blink before it was taken away. Sadly, I don't think I can prove it, tho, but I was certain I had.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you 100%, because I did it too...ONLY once though and then poof, it was gone next day : - )
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did it in an alternate universe then jumped away again? 🙂 #MultiverseIsReal
As for the in-place upgrade here, tho, sk177714 "says" it's doable with the specific package via the link given for R80.40. Yeah, "they said"... 😕
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, I thought maybe I was having some sort of "gaslighting" scenario, so I took screenshots and my notes prove that in place upgrade happened, so no, I was not going crazy LOL
In place upgrade...I guess it depends how you define it haha. Sure, it is rechnically in place, but not using image thats there or getting it from the cloud, you still gotta upload it.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you remain stuck please contact TAC sighting the following SK:
sk180769: Upgrade to R81.20 on a Virtual Machine fails with "Your partitions are not in Check Point standard format, and an upgrade is not possible. Reinstall your system and verify correct partitioning"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, I saw that SK. It also says:
This scenario is not relevant to CloudGuard Network Security products (IaaS) on public cloud platforms (AWS, Azure, GCP, etc.)
That's when I opened a TAC case. I have a session scheduled tomorrow to review things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Keep us posted on what TAC says.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FIrstly, this is not a place to report bugs, we have TAC for that.
Secondly, it seems your case is described in sk180769, Scenario 1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, some older Azure images had an issue with SWAP disk misconfiguration during deployment, and as a result all installations of these images are blocked from IPU procedure. These deployments will have to be migrated with a side by side procedure.
Regarding Blink, it was indeed available previously but we're moving away from it for several reasons - the main one being providing a single upgrade package for all deployments on all Cloud vendors and an online package for SmartCenter.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will new marketplace template deployments have the corrected swap configuration? I notice on my other CloudGuard management servers that swap is never in use, plus that partition is commented out in /etc/fstab:
# free total used free shared buff/cache available Mem: 16179520 4683356 536856 351368 10959308 10419144 Swap: 0 0 0
# cat /etc/fstab /dev/mapper/vg_splat-lv_current / xfs defaults,inode32 1 1 LABEL=/boot /boot ext3 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 /dev/mapper/vg_splat-lv_log /var/log xfs defaults,inode32 1 2 #LABEL=SWAP-sda2 swap swap defaults 0 0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
New marketplace images include the corrected swap configuration.
Can you share what instance type you are testing? Some instances don't have ephemeral disks, so swap disk is not configured.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Management BYOL for R81.20
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What Azure Instance type are you using?
Dv5, Dsv5, Something else?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This was the Standard_D4s_v3 image.
While waiting on this thread, I did deploy a net-new R81.20 image and I do see now that the VM has swap space enabled and in-use, along with a different partition layout from R80.40. The new R81.20 deployment is also the same Standard_D4s_v3 image, for comparison.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Duane, any chance you could post your "good" fstab and lvm_manager output for comparison?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't have a recent R80.40 Azure CloudGuard management server anymore. They were all re-deployed with R81.20 and migrated over. This is an R81.20 /etc/fstab:
# /etc/fstab
# Created by anaconda on Tue Mar 14 15:52:02 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_splat-lv_current / xfs defaults,inode32 0 0
LABEL=/boot /boot ext3 defaults 1 2
/dev/mapper/vg_splat-lv_log /var/log xfs defaults,inode32 0 0
#LABEL=SWAP-sda2 swap swap defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/sdb1 swap swap sw,pri=1 0 0
lvm_manager for this particular Azure management server shows:
LVM overview
============
Size(GB) Used(GB) Configurable Description
lv_current 70 19 yes Check Point OS and products
lv_log 340 97 yes Logs volume
upgrade reserved 77 N/A no Reserved space for version upgrade
swap 32 N/A no Swap memory volume
unallocated space 204 N/A no Unused space
------- ----
total 723 N/A no Total size
For this host, in the deployment parameters JSON, I configured 800GB for the "additionalDiskSizeGB" value. Maybe it was just 750GB. I don't seem to have that lying around anymore.
![](/skins/images/A53DAF99EDBAFE11A1FC6E62F510C235/responsive_peak/images/icon_anonymous_message.png)