Update to 12.1 Error: Invalid length parameter passed to the RIGHT function.

[heavy]

Hi all,

i have an issue installing V12.1 in a customer's environment.

Code: Select all

05.12.2023 15:37:48 Error    Invalid length parameter passed to the RIGHT function.

                             The statement has been terminated.

                             Guests hosts fingerprints have been updated to SHA256.

Initially i thought this was an issue when migrating to a new server and this occured when importing the old database backup onto the new installation. So i thought i'd upgrade the existing server, take a fresh database backup and then migrate. Unfortunately the very same error occured when the installation tried to upgrade the existing database.

Biggest issue right now: both servers do not accept the configuration backup, the old one did not even finish the update but invalidated the install so far that i have to uninstall.

Bonus question: is the ISO for P20230412 still downloadable? Right now I'd love to get the existing environment back into a working state and this seems to be my best bet.

Any help is welcome. Thanks
Thomas

[Mildur]

Hello Thomas

Please open a case with our customer support team to solve this issue.
Share the case number with us so we can follow the case from our side.

Best,
Fabian

[Gostev]

Bonus question: is the ISO for P20230412 still downloadable?

No, only 12.0.0.1420 P20230718 is still downloadable as this is the latest patch for version 12.0
But there's really no reason to use P20230412 specifically at this time, you do want P20230718.

[MPG]

HI,

i have the same issue on our Backup Server. I go Back to previous version 12.0.0.1420 P20230718 and all is working again.

Case ID #02957621

[KSCSIT]

I have had exactly the same this evening - Case 07038726

Upgrading failed half way through & won't let me reinstall as it says I have to "Uninstall the console first" which I don't want to do without support telling me it's ok or not..

Server OS is 2022.

[tyler.jurgens]

Is everyone with this issue trying the same upgrade path? P20230412 -> 12.1? Has anyone tried P20230412 -> P20230718 -> 12.1?

[chris.childerhose]

It would be nice to know if there are issues with the P20230718 patch. About to test this in my homelab, so we will see.

[balazs.nagy]

Dear, I have the same issue: 12.0.0.1420_20230718 -> 12.1.0.2131_20231205

[KSCSIT]

I was on P20230718

[Gostev]

Even without looking at the logs, the issue has got to deal with some invalid/unexpected content of the Backup.Model.HostSshFingerprint table, which makes the fingerprint conversion code fail.

Those affected and knowing how to work with SQL, please dump current_fingerprint content and attach to your support case, so the devs could see what those unexpected values are. Hopefully seeing the actual values will help to get some ideas on how those could appear in the first place. And if they are mostly one-offs then we can modify the upgrade script to simply skip them.

Code: Select all

SELECT [current_fingerprint]
  FROM [dbo].[Backup.Model.HostSshFingerprint]

[dcolpitts]

I haven't had a chance to open a ticket yet... Trying to get this box restored back to 12.0 in time to run tonight's backup, so the ticket will come tomorrow. But in my case, in that entire table, there are 13 entries, and not a single one has a value for current_fingerprint.

dcc

[KSCSIT]

@Gostev Yarp no problem, my agent has requested I upload ours & have done so

[Gostev]

I haven't had a chance to open a ticket yet... Trying to get this box restored back to 12.0 in time to run tonight's backup, so the ticket will come tomorrow. But in my case, in that entire table, there are 13 entries, and not a single one has a value for current_fingerprint.

@dcolpitts got it, thanks. If you replace those empty values with a single space symbol, this should allow the upgrade to complete. Might be easier than restoring 12.0. Just remember to roll this change back after the upgrade until more is known about why are they empty in the first place.

Before upgrade:

Code: Select all

update [dbo].[Backup.Model.HostSshFingerprint] set [current_fingerprint] = ' ' where [current_fingerprint] = '';

After upgrade:

Code: Select all

update [dbo].[Backup.Model.HostSshFingerprint] set [current_fingerprint] = '' where [current_fingerprint] = ' ';

[dcolpitts]

15 minutes too late Gostev! But I'll try that tomorrow (probably mid afternoon Eastern time zone) and report back here.

Thanks

dcc

[Gostev]

So given 19 minutes difference between our posts, I had to respond in 4 minutes to have a chance!! But sound good

[KSCSIT]

So that fix appears to have worked for me - I'll do some verification in the morning but have been able to install 12.1 successfully now

[Asahi]

Hi,

I have tested the upgrade in my Lab environment.
※12.0.0.1420_20230718 -> 12.1.0.2131_20231205

However, no problems occurred.

The Veeam server that exists in my test environment is running with a configuration DB of PostgreSQL 15.5-1.
Does this problem occur when the configuration DB is SQL Server?

Kind Regards,
Asahi,
Climb inc.

[Asahi]

By the way, I have several Linux machines registered on my Veeam server from before the upgrade.

[skate88]

hello i too have the same error ticket is logged with the error logs attached
Case # 07039630

i can execute the sql command, but i cannot restart the installation
as the install optio s greyed out with "please uninstall console first"
add remove programs shows the following installed
veeam backup and replication
microsoft windows desktop runtime 6.0.24
veeam VSS hardware provider

waiting for advise before doing anything further

[Gostev]

We can't assist you over forum posts, please work with the support engineer assigned to your case. I think a live support session is due in your case?

I have tested the upgrade in my Lab environment.
※12.0.0.1420_20230718 -> 12.1.0.2131_20231205

However, no problems occurred.

The Veeam server that exists in my test environment is running with a configuration DB of PostgreSQL 15.5-1.
Does this problem occur when the configuration DB is SQL Server?

Yes, the issue is only possible with SQL Server as a configuration database and likely applies to a very limited scope of users anyway, as we're talking completely unexpected content of the configuration database.

In our experience these inconsistencies are usually from very old product versions which took years of in-place upgrades to make it to their final show.

Which is also why this is something that is simply impossible to catch in internal QA process, only during real upgrades.

[Gostev]

We plan to release a new VBR ISO with only the SQL upgrade script granularly replaced with one that skips invalid entries. As always the ISO will have a new production date in it's name, so it will be easy to distinguish from earlier download.

We will post an update here when it's live.

[Simonx182]

Before upgrade:

Code: Select all

update [dbo].[Backup.Model.HostSshFingerprint] set [current_fingerprint] = ' ' where [current_fingerprint] = '';

After upgrade:

Code: Select all

update [dbo].[Backup.Model.HostSshFingerprint] set [current_fingerprint] = '' where [current_fingerprint] = ' ';

Thanks Gostev. The SQL workaround solved the problem. In my installation there where also 13 rows with empty values.

[heavy]

Hi all,

first of all, thanks @Gostev for pointing me towards V12 downloads - i could not find the previous versions.
Just like many others already wrote, I also tried P20230412 -> P20230718 -> 12.1 last night, but to know avail, same result. And yes, this is an environment using MSSQL server, not postgres.

Since i needed the environment back up and running asap, i kept it running on P20230718 after a few failed attempts.
Today I forgot to check back here before i decided to use the opportunity and start with a fresh and clean install of 12.1 (on postgres) and migrate the configuration on my own (powershell for the win).

Very nice to see that a workaround is found by updating the fingerprints in the database.

Thanks
Thomas

[dcolpitts]

@Gostev - yes I too can confirm the DB update and roll back afterwards worked.

dcc

[veremin]

We plan to release a new VBR ISO with only the SQL upgrade script granularly replaced with one that skips invalid entries. As always the ISO will have a new production date in it's name, so it will be easy to distinguish from earlier download.

We will post an update here when it's live.

The new .iso has been just published.

[dcolpitts]

Uh - instead of re-downloading a 10GB ISO image at 20+ managed customer sites (after having pulled it down yesterday), is there another option for this script?

dcc

[Gostev]

The new .iso has been just published.

Actually, not just that ISO only but all ISOs containing VBR (all the different production editions/packages) have been updated.
All ISOs dated 20231206 (or later) at the end of the file name will have the patched upgrade script that skips invalid entries.

[Gostev]

Uh - instead of re-downloading a 10GB ISO image at 20+ managed customer sites (after having pulled it down yesterday), is there another option for this script?

Well, in case you want to update the original ISO yourself, then the only two files you need from the patched ISO are Server.x64.msi and VBR_SRV.CAB from the Backup folder.

[dcolpitts]

Ok - well that makes it simpler and quicker for those sites with poor bandwidth options (of which there are many).

[wmarshal]

Case #07040589

With the new ISO file, should the old version of VBR be uninstalled first before launching the new ISO?

Thank you.