Using smart dashboard method to upgrade HA cluster to R81.20

[the_rock]

Hey guys,

Happy Friday 🙂

Jus a word of caution, if anyone is thinking of using smart dashboard method to upgrade their cluster to R81.20, I do not recommend it. I tried, whole process got stuck at 69% and it "sat" there for almost 2 hours. I got sick of waiting, rebooted backup member, did web UI method for both cluster members and worked like a charm.

Cheers,

Andy

[Bob_Zimmerman]

Odd. A few weeks ago, I used SmartConsole to update three clusters at once to R81.20 with no hiccups. Would be nice if the update UI in SmartConsole provided better feedback.

[the_rock]

Worked fine for latest jumbo hotfix install on R81.10 though.

[genisis__]

I also had issues, but mine related to just doing a clean building using ISOmorphic tool.  I did post the error received but I've had no response.
USB built fine, booted and then then just after the menu it seems to crash.  Using the same process and USB but with R81.10 image, no problems at all.

[Chris_Atkinson]

Pretty broad statement from a small sample set of experience but appreciate the feedback just the same.

So others can assist / compare based on their own experience are you able to share the details of the systems involved in terms of source versions / JHF / deployment agent build etc ?

[the_rock]

All latest versions...R81.10 jumbo 95

[genisis__]

ISOMorphic Tool = Build 201

ISO Image T631 of R81.20

CPU Agent 2182

Jumbo HFA8
Kingston USB Stick (works fine with R81.10 and used this many times) 

Here's output I posted in another chat stream which may also help:

I have a 5200 appliance, just created a R81.20 USB with latest CPUSE agent and JHFA8, after booting this is what I get after initial menu:

i8042: No controller found
Inserted module sd 0:0:0:0: [sdb] No Caching mode page found
sd 0:0:0:0: [sdb] Assuming drive cache: write through
[ *** ] A start job is running for Switch Root (32s / no limit)device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
Buffer I/O error on device dm-0, logical block 395434
Buffer I/O error on device dm-0, logical block 396714
Buffer I/O error on device dm-0, logical block 396715
Buffer I/O error on device dm-0, logical block 396716
Buffer I/O error on device dm-0, logical block 396717
Buffer I/O error on device dm-0, logical block 396718
Buffer I/O error on device dm-0, logical block 396719
Buffer I/O error on device dm-0, logical block 396720
Buffer I/O error on device dm-0, logical block 396721
Buffer I/O error on device dm-0, logical block 396722
[ *] A start job is running for Switch Root (34s / no limit)Aborting journal on device dm-0-8.
Buffer I/O error on dev dm-0, logical block 262144, lost sync page write
[ *BD2: Error -5 detected when updating journal superblock for dm-0-8.
[1;31m*] A sBuffer I/O error on dev dm-0, logical block 0, lost sync page write
tart job is runnEXT4-fs error (device dm-0): ext4_journal_check_start:56: Detected aborted journal
ing for Switch REXT4-fs (dm-0): Remounting filesystem read-only
oot (34s / no liEXT4-fs (dm-0): previous I/O error to superblock detected
mit)Buffer I/O error on dev dm-0, logical block 0, lost sync page write
EXT4-fs error (device dm-0): ext4_find_entry:1318: inode #18: comm systemd: reading directory lblock 0
EXT4-fs (dm-0): previous I/O error to superblock detected
Buffer I/O error on dev dm-0, logical block 0, lost sync page write
[FAIL/bin/sh: /usr/sbin/sulogin: No sEXT4-fs error (device dm-0): ext4_find_entry:1318: inode #18: comm systemd-fstab-g: reading directory lblock 0
EXT4-fs (dm-0): previous I/O error to superblock detected
Buffer I/O error on dev dm-0, logical block 0, lost sync page write
Buffer I/O error on dev dm-0, logical block 272, lost async page write
Warning: /dev/root does not exisBuffer I/O error on dev dm-0, logical block 537584, async page read
t

Generating Buffer I/O error on dev dm-0, logical block 537584, async page read
"/run/initramfs/rdsosreport.txt"

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

dracut:/#

Anyone seen this before?  If I reboot appliance comes up fine with previous GAIA release.

Builds find with R81.10 ISO on the USB.

Redownloaded R81.20 ISO and checked hash, all good.  Rebuild same USB with R81.20 ISO and got the same issue, so only conclusion is you can't do a clean build of a 5200-appliance using R81.20 ISO utilising the isomorphic to build a USB.

Can someone please test to confirm if this is just isolated to me, or if I'm actually right here.

[the_rock]

Cant say if thats just an isolated case or not, but I think I will stick with web UI method, as it never gave me any issues.

[Alex-]

I generally use Zalman VE which allows to emulate a DVD drive from a loaded ISO library or function as classical USB drive. 

Works perfectly with anything. In terms of CP appliances, only 3000 series didn't like it but the rest never posed any issue.

[divad]

Hellow,

I have the same problem with two 16200 Apliances. My solution is to create a ISO (isomorphic) with R81.20 but without additional HFA and Deployment Agent. That works for me.

MfG

David

[Boaz_Orshav]

Hi Andy

  In order to understand why it was stuck I would appreciate if you can send me the logs (run "collect_logs.bash on the management machine) to boazo@checkpoint.com

  In general the Smart Console simply orchestrate the same processes as you used to do manually so it's stability is expected to be high.

  Will know better after I can review the logs

Thanks

Boaz

[the_rock]

Thanks @Boaz_Orshav . Not a big deal, I will stick with what I know works : - )

[Luis_Miguel_Mig]

I tested the standard cluster upgrade in r81.10 and worked well for me.
Now I see that r81.20 allows you to install to non-active members only with or without failover.

So I guess the expectation is to run the cluster upgrade in two or three steps:

2 steps:
1) install on non-active members only + once installation is complete, turn non-active member to active
2) install on non-active members only + once installation is complete, turn non-active member to active

3 steps:

1) install on non-active members only + once installation is complete; no turn non-active ...

2) Failover: clusterXL_admin down; clusterXL_admin up

3) install on non-active members only + once installation is complete; no turn non-active ...

Has anybody tested ? Any feedback?