ScaleIO: During upgrade of ScaleIO using Installation Manager, could not upgrade one SDS and cannot mark upgrade complete.

Article Number: 492097 Article Version: 3 Article Type: Break Fix

ScaleIO,ScaleIO 2.0.1,ScaleIO

scli –query_upgrade

Upgrade State: SDS Upgrade in Progress

List of Slave MDMs not yet upgraded:

0 Slave MDMs need to be upgraded in total

List of Tie-Breakers not yet upgraded:

0 Tie-Breakers need to be upgraded in total

List of SDSs not yet upgraded:

Protection Domain XXXXXXXX00000000 Name: domain1

SDS ID: XXXXXXXX00000066 Name: SDS-NAME State: Connected, Joined IP: 10.XX.AA.YY,10.XX.BB.YY,10.XX.CC.ZZ,10.XX.DD.ZZ Port: 7072 Version: 2.0.7536

1 SDSs need to be upgraded in this Protection Domain

1 SDSs need to be upgraded in total

rpm -qa | grep -i lia returned the version 2.0-8005.0 on the hosts that were working fine while it returned version 2.0.7536 on the problem SDS.

conf.txt file in LIA folder on another working host looks like this:-

lia_os_name=Red Hat 6




lia_os_name=Red Hat 6







While on the problem node SDS-NAME it has the following contents:-



lia_os_name=Red Hat 6






1. Manually upgrade LIA to the newer version

rpm -Uvh EMC-ScaleIO-lia-2.0-8005.0.el6.x86_64.rpm

2. Navigate to the folder /opt/emc/scaleio/lia/bin and run the following scripts to restart lia:-



3. Make sure lia is running:-

ps -ef | grep lia

4. Navigate to the folder /opt/emc/scaleio/lia/bin and run the command:-

./update_conf_bin 7 lia_trusted_ips <list of the trusted IPs> 1


./update_conf_bin 7 lia_trusted_ips 10.XX.16.75,10.XX.48.75,10.XX.64.11,10.XX.80.11 1

5. Navigate to the folder /opt/emc/scaleio/lia/conf and run the command “cat conf.txt” and validate that now you see the below line:-


6. Navigate to the folder /opt/emc/scaleio/lia/bin and run the following scripts to restart lia:-



7. Make sure lia is running:-

ps -ef | grep lia

8. Enter the SDS in the maintenance mode:-

scli –enter_maintenance_mode –sds_name SDS-NAME

9. Wait for any rebuild/rebalance activity to finish.

10. Upgrade the SDS package on host eurdtp1siob15 using the rpm command :-

rpm -Uvh EMC-ScaleIO-sds-2.0-<BUILD>.0.elX.x86_64.rpm

11. Restart the SDS service. This can be done by either “pkill sds” or navigate to the folder /opt/emc/scaleio/sds/bin and run the following scripts to restart sds:-



12. Verify the SDS package:-

rpm -qa | grep -i sds

13. Exit maintenance mode (run the command from the Master MDM)

scli –exit_maintenance_mode –sds_name SDS-NAME

14. Finalize the upgrade using scli command

scli –finalize_upgrade


7023120: Migrating a SLES 15 system to SLES for SAP Applications 15

Use an interactive script.

Download the following RPM file to the server running SUSE Linux Enterprise Server 15. It is not required that the system (the source system) be registered with SUSE Customer Center (SCC).

Install the RPM:

# zypper in migrate-sles-to-sles4sap-15-2.1.noarch.rpm

After installation run the interactive script and follow the on screen instructions:

NOTE: It is required to have your email address as well as a valid registration key for SUSE Linux Enterprise Server for SAP Applications (the target system) at hand.

# sudo /usr/sbin/

NOTE: In case packages are installed that have dependencies against IBM Java, it may be needed to reinstall them at the end of the procedure.

A reboot of the system is not necessary unless packages which require a reboot are also installed from the newly added channels.


7017137: How to obtain systemd service core dumps

Temporary configuration:

echo ‘|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e’ > /proc/sys/kernel/core_pattern


Persistent configuration:

1. echo ‘kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e’ > /etc/sysctl.d/50-coredump.conf

2. reboot

Run sysctl -a | grep ‘kernel.core_pattern’ to confirm the correct core_pattern command.

UPDATE NOTE: The command “systemd-coredumpctl” has changed in SLES12-SP2 and above. In SLES12-SP2/SP3 the command is “coredumpctl”.

In order to see coredumps, run:

sles12sp1:~ # systemd-coredumpctl list

Fri 2016-01-08 15:01:10 MST 1088 0 0 6 /usr/sbin/sshd
Fri 2016-01-08 15:34:04 MST 1655 0 0 6 /usr/sbin/sshd
Fri 2016-01-08 15:34:05 MST 21491 0 0 6 /usr/sbin/sshd
Fri 2016-01-08 15:35:27 MST 1361 0 0 6 /usr/sbin/cron
Fri 2016-01-08 15:35:36 MST 21501 0 0 6 /usr/sbin/sshd
Fri 2016-01-08 15:35:39 MST 21530 0 0 6 /usr/sbin/cron

To get the most recent sshd coredump, run:

sles12sp1:~ # systemd-coredumpctl -o core.sshd dump /usr/sbin/sshd

Fri 2016-01-08 15:35:36 MST 21501 0 0 6 /usr/sbin/sshd
More than one entry matches, ignoring rest.

sles12sp1:~ # ls -l core.sshd
-rw-r--r-- 1 root root 954368 Jan 8 15:49 core.sshd

To get other coredumps, by PID# run:

coredumpctl -o FileName dump PID#

coredumpctl -o core.sshd dump 21491

You must run systemd-coredumpctl dump to extract any core dumps you want out of the systemd journal before rebooting the server. The core dumps stored in the systemd journal will not persist after a server reboot. See systemd-coredumpctl(1) for more options.

Application core can be stored in /var/lib/systemd/coredump depending on the storage setting in /etc/systemd/coredump.conf, see the coredump.conf(5) man page for options.

Run getappcore /path/to/core.sshd to prepare the core dump to upload to SUSE.

sles12sp1:~ # getappcore core.sshd

Get Application Core Tool, v1.28
Date: 01/08/16, 15:50:51
Server: sles12sp1
OS: SUSE Linux Enterprise Server 12 - SP1
Kernel: 3.12.49-11-default (x86_64)
Corefile: core.sshd

Binary file not provided, trying to determine source binary using gdb... Done (/usr/sbin/sshd)
Checking Source Binary with chkbin... Done
Building list of required libraries with gdb... Done
Building list of required RPMs... Done
Building list of debuginfo RPMs...

glibc-2.19-31.9.x86_64.rpm --> glibc-debuginfo-2.19-31.9.x86_64.rpm
krb5-1.12.1-19.1.x86_64.rpm --> krb5-debuginfo-1.12.1-19.1.x86_64.rpm
libaudit1-2.3.6-3.103.x86_64.rpm --> audit-debuginfo-2.3.6-3.103.x86_64.rpm
libcom_err2-1.42.11-7.1.x86_64.rpm --> e2fsprogs-debuginfo-1.42.11-7.1.x86_64.rpm
libkeyutils1-1.5.9-3.29.x86_64.rpm --> keyutils-debuginfo-1.5.9-3.29.x86_64.rpm
libopenssl1_0_0-1.0.1i-34.1.x86_64.rpm --> openssl-debuginfo-1.0.1i-34.1.x86_64.rpm
libpcre1-8.33-3.314.x86_64.rpm --> pcre-debuginfo-8.33-3.314.x86_64.rpm
libselinux1-2.3-2.75.x86_64.rpm --> libselinux-debuginfo-2.3-2.75.x86_64.rpm
libwrap0-7.6-886.3.x86_64.rpm --> tcpd-debuginfo-7.6-886.3.x86_64.rpm
libz1-1.2.8-5.1.x86_64.rpm --> zlib-debuginfo-1.2.8-5.1.x86_64.rpm
openssh-6.6p1-29.1.x86_64.rpm --> openssh-debuginfo-6.6p1-29.1.x86_64.rpm
pam-1.1.8-14.1.x86_64.rpm --> pam-debuginfo-1.1.8-14.1.x86_64.rpm

... Done
Setting gdb environment variables... Done
Creating gdb startup files... Done
Creating core archive... Done
Created archive as: /var/log/nts_sles12sp1_sshd_160108_1550_appcore.tbz
Removing required files and directories ... Done



7014247: How to upgrade SLES for SAP Applications 11 SP2 to SP3

This document (7014247) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 11 for SAP Applications


A system running SLES for SAP Applications 11 Service Pack 2 should be upgraded to Service Pack 3.


Important note: Aftercompleting any form of update, run the command “rcrpmconfigcheck”, then look at the contents of the file /var/adm/rpmconfigcheck.This file contains a list of configuration files that could not beupdated automatically. These files must be checked and theconfigurations adjusted manually.

Procedure for upgrading from SLES / SLED 11 SP2There are different supported ways for updating a SUSE LinuxEnterprise 11 system to SP3 level. Users can either update to SP3 byusing the online update tools to install the respective patches or update using the SP3 installation media.

For installing SP3 via the respective patches, the following toolsare supported:

  • 1) YaST (“yast2 wagon”)
  • 2) zypper

Alternatively, the full SP3 media (DVD ISOimage) can be downloaded and one of the following procedures can be used, especially in caseof environments without network access:

  • 3) by booting from SLES for SAP 11 SP3 media

Update to SP3 via patches

Attention: The update process has to be done completely frombeginning to reboot. There is only a limited chance to revert changes.Furthermore, the server has to be connected online during thewhole update process.

Users have to makesure to have the system registered. If this is not done already, it can either be registered by using the “Novell Customer CenterConfiguration” module in YaST or by using the suse_register commandlinetool. This will add update sources to the system.

1) Update by using YaST and/or Update Applet

  • Start the Online-Update module (YOU) from the YaST control center.
  • Check, if all available patches that are named “You update for Software update stack” are installed. If this is not the case, those patches will automatically be preselected. Press ‘Accept’ to apply those updates. Among others, this will install updates of libzypp, satsolver, yast2-wagon, yast2-pkgbindings, etc.After installing those, YOU will restart itself.
  • Now it is possible to install all other updates that are availablefor SLE for SAP 11 SP2. The system needs to be rebooted afterwards, because the kernel and/or other important system components are updated.
  • Thetray applications kupdateapplet or gnome-packagekit will display amessage that a distribution upgrade is available and start the YaST2module ‘wagon’ on request. If the gnome desktop is being used, but thegnome-packagekit applet is not started automatically on login, go aheadas follows:
    • Press ALT-F2 and run ‘gconf-editor’.
    • In here, select ‘apps’ -> ‘gnome-packagekit’ -> ‘force_get_update_login’.
    • Afterthe next login the gnome-packagekit will start automatically and openup a message that a distribution upgrade is available.
  • As an alternative to using the tray application open up a root shell and run ‘/usr/sbin/wagon &’.
  • to manually start yast wagon you can also open a root shell and execute ‘yast2 wagon’
  • yast2-wagon contains a workflow to upgrade the system to the next Service Pack level. On the welcome page press “Next”.
  • yast2-wagon will do an automatic self update if needed.
  • Inthefollowing dialogue select how to migrate. Select “CustomerCenter” if the update repositories should be used, or select “Custom URL”if you want to specify the update source manually (see the respectivesection below). In most cases “Customer Center” should be the rightchoice. If you want to review the repositories changes yourself,additionally select “Check Automatic Repository Changes”. Click “Next”.
  • Are-registration of the system against the Novell Customer Center will be done. During the registrationprocess the appropriate SP3 update catalogs (SLE11-SP3-SAP-Pool, SLE11-SP3-SAP-Updates, SLES11-SP3-Pool, etc.) will be added. TheSLES for SAP 11 SP1/SP2 catalogs will be removed. Click “Next”.
  • The successdialog-popup at the end informs about which repositories were added (clickon the “Details” Button). A detailed list of the repos can be found further down in this document in the “Update via zypper” section.
  • Ifyou have selected “Check Automatic Repository Changes”, the list ofrepositories will be displayed, providing the opportunity to manuallyenable/disable/add/delete repositories. Klick “Ok” when finished.
  • A proposal screen (named “Distribution Updrade Settings”) is now listed with the following sections:
    • Add-On Products: Third Party add-on products can be added here.
    • UpdateOptions: This shows what will happen with the product. Temporarymigration products (e.g. SUSE_SLES-SP3-migration) will be removed, realproducts (e.g. SUSE_SLES) will be upgraded. Further, it can be selected, if all packages should be downloaded before upgrading (this is the default) or if the packages should be downloaded and installed one by one.
    • Packages: shows some statistics about rpm packages to update, to install and to remove.
    • Backup: some backup options.
  • Please note: If you changed your mind and want to abort the upgrade to SP3,click “Back” then “Abort”. In this case a rollback is triggered tobring the system back to SLE 11 SP2 level. Further the migrationproducts are removed, a re-registration is performed and the newlyadded repositories are removed.
  • To continue the upgrade to SP3 press “Next” -> “Start Update”.
  • The following steps are executed:
    • The update of the rpm packages is performed.
    • SuSEconfig is executed.
    • A message to reboot the system is displayed (Press “Ok”).
    • Aregistration of the final SP3 product(s) takes place. Please note that only the SLE 11 SP3 catalogs need to stay enabled.
  • After a reboot the system is on SP3 level.
1.1) Using a “Custom URL” for updating with YaST
  • Start yast2 wagon as stated above.
  • In the “Update method” dialogue select “Custom URL”.
  • Alist of repositories will be displayed, providing the opportunity tomanually enable/disable/add/delete repositories. In here it is possible to manually adjust installation- and update repositories.
  • Add the SP3 update source(s). This can either be the SP3 installation media or the new SP3 repositories (SP3-Pool and SP3-Updates).
  • Klick “Ok” when finished and continue with the “Distribution Upgrade Settings” dialogue as stated above.

2) Update by using zypper

  • Open a root shell.
  • Run ‘zypper ref -s’ to refresh all services and repositories.
  • Run ‘zypper update -t patch’ to install package management updates (same as “zypper patch”)
  • Now it is possible to install all available updates for SLES for SAP 11 SP2: run ‘zypper update -t patch’ again.
(As a sidenote: if you want to use the above command in a script for an unattended upgrade, the command would be: “zypper –non-interactive patch –auto-agree-with-licenses –with-interactive”)
  • Now the installed products contain information about distribution upgradesand which migration products should be installed to perform themigration. Read the migration product informations from/etc/products.d/*.prod and install them. Use the followingcommand:
  • zypper se -t product | grep -h — “-migration” | cut -d| -f2
  • A sample output could be as follows:
  • Install these migration product:
    • zypper in -t product SUSE_SLES_SAP-SP3-migration
  • run ‘suse_register -d 2 -L /root/.suse_register.log’ to register theproducts in order to get the corresponding SP3 Update repositories.
  • Run ‘zypper ref -s’ to refresh services and repositores.
  • Check the repositories using ‘zypper lr’. Important: if needed, disable the SP1/SP2 Pool/Core/Updates repositories manually and enable the new SP3 repositories:
    • zypper mr –disable <repo-alias>
    • zypper mr –enable <repo-alias>
  • The following repositories should be made available (please note this list contains the HAE add-on product):

  • SLES4SAP:~ # zypper lr -E

    # | Alias | Name | Enabled | Refresh


    1 | SLES-for-SAP-Applications 11.2.2-1.5 | SLES-for-SAP-Applications 11.2.2-1.5 | No | No

    2 | nu_novell_com:SLE11-HAE-SP3-Pool | SLE11-HAE-SP3-Pool | Yes | Yes

    3 | nu_novell_com:SLE11-HAE-SP3-Updates | SLE11-HAE-SP3-Updates | Yes | Yes

    4 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Pool | SLE11-SP2-WebYaST-1.3-Pool | Yes | Yes

    5 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Updates | SLE11-SP2-WebYaST-1.3-Updates | Yes | Yes

    6 | nu_novell_com:SLE11-SP3-SAP-Pool | SLE11-SP3-SAP-Pool | Yes | Yes

    7 | nu_novell_com:SLE11-SP3-SAP-Updates | SLE11-SP3-SAP-Updates | Yes | Yes

    8 | nu_novell_com:SLES11-SP3-Pool | SLES11-SP3-Pool | Yes | Yes

    9 | nu_novell_com:SLES11-SP3-Updates | SLES11-SP3-Updates | Yes | Yes
  • Then perform a dist upgrade by using the following command (example including the HAE add-on product)
    • zypper dup –from SLE11-HAE-SP3-Pool –from SLE11-HAE-SP3-Updates –from SLE11-SP2-WebYaST-1.3-Pool –from SLE11-SP2-WebYaST-1.3-Updates –from SLE11-SP3-SAP-Pool –from SLE11-SP3-SAP-Updates –from SLES11-SP3-Pool –from SLES11-SP3-Updates

      #add more SP3 catalogs here if needed, e.g. in case other add-on products are installed
  • zypper will report that it will delete the migration product and update themain products. Confirm the message to continue updating the rpm packages.
  • After the upgrade is finished, register the newproducts again:
    • suse_register -d 2 -a -a regcode-sles=insert_valid_regcode -L /root/.suse_register.log
  • Reboot the system

Update to SLES for SAP 11 SP3 via patches by using Subscription Management Tool for SUSE Linux Enterprise

As an alternative to downloading the updates for each singleclient system from the Novell update server, it is possible to useSubscription Management Tool for SUSE Linux Enterprise to mirror theupdates to a local server.

This tool acts as Novell CustomerCenter proxy both for client registrations and as software updaterepository. The SMT documentation at gives an overview of its features as well as instructions on how to implement it.

Update via using a SLES for SAP Applications 11 SP3 installation media

Please obtain the ISO images from

3) Update by booting from a SLES for SAP Applications 11 SP3 media

To start the standard update via DVD, reboot thecomputer with this medium in it’s DVD drive. Perform a systemupdate instead of a fresh installation. To achive this, select”Installation” -> Select language and keyboard layout -> Agree tothe License -> Select “Update an Existing System” instead of “New Installation”.

3.1) Update by booting off a SP3 network installationsource

It is also possible to provide the installation media vianetwork. The SLES for SAP 11 Service-Pack 3 media contains a complete product. So it can beadded to an installation server in the same way as every other SUSELINUX Enterprise product. The procedure on how to setup an installationserver and on how to addthe service pack is described in the product documentation. For SLES 11 havea look into chapter 14.2 of the deployment guide. The document isavailable online under

To start the update, go ahead as follows:

  • A bootable medium is needed to initialize the process. Booting vianetwork/PXE is also possible. For PXE boot configuration examples seechapter 14.3 in the SLES 11 deployment guide (online available at ).
  • Boot the machine and choose “Installation”.
  • Changethe installation source via the “F4” key and enter the IP and path to the installation source or select “SLP” if this protocol is configuredon your installation server.
  • Select “System Update” instead of performing a “New Installation”.


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7013242: How to unregister SUSE Manager Client

Traditional client

NOTE: This process is only for SUSE Manager clients, do not run it on the SUSE Manager itself.

First, please stop osad client on the system:

SLES 11:
rcosad stop


systemctl stop osad

In order to unregister a SUSE Manager client, several rpms must be removed. Try the following method first:

zypper rm -u spacewalksd spacewalk-check zypp-plugin-spacewalk spacewalk-client-tools osad

This will show the following:

Refreshing service ‘spacewalk’.

Loading repository data…

Reading installed packages…

Resolving package dependencies…

The following packages are going to be REMOVED:

spacewalk-check spacewalk-client-setup spacewalksd zypp-plugin-python zypp-plugin-spacewalk osad

5 packages to remove.

After the operation, 301.0 KiB will be freed.

Continue? [y/n/?] (y):

The above 5 rpm packages are client specific, and should be removed.

If this fails, please remove them manually. Do not use the following “rpm -e” commands unless the “zypper rm” command above failed.

rpm -e spacewalk-client-setup

rpm -e spacewalksd

rpm -e spacewalk-check

rpm -e zypp-plugin-spacewalk

rpm -e zypp-plugin-python

rpm -e osad

After this is complete, remove /etc/sysconfig/rhn/systemid.

That file only exists on a client machine and is used to register itself with SUSE Manager.

When this is done, refresh the repositories on the server (zypper ref -s), and then list them out (zypper lr) and make sure everything looks good.

If any repositories pointing to spacewalk still exist, remove them using the following:

zypper repos -d

zypper removerepo <ID of the repo in the output from previous command>

Salt client
Stop salt minion:
on SLES 12 stop the salt minion service using:

systemctl stop salt-minion

and on SLES 11 based systems

rcsalt-minion stop

Remove repositories and configs:
rm /etc/zypp/repos.d/susemanager:channels.repo

rm -r /etc/salt/
Delete the client RPMs of salt (as the channel data was removed before, rpm -e needs to be used here):

rpm -e salt salt-minion

Now the system can be removed from the inventory using the webUI, or from command line using spacecmd:

spacecmd system_delete FQDN

salt-key -d FQDN


7023309: Error when installing Novell-NLDAPsdk Runtime Library

This document (7023309) is provided subject to the disclaimer at the end of this document.


eDirectory on Linux


When attempting to install the Novell-NLDAPsdk Runtime Library (novell-NLDAPsdk.rpm / novell-NLDAPsdk- on a Red Hat Linux server running eDirectory, an error is displayed:
error: Failed dependencies:
novell-filesystem is needed by novell-NLDAPsdk-


As stated in the readme for the sdk, the package needs to be installed with the “nodeps” switch, in order to ignore the dependency:
These RPM were plucked directly from the OES distribution and placed here.
Unfortunately, these RPMs have a minor dependency on other RPMs distributed
with OES. Hence, installation of these RPMs will require that this minor
dependency be dropped. This is done by specifiyng the –nodeps option. For
example, to install novell-NLDAPsdk-
# rpm -i –nodeps novell-NLDAPsdk-


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7023296: General troubleshooting for client SP migration within SUSE Manager.

This document (7023296) is provided subject to the disclaimer at the end of this document.


SUSE Manager 3

SUSE Manager 3.1

SUSE Manager 3.2


A client registered to SUSE Manager needs to get updated to the following SP (please remember that the tool for a SP migration only allows that, and not major release upgrades, such as SLES 11 to SLES 12).


The following points should be checked, if possible, before the migration:
– All products/extensions/add-ons should be mirrored in the destination SP. Example: Webscripting extension is used for SLES 12 SP2, the extension should already be mirrored for SP3. Otherwise, no migration will be even suggested and a message with “no migration available” will be shown.
– The existence of foreign packages (non-SUSE) should be checked, usually coming from foreign repositories, or from manually installed RPMs. This won’t prevent the migration to start, but might make it failed due to missing dependencies. This problem can be easily and previously checked in the rpm.txt file of the supportconfig of the client, or by running:
rpm -qa –queryformat “%-35{NAME} %-35{DISTRIBUTION} %{VERSION}-%{RELEASE}n” | sort -k 1,2 -t ” ” -i | less
– Kernel multi-version should be disabled.
Further information can be found here:
Once those basic checks are performed, should further problems still exist, opening a case with Support would be expected. However, in cases where the migration failed at some point of the process, running “zypper dup” in the client will usually show the error in a verbose mode, as the client usually stays registered against the new SP channels.


The cause can be different and are explained in the resolution section. Most of the times, it is either missing channels in the target SP or dependencies problems (either foreign packages or a multi-version kernel).


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7023285: Failed dependencies during initial PAM 3.5 install on sles 12 (lsb >= 3.0)

This document (7023285) is provided subject to the disclaimer at the end of this document.


Privileged Account Manager 3.5
SUSE Linux Enterprise Server 12


During a brand new install of PAM 3.5 on SLES 12, the following error occurs:

# rpm -ihv netiq-npam-manager-3.5.0-linux-2.6-x86_64.rpm

error: Failed dependencies:

lsb >= 3.0 is needed by netiq-npam-manager-3.5.0-linux-2.6-x86_64.rpm


  1. Please resolve this dependency by upgrading lsb to >= 3.0.

    From a terminal window on the server, please enter the following command:

    zypper in lsb

  2. Verify lsb is >= 3.0:

    rpm -qa | grep lsb

  3. Then proceed with the PAM install again.


SLES 12 or other Linux server has a version of lsb < 3.0 where PAM requires >= 3.0.


Reported to Engineering

Additional Information

The following will display the version of lsb installed on the OS:
# rpm -qa | grep lsb

The following steps detail the GUI approach to upgrading this dependency:
  1. Open YaST Software Management
  2. Search for ‘lsb’
  3. Select what is available >= 3.0, in this case: ‘lsb5 – Linux Standard Base’
  4. Click Accept to Install
  5. Click Continue (automatic dependency resolutions)
  6. Click Finish


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7023149: Integration of sap-suse-cluster-connector does not work as expected

Technical Overview:

With SLES-for-SAP 12 two different versions of the SAP SUSE Cluster Connector are shipped.

This connector is used for setting up an HA cluster for SAP Netweaver Enqueue Replication according to the SAP cluster certification.

The appropriate RPM in fact is named sap-suse-cluster-connector-3.x.x-x.x.noarch.rpm

(with dashes “-” instead of underscores “_”).

It is available via the SLES-for-SAP 12 update channels. This version is needed for SAP Netweaver 7.40 and newer.

An older version comes with the SLES-for-SAP 12 DVD and the product channels and will subsequently be installed by default. It is named sap_suse_cluster_connector-1.x.x-x.x.noarch.rpm

(with underscores “_”).

This version was intended for SAP Netweaver 7.30.

If one faces an error when testing the setup like mentioned above, the most likely reason is that the necessary RPM


is not installed.

How to install the sap-suse-cluster-connector-3.x.x-x.x

The first action should be to check which package is installed, and which are available

As user root one checks with:

# zypper se /sap.suse/

S | Name |Summary


| sap-suse-cluster-connector | SUSE High Availability Setup for SAP Products

i | sap_suse_cluster_connector | Connector between sapstartsrv and corosync/pacem…

# zypper se -t package –details /sap.suse/

S | Name | Type | Version | Arch | Repository


| sap-suse-cluster-connector | package | 3… | noarch | SLE-12-SP2-SAP-Updates

i | sap_suse_cluster_connector | package | 1… | noarch | SLE12-SP2-SAP-Pool

if there is no sap-suse-cluster-connector package available then there are no update channels. In this case one should contact the Linux System Administrator and ensure that the proper update channels are available.

The next step is the Removal of the old package

As user root one does:

# zypper rm sap_suse_cluster_connector

then install the new package

# zypper in sap-suse-cluster-connector

# zypper se -t package –details /sap.suse/

S | Name | Type | Version | Arch | Repository


i | sap-suse-cluster-connector | package | 3… | noarch | SLE-12-SP2-SAP-Up…

| sap_suse_cluster_connector | package | 1… | noarch | SLE12-SP2-SAP-Pool

Alternatively one could just invoke

# zypper in sap-suse-cluster-connector

and then let zypper resolve the error by deinstalling the older sap_suse_cluster_connector.

Activation of new package

it is necessary to restart the sapstartsrv process associated with the SAP Instance.

To do this first the process is identified with

ps aux | grep <SID>adm | grep sapstartsrv

which results in an output like this, in this example the SID is HA1

ardmore:~ # ps aux | grep ha1adm | grep sapstartsrv

ha1adm 561 20.0 0.1 864312 76092 ? Ssl 16:09 0:00 /usr/sap/HA1/SYS/exe/run/sapstartsrv pf=/sapmnt/HA1/profile/HA1_ASCS00_sapro0as -D -u ha1adm

the process is then killed with

kill -9 <PID-sapstartsrv>

in the above example

kill -9 561

and then the log is checked for an entry like

Jul 03 16:11:58 ardmore SAPInstance(rsc_sap_S97_ASCS97)[12599]: INFO: sapstartsrv for instance HA1-S00 was restarted !

which confirms that the sapstartsrv is restarted

Verification of installed package

As user <sid>adm one does:

# sapcontrol -nr <instance_nr> -function StopService

# sapcontrol -nr <instance_nr> -function StartService <SID>

# sapcontrol -nr <instance_nr> -function HACheckFailoverConfig



state, category, description, comment

SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version,

SAPInstance includes is-ers patch

Optional restart of cluster resource agent

Usually the cluster connector should have been tested before integration with the cluster. In case the cluster already is running, the resource agent should be restarted. For details, the respective cluster documentation explains this.