Update from 16.08.16 to version 18 failed on Debian upgrade from 9 to 10 GCP hosted

[rely1]

Hello,
I have several instances of 3cx hosted in GCP. One of them will not upgrade and fails on a set of steps trying to download the appropriate update for Debian O/S.

Below is a snippet of the logs:
Reading package lists...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.debian.org/debian stretch-backports InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://packages.cloud.google.com/apt google-compute-engine-stretch-stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://packages.cloud.google.com/apt google-cloud-packages-archive-keyring-stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: Failed to fetch http://deb.debian.org/debian/dists/stretch-backports/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
W: Failed to fetch http://packages.cloud.google.com/apt/dists/cloud-sdk-stretch/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: Failed to fetch http://packages.cloud.google.com/apt/dists/google-compute-engine-stretch-stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: Failed to fetch http://packages.cloud.google.com/apt/dists/google-cloud-packages-archive-keyring-stretch/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FEEA9169307EA071 NO_PUBKEY 8B57C5C2836F4BEB
W: Some index files failed to download. They have been ignored, or old ones used instead.
W: --force-yes is deprecated, use one of the options starting with --allow instead.

Not sure what to do here as I cannot seem to upgrade to V18 due to the above errors?

Anyone else experience this or have a manual solution on the CLI?

Thanks!

 

[Agathocles Prodromou]

Hi there,

The recommended way would be to take a full backup of 3CX, setup a new Debian 10 instance, shutdown the old instance and then restore the 3CX backup on the new one.

If that is not an option then try the following:

1. SSH on your machine
2. Run apt-update. It should output the same errors as the ones you posted
3. Run curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
4. Run apt-update. Google related errors should be gone
5. Run apt-get install debian-keyring debian-archive-keyring -y
6. Run apt-update. If you get no errors reboot & then logon to your Management Console and initiate the upgrade process. If you still get errors then please follow the recommended way and spin up a new Debian 10 machine.

 

[rely1]

Thanks for the ideas and options. If I launch a new instance will V18 recognize a backup from V16 and restore it?

Thanks!

 

[cobaltit]

Not sure if you are asking if a new instance will magically see the backup, or if you can restore a v16 backup. When you install 3CX it will ask you if you are doing a fresh install or want to restore a backup. If you pick 'Restore' and the provide the backup file then yes it will recognize it. Be sure you copy the backup off the VM.

 

[Agathocles Prodromou]

Thanks for the ideas and options. If I launch a new instance will V18 recognize a backup from V16 and restore it?

Thanks!

If you are running the latest version of V16 the yes it should work fine once you upload it during V18's installation wizard.

 

[rely1]

Ran the fix above on the "CLI" but the upgrade failed again to the point that I can no longer log into the UI over the web browser. Connected to the Serial console for the VM and found it was stuck on Boot From Hard Disk 0, so it would no longer boot. I did take a full backup of the V16 version so I will deploy a V18 VM at GCP and restore from my backup, hoping that my backup is fine.

Thanks

 

[Agathocles Prodromou]

The CLI commands did fix the issues reported initially but the upgrade failed while processing a package for google compute engine. If you have a full backup then there should be no problem restoring on a new V18 instance. Deploying a V18 machine and restoring from backup takes less than 15 minutes in most cases.

 

[rely1]

I have an old backup...seems my latest backup was for another client. To make matters worse I deployed a new VM in GCP and restored another clients mislabeled backup onto this VM, so now I have 2 VM's running with the same FQDN which in turn changed the FQDN for the working clients 3cx instance..

To fix this do I need to release the FQDN of the working client's 3cx instance from the customer portal? Then how do I set up the FQDN again is that from the customer portal or from the Web interface?

 

[Agathocles Prodromou]

For the FQDN to point back to the correct server you need to stop the new instance. Then go to the old (correct) instance and refresh the license key information via the Management Console. That should trigger DNS change and revert. No need to release the FQDN.

 

[rely1]

Thanks! Spent $75 on a support case to learn you can also restart the service:
3CX PhoneSystem 01 System Server and it will also re-register the FQDN after stopping the duplicate instance.

Also word to the wise: if you are hosted in a public cloud, schedule snapshots so you can easily revert if something goes really wrong you can simply restore and get the system back to a working state.

Regards