CM: Unable to load patch due to xdelta errors


Doc ID:    SOLN324330
Version:    5.0
Status:    Published
Published date:    16 Apr 2018
Updated:    05 Dec 2019
Author:   
Guest User
 

Details

CM 7 or CM 8 on VMware

Problem Clarification

Patch installation fails with checksum error on ESS/LSP servers .

Case A)  -  CM 7.1

init@<HOST> update_unpack 01.0.532.0-24502.tar
unpacking file /var/home/ftp/pub/01.0.532.0-24502.tar.gz
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta failed for file /opt/updates/01.0.532.0-24502/almclear.update.
unpacking of /var/home/ftp/pub/01.0.532.0-24502.tar.gz failed:65280RFC0080879

 

Case B)   -  newly deployed CM 8 simplex OVA

When trying to unpack any Service Pack via the Web SMI interface, the following error is displayed:
System command failed - see logs for more details. Please try again and/or contact system administrator.

Details:

unpacking file /var/home/ftp/pub/00.0.822.0-25183.tar.gz
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta failed for file /opt/updates/00.0.822.0-25183/capro.update.
unpacking of /var/home/ftp/pub/00.0.822.0-25183.tar.gz failed:65280

Cause

Case A)

Someone has edited the /opt/update/update-info file to change the status of a patch.

The xdelta errors occur because someone has edited the /opt/update/update-info file to change the status of a patch. Usually one that is stuck in an activating or deactivating state. Then another patch is activated and this overwrites all the symbolic links to the old patch files and also overwrites the base executables.

 

Case B)

Since it is a newly deployed CM 8 simplex OVA on customer provided VMware it could not happen that someone manipulated a file.
The error message

unpack_script:xdelta failed for file /opt/updates/00.0.822.0-25183/capro.update.

gives hint which file can be corrupted. And indeed when checking the checksum of the capro file

init@cm8> cd /opt/ws

init@cm8> ll capro*

-rwxr-xr-x. 1 root root 23807564 Jun 14  2018 capro

init@cm8> md5sum capro

e196a80e3d520f93f7041d6c75502464  capro

it is different from the normal one:

 

avaya@cm8-test> cd /opt/ws

avaya@cm8-test> ll capro*

-rwxr-xr-x. 1 root root 23807564 Jun 14  2018 capro

avaya@cm8-test> md5sum capro

39ea5ed9025764c1f78edefb00bdc8fb  capro

 

How could the capro checksum change when the correct OVA was used for deployment?

Further tests suggested that the issue is specific to the storage used on the customer's VMware system. When deploying the OVA with the default "thick provisioning lazy zeroed" setting in VMware the md5 checksum got corrupted. When using "thick provisioning eager zeroed" the capro checksum got he correct value and it was possible to install CM service pack.

Solution

 

remember to do backup before upgrade or install patch on CM!!!

Re-deploy the OVA on VMware with thick provisioning eager zeroed.

After that CM Service Pack installation started to work:

init@cm8> swversion

     Operating system:  Linux 3.10.0-693.21.1.el7.x86_64 x86_64 x86_64

                Built:  Feb 23 18:54 2018

 

             Contains:  00.0.822.0

        CM Reports as:  R018x.00.0.822.0

    CM Release String:  vcm-018-00.0.822.0

          RTS Version:  CM 8.0.1.1.0.822.25183

     Publication Date:  09 May 2018

  VMwaretools version:  10.1.5.59732 (build-5055683)

       App Deployment:  Virtual Machine

       VM Environment:  VMware

 

UPDATES:

Update ID                         Status       Type  Update description

--------------------------------- ------------ ----- ---------------------------

00.0.822.0-25183                  activated    cold  8.0.1.1.0-FP1SP1

 

 

Platform/Security ID              Status       Type  Update description

--------------------------------- ------------ ----- ---------------------------

 

 

 CM Translation Saved:   2018-06-14 03:21:25

 

 CM License Installed:   2019-04-05 08:57:19

 

     CM Memory Config:   Large

 

Additional Relevant Phrases

When Thick Provisioning Lazy Zeroed method is used for VMware VM storage LicenseServer process may fail to start in CM causeing license errors.

Please rate this article

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy