Invalid Login Issue on MCS Provisioned Linux Machines with Winbind

To fix this issue on SUSE 12.3, you downgrade the version of samba on your template machine using the following command:

sudo zypper in -f samba-4.6.7+git.51.327af8d0a11-3.12.1

After this, update your machine catalog using the new master image.

On RHEL 7.4, you need to create a new template machine, then use the following command to restrict the package version:

echo ‘7.4’ >/etc/yum/vars/releasever

If your system is not registered or using other repos, you can install specific version of samba and lock it with yum version lock.

yum install yum-plugin-versionlock

yum install samba-winbind-clients-4.6.2-12.el7_4.x86_64

yum versionlock samba*

If there are other packages fail to install due to this version of samba, you need to install their lower versions accordingly.

Update on RHEL 7 Platform

RHEL team has fixed this issue in their latest samba package: 4.7.1-9.el7_5. However, after upgrading to this samba version, you will still get invalid login error. To solve this issue, in the template machine, you need to add a line in /var/xdl/mcs/, in function join_domain(), find the line:


add a line below:


After this, create a new snapshot of the template machine and update machine catalog using this snapshot.


7018416: Clear cache on SUSE Manager Proxy

proxyclient3:/etc/ssl/certs # zypper ref -s

All services have been refreshed.

Repository ‘SLES11-SP4-Pool for x86_64’ is up to date.

Retrieving repository ‘SLES11-SP4-SUSE-Manager-Tools x86_64’ metadata []

Warning: Digest verification failed for file ‘updateinfo.xml.gz’


expected 0fe3250dcca441ff3ec9d5935982e7e12af3690d

but got bca670744a56453e847c669b705bb7939a2c399e

Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.

However if you made certain that the file with checksum ‘bca6..’ is secure, correct

and should be used within this operation, enter the first 4 characters of the checksum

to unblock using this file on your own risk. Empty input will discard the file.

Unblock or discard? [bca6/? shows all options] (discard):


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.


7023356: The boot.log file is missing with s390x systems

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


SUSE Linux Enterprise Server 12 Service Pack 1 (SLES 12 SP1)

SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)

SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)


There is no /var/log/boot.log file found / present on s390x systems.


Not having a /var/log/boot.log file created is by default expected with IBM Z systems.


The Plymouth services are failing on s390x IBM Z Systems with SLES12SPx since these systems do not have any graphics components.

Additional Information

As an alternative it is possible to get the /var/log/boot.log created by removing the plymouth package and instead adding the package blog-plymouth:
zypper rm plymouth plymouth-dracut

zypper in blog blog-plymouth
On reboot the /var/log/boot.log should then be created. Also see the SLES12 SP3 Release Notes.


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.


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


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.


7023233: Boot fails or gives errors after Update

Most times this stems from the fact that an update was done on specific packages, like for example

zypper up kernel-default

zypper up glibc

zypper up systemd

but none on dracut, udev and any other packages where updates might also be available.

The impeded system can be brought into working condition again by a skilled Linux System Administrator, but this is an unnecessary interrupt to services.

If there is an update for a package, there is a good chance that this will for a seamless integration also require an update to other packages.

It is generelly recommended to do

zypper patch

and update all and every installed package on the system to prevent any incoherence in the system. This is especially true for everything connected to boot and root filesystem and base system like for example