XG Auxiliary boots wrong SFOS Version

push

This looks faulty in my view. Assuming you interrupted the installation process, the AUX seems in a weird state. 

You should flash the second appliance once again, upgrade the Cluster to MR2 and join both in MR2. 

can't believe there is no way to simple modify a GRUB variable or something  like that.

so in other words, if a HA cluster breaks, I'm forced to upgrade to the newest SFOS, otherwise i can not join the Aux. 

Even if the current release 18.5.1 should be a supported release from sophos.   Upgrading a standalone primary causes additional downtime and the risk in breaking the cluster completelly.

again sophos shows that it's not suitable for any mid-range/enterprise deployments.

Cancling a installation of a product and its boot sequence looks like a bad idea to me. There is a reason nearly every product is saying "Do not power off" in such phases. 

I do not know, in which state this appliance is currently locked. You could install V18.5 MR1 and simply cut the Connection of the appliance to the internet. But i am not able to say, why your appliance downloaded a firmware update to begin with. 

You should create a support case to get this investigate or follow up with the reimage of the appliance and the upgrade. 

there is a misunderstanding here. The installation was done completely, i did not interrupt any installation process at all.

during the initial setup, the device installed 18.5.2, completely ignoring the checkbox "install upgraded during setup", which was unchecked.

there was no way to access the GUI to prepare the Box for HA Setup / register the device / sync the (base) license, without installing the "mandatory firmware upgrade"

I booted the device, after the initial setup and selected 18.5.1 from the boot loader.

it looks like this is a one time thing and is not persistant in the bootloader.

Imo it's totally legit to boot from the previous SFOS since this a common downgrade option.

I expected the device to save the setting or at least have it overwritten after HA config is synced.

I'm agree that upgrading the primary to 18.5.2 would probably have been the better option in this case. 

But since 18.5.1 is still a supported release, i don't see a reason to do this, just to fix an HA Cluster. 

the only way I see:

- register the device with 18.5.2 online

- reflash the device with 18.5.1

- skip the setup offline, so that it won't install 18.5.2

- rejoin device to cluster with 18.5..1

back to my initial question. where is the boot sequence stored and isn't possible to change the order by manipulating eg. grub.cfg?

SFVH_SO01_SFOS 18.5.2 MR-2-Build380# cd /boot/grub/
SFVH_SO01_SFOS 18.5.2 MR-2-Build380# ls
fonts grub.cfg grubenv i386-pc locale
SFVH_SO01_SFOS 18.5.2 MR-2-Build380# cat grub
cat: can't open 'grub': No such file or directory
SFVH_SO01_SFOS 18.5.2 MR-2-Build380# cat grub.cfg
set timeout=5
set default=1
insmod all_video
serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1
terminal_input --append serial; terminal_output --append serial
menuentry "SFLoader" {
linux /SFLoader quiet console=tty0 console=ttyS0,38400n8 BOOT_IMAGE=SFLoader
}
menuentry "18_5_2_380" {
linux /18_5_2_380 quiet console=tty0 console=ttyS0,38400n8 pcie_aspm.policy=performance maxcpus=4 memlimit=6G
}
menuentry "18_5_1_326" {
linux /18_5_1_326 quiet console=tty0 console=ttyS0,38400n8 pcie_aspm.policy=performance maxcpus=4 memlimit=6G
}

I cannot answer this. It is highly unsupported.