Virtual appliance detecting sda and sdb in wrong order

[adriant5 (Adrian Correa)]

CMK version: 2.3.0p3**
OS version: Virtual appliance firmware version 1.7.1 over VMware VSphere

Error message:
sda and sdb disks detected in reverse order, so DRDB replication not working.

Hi!
We were working flawlessly with virtual appliance firmware version 1.7.1 but after a power cycle we found that the second node on our cluster was unable to replicate.
After some time doing some debug we found that the virtual appliance is detecting sda and sdb in reverse order.
Later we found there is a related bug (Fix "Found an unpartitioned data volume" blocking boot process), but the upgrade to version 1.7.2 still has the bug.
Even starting fresh with firmware 1.6.8 (working fine) and upgrading directly to 1.7.2, the disks are detected in wrong order after the upgrade to 1.7.2

I hope someone can help us with this.
Thanks!

[robin.gierse]

You want to reboot the appliance when it is stuck at the “unpartitioned data volume” until it boots properly. During the update, you are still on the older firmware and only after a subsequent reboot does 1.7.2 become active. You can see that in the GRUB screen.

TL;DR: If you get stuck during upgrade, reboot a few times (one time might suffice).

[adriant5 (Adrian Correa)]

Thanks Robin!
We tried 1.7.1 to 1.7.2 upgrade and we fund that the appliance get stuck on 1.7.1, booting but the instance end up on the initial configuration screen as if it was never configured.
That’s weird, and the weirdest thing is that upgrading from 1.6.8 (working fine with no problems at all) to 1.7.2 the bug is still present after power cycling the vm.

[robin.gierse]

@adriant5

We tried 1.7.1 to 1.7.2 upgrade and we fund that the appliance get stuck on 1.7.1, booting but the instance end up on the initial configuration screen as if it was never configured.

That means the data was actually wiped off the drive, which only happens, if one confirms the dialogue to initialize the volume.

@adriant5

That’s weird, and the weirdest thing is that upgrading from 1.6.8 (working fine with no problems at all) to 1.7.2 the bug is still present after power cycling the vm.

I doubt that. If you upgrade from whatever version to 1.7.2, the first reboot still uses the old version and after another reboot it boots into 1.7.2. If you can actually prove, that the issue is still present in 1.7.2, please open a ticket, so we can look at the diagnostic data (which you probably do not want to share on a public forum?).