R81.20 Azure CloudGuard management upgrade package bug

[Duane_Toler]

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?

[the_rock]

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

[Duane_Toler]

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.

[the_rock]

I believe you 100%, because I did it too...ONLY once though and then poof, it was gone next day : - )

Andy

[Duane_Toler]

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"... 😕

[the_rock]

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

[Chris_Atkinson]

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"

[Duane_Toler]

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.

[the_rock]

Keep us posted on what TAC says.

[_Val_]

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. 

[Itay_Sharim]

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.

[Duane_Toler]

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

[Itay_Sharim]

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.

[Duane_Toler]

Management BYOL for R81.20

[Itay_Sharim]

What Azure Instance type are you using?

Dv5, Dsv5, Something else?

[Duane_Toler]

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.

[EY]

Duane, any chance you  could post your  "good" fstab and lvm_manager output for comparison?

[Duane_Toler]

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.