AWS Cluster in-place upgrade

[khodgson_bts]

Hi all.

Trying an in-place upgrade of an R81.20 AWS cluster to R82, which according to sk177714 is possible but when importing the relevant upgrade package, I'm getting the error in this screenshot:

The gateways were deployed using the CFT provided by Check Point and are running on c4.large (this is only a lab environment).

Any ideas what the issue might be?

[Nir_Shamir]

Because of the partitions issue you won't be able to do in-place upgrade.

You will have to go with Advanced Upgrade, basically deploy a new R82 Cluster and move all routes, policies etc. to it.

[khodgson_bts]

Hi.

Thanks for the response, but I don't understand why this is necessary. The cluster was deployed using the approved Cloud Formation Template, and according to the referenced SK article the in-place upgrade is supported using the package provided. Does this mean that the article is incorrect? I have no control over how the partitions are created. Even the error says it is supported on AWS.

[Nir_Shamir]

No one tried to change the disk size ? partitions ?

[khodgson_bts]

No. It's a fresh deployment. I'm just testing the process in my lab at this stage.

[Nir_Shamir]

I can’t tell why exactly it’s like that from a fresh install but the only option with this error is a new deployment. 

[DanAyzik]

Hi @khodgson_bts,
You saying this is a fresh deployment really sparked my curiosity.
Can you please share the outputs of:
fdisk -l
parted -l
df -h
lvs
vgs
pvs

from the machine?

[khodgson_bts]

Here you go.

[Expert@Cluster-01-member-a:0]# fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/xvda: 214.7 GB, 214748364800 bytes, 419430400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 0992E62B-6F31-41EE-968C-964CB70E898E

# Start End Size Type Name
1 2048 4095 1M BIOS boot parti
2 4096 618495 300M Microsoft basic
3 618496 17395711 8G Linux swap
4 17395712 419430366 191.7G Linux LVM Linux LVM
[Expert@Cluster-01-member-a:0]# parted -l
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vg_splat-lv_current: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 21.5GB 21.5GB xfs

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vg_splat-lv_log: 46.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 46.2GB 46.2GB xfs

Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 215GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 317MB 315MB ext3
3 317MB 8907MB 8590MB linux-swap(v1)
4 8907MB 215GB 206GB Linux LVM lvm

[Expert@Cluster-01-member-a:0]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 20G 8.3G 12G 42% /
/dev/xvda2 291M 52M 225M 19% /boot
/dev/mapper/vg_splat-lv_log 43G 4.9G 39G 12% /var/log
tmpfs 1.8G 26M 1.7G 2% /dev/shm
[Expert@Cluster-01-member-a:0]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_current vg_splat -wi-ao---- 20.00g
lv_log vg_splat -wi-ao---- 43.00g
[Expert@Cluster-01-member-a:0]# vgs
VG #PV #LV #SN Attr VSize VFree
vg_splat 1 2 0 wz--n- 191.70g 128.70g
[Expert@Cluster-01-member-a:0]# pvs
PV VG Fmt Attr PSize PFree
/dev/xvda4 vg_splat lvm2 a-- 191.70g 128.70g
[Expert@Cluster-01-member-a:0]#

---

@DanAyzik wrote:

Hi @khodgson_bts,
You saying this is a fresh deployment really sparked my curiosity.
Can you please share the outputs of:
fdisk -l
parted -l
df -h
lvs
vgs
pvs

from the machine?

---

---

@DanAyzik wrote:

Hi @khodgson_bts,
You saying this is a fresh deployment really sparked my curiosity.
Can you please share the outputs of:
fdisk -l
parted -l
df -h
lvs
vgs
pvs

from the machine?

---

[DanAyzik]

Everything looks standard for a fresh deployment.
I'll look into it tomorrow and let you know what I find.

[DanAyzik · Accepted solution]

Hi @khodgson_bts  can you try a newer instance type (one that is nitro-based rather than Xen-based like c4.large) Example: c6in.large

[khodgson_bts]

That seems to have done the trick.

Perhaps this information should be added to the SK article.

Thanks.