manager upgrade from r81.10 to r81.20

[Luis_Miguel_Mig]

I am planning to upgrade the firewall manager from r81.10 to r81.20.

Cpuse doesn't list r81.20 though. I can see different  r81.10 hot fixes but I can see any r81.20 package. Why would it happen? 
I have another firewall manager vm in the lab running r81.10 and I can see the list of r81.20 packages in cpuse.

[Alex-]

This happens if your partitioning isn't compatible or similar.

You will need an advanced upgrade with migrate_server on a new server.

[Luis_Miguel_Mig]

I have read that partition or disk requirements could cause the installation to fail but not the prevent r81.20 to be shown as an option.

Is there anyway to troubleshoot it or some sort of  cpuse verbose logs?

[Alex-]

You can import the R81.20 image manually in CPUSE and run the verifier to see if you get more information.

Given the advantages of installing on a new system, I wouldn't go through the trouble and perform an advanced upgrade instead.

[Luis_Miguel_Mig]

you are right Alex. I imported r81.20 manually and I got that error because we have two  raid logic disks on for the system and one for the logs.

So I guess I have no option but going through the pain of setting up a new management pair of servers. 

Such a pity because ì am quite happy with the current open server managers.

Any workaround, alternative or suggestion?

[the_rock]

Can you share the error?

Andy

[Luis_Miguel_Mig]

error attached

[the_rock]

Can you send output of below?

df -h

parted -l

[Luis_Miguel_Mig]

attached

[the_rock]

I see its totally different, so as @Alex- said, this probably wont work as far as upgrade. Maybe TAC can give some sort of workaround, not sure.

Below is what it should look like.

Andy

[Expert@CP-FW-01: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: Virtio Block Device (virtblk)
Disk /dev/vda: 107GB
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 107GB 98.5GB lvm

[Expert@CP-FW-01:0]#

[Luis_Miguel_Mig]

totally different? Not really ,just two disks instead of one.
Is there anything else I am missing? 

I was wondering if I can take advantage of the Management HA so I don't need to be worried about migrate export.

So I could do a fresh install in the secondary management with one disk, sync it and failover and repeat the process with the management primary with one disc and sync

I guess management HA is not concerned about the disk partitions, right?

[the_rock]

Partition table is different, not sure if that could be one of the reasons. Yea, mgmt HA may be good option here.

Andy

[PhoneBoy]

Given the fdisk and installer improvements, you might find performance improves dramatically by doing a clean install and advanced migration.

[Luis_Miguel_Mig]

so clean install and sync on the secondary

and clean install and advanced migration on the primary

If I do clean install and advance migration from r81.10 to r81.20 just to get installed r81.10  in one disk, I guess I won't need to get worried about SIC licenses etc. And then I can upgrade to r81.20.

Or would you do clean install and advanced migration from r81.10 to r81.20? If I do that on the same server, I guess SIC will be okay,  licenses will be okay straight away. So it may be cleaner but it feels a bit riskier, doesn't it?

[PhoneBoy]

When doing any sort of upgrade involving Management HA, the secondary node has to be done as a clean install.
In this case, your primary management also needs a clean install (to get the aforementioned benefits).

You might be able to reinstall the secondary node with R81.20, downgrade to R81.10 (use the Clean Install option in CPUSE), and reconfigure Management HA.
Then promote to primary and do the same on the other node.

No idea if that will work, of course.
I'd still suggest taking a backup with migrate_server before proceeding with any of this.