7023490: os-release inconsistencies in SLES for SAP Applications

There are no fixes involved. This document is merely to provide information on what to expect in the os-release file depending on the installed version.

Fresh installs of SLES for SAP Applications produce the following os-release syntax and products.d contents:-

————————————————————————————————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”12″

VERSION_ID=”12″

PRETTY_NAME=”SUSE Linux Enterprise Server 12″

ID=”sles”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles:12″

/etc/products.d # ls -l

total 16

-rw-r–r– 1 root root 2705 Oct 14 2014 SLES.prod

-rw-r–r– 1 root root 2839 Apr 23 2015 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 15:41 baseproduct -> SLES_SAP.prod

-rw-r–r– 1 root root 1598 Oct 2 2014 sle-ha.prod

——————————————————

# cat /etc/os-release

NAME=”SLES_SAP”

VERSION=”12-SP1″

VERSION_ID=”12.1.0.1″

PRETTY_NAME=”SUSE Linux Enterprise Server for SAP Applications 12 SP1″

ID=”sles_sap”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp1″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 2854 Mar 15 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 15:05 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES_SAP”

VERSION=”12-SP2″

VERSION_ID=”12.2″

PRETTY_NAME=”SUSE Linux Enterprise Server for SAP Applications 12 SP2″

ID=”sles_sap”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp2″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 3080 Mar 30 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 13:11 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”12-SP3″

VERSION_ID=”12.3″

PRETTY_NAME=”SUSE Linux Enterprise Server 12 SP3″

ID=”sles”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp3″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 2972 Jul 24 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 12:31 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”15″

VERSION_ID=”15″

PRETTY_NAME=”SUSE Linux Enterprise Server 15″

ID=”sles”

ID_LIKE=”suse”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles:15″

linux-mpxw:~ #


/etc/products.d # ls -l

total 28

-rw-r–r– 1 root root 3185 May 30 05:23 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Oct 31 11:46 baseproduct -> SLES_SAP.prod

-rw-r–r– 1 root root 3197 May 30 05:23 sle-ha.prod

-rw-r–r– 1 root root 1892 May 30 05:23 sle-module-basesystem.prod

-rw-r–r– 1 root root 2264 May 30 05:23 sle-module-desktop-applications.prod

-rw-r–r– 1 root root 2315 May 30 05:23 sle-module-sap-applications.prod

-rw-r–r– 1 root root 2351 May 30 05:23 sle-module-server-applications.prod

——————————————————

This leaves us with the question ‘How do we identify the ‘base product’ of a server?”.

The correct way to do this is is by examining the contents of /etc/product.d directory (and look at which product file the link ‘baseproduct’ is pointing too).

Related:

  • No Related Posts

7023378: freshclam reports wrong exit status after clamav update

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

Environment

SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)
clamav-0.100.0-33.12.1
SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)
clamav-0.100.0-0.20.12.2

Situation

After updating to clamav, freshclam reports a wrong exist status after an update without refreshing the patterns:

clamclient:~ # freshclam -v

Current working dir is /var/lib/clamav

Max retries == 3

ClamAV update process started at Wed Sep 26 14:46:50 2018

Using IPv6 aware code

Querying current.cvd.clamav.net

TTL: 931

Software version from DNS: 0.100.1

WARNING: Your ClamAV installation is OUTDATED!

WARNING: Local version: 0.100.0 Recommended version: 0.100.1

DON’T PANIC! Read https://www.clamav.net/documents/upgrading-clamav

main.cvd version from DNS: 58

main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr)

daily.cvd version from DNS: 24983

daily.cld is up to date (version: 24983, sigs: 2100133, f-level: 63, builder: raynman)

bytecode.cvd version from DNS: 327

bytecode.cld is up to date (version: 327, sigs: 91, f-level: 63, builder: neo)

clamclient:~/PTF-2018-Sep-07-09:38:00 # echo $?

1

According to man (1) freshclam, the exit status should be zero if the database was successfully refreshed or up-to-date.

Resolution

Please contact SUSE Technical Services for a Program Temporary Fix (PTF).

Cause

The issue was introduced unintentionally in the upstream project while changing the return codes for the downloader which in return affected the exit code of freshclam.

Status

Reported to Engineering

Additional Information

Disclaimer

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.

Related:

7023375: NVMe drive label changes after reboot

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

Environment

SUSE Linux Enterprise Server 15

Situation

After installation of SLES 15, NVMe drive labels are changing after each reboot. For example, nvme0n1 could be an NVMe Drive with 800GB capacity and nvme1n1 is another NVMe drive with 1.6TB capacity in one instance of boot. When the system is rebooted, nvme0n1 could be drive with 1.6TB Capacity and nvme1n1 could be drive with 800GB capacity.

Steps to reproduce:
1- Attach 3-4 NVMe drives to the server.
2- Install and boot into os.
3- Check Major and Minor numbers of NVMe devices and note them to compare with the next reboot instance.
4- Reboot the server and compare Major and Minor numbers to previous boot.
5- Repeat step-4 for 4-5 times and observe the device label change.
Note: This behavior was not seen in SLES 12 SP3.

Resolution

This is the expected behavior for SLE 15 even though it is different from SLES 12 SP3. The device label can get changed on reboots and there is no relation between NVMe controller numbering and NVMe block device numbering.

As an alternative, using UUIDs is recommended in the Storage Administrator Guide as well, see:https://www.suse.com/documentation/sles-12/singlehtml/stor_admin/stor_admin.html#cha.uuid

Disclaimer

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.

Related:

7023373: SMT – Error: Unable to request next job: 500 Access to ‘http’ URIs has been disabled

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

Environment

SUSE Linux Enterprise Server 11

SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 15

Subscription Management Tool

Situation

The SMT (Subscription Management Tool) server is reporting the following error message related to the jobs:

Error: Unable to request next job: 500 Access to ‘http’ URIs has been disabled-

The above error will also show on the Client when the smt-agent command is launched manually.

Resolution

A configuration file must be changed on the Client so the first step is to create a backup copy of the file:

– On SUSE Linux Enterprise Server (SLES) 11 based Clients run:

# cp -p /etc/suseRegister.conf /etc/suseRegister.conf.BCK

– On SLES 12 and 15 based Clients run:

# cp -p /etc/SUSEConnect /etc/SUSEConnect.BCK

Then edit the file and change “http” for “https” (without the quotation marks) in the “url” line, so after the change the line should look as follows:

– On SLES 11 based Clients:

url=https://<YOUR-SMT-FQDN-HERE>/center/regsvc

– On SLES 12 and 15 based Clients:

url: https://<YOUR-SMT-FQDN-HERE>/

Save the changes and exit the editor.

Finally run the smt-agent command on the Client to check if the error is still showing up:

# smt-agent

If working the above command will not show any output.

Cause

Communication via HTTP for the SMT servers jobs is disabled by default, hence the error. All communications must be only via HTTPS and cannot be changed to work with HTTP.
The registration of the Client was done using HTTP or the configuration file was changed manually to use HTTP, verify the procedure and commands being used to register Clients against the SMT server and be sure to always use the SMT’s FQDN (Fully Qualified Domain Name) and HTTPS instead of HTTP.

Disclaimer

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.

Related:

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/Migrate_SLES_to_SLES-for-SAP.sh

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.

Related:

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.

Environment

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)

Situation

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

Resolution

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

Cause

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
mkinitrd
On reboot the /var/log/boot.log should then be created. Also see the SLES12 SP3 Release Notes.

Disclaimer

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.

Related:

7023361: Installing SLES 11 SP4 using AutoYaST on Intel RSTe BIOS RAID Failed

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

Environment


SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)

Situation

Installing SLES 11 SP4 on Intel RSTe BIOS RAID (Fake RAID) manually works fine without issues but when using the generated AutoYaST file to rollout installation on new machines the installation failed and admininstator getting: Error while configuring partitions. Try again. error message.

Resolution

  1. Make sure there aren’t any existing partitions on the drives.
  2. Blacklist the dm-mod module during autoyast install.

This can be done by passing BrokenModules=+dm-mod to kernel option line before calling autoyast file.

Additional Information

Disclaimer

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.

Related:

7023363: Getting error updating database in Vibe 4.0.5

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

Environment

Vibe 4.0.5

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

SUSE Linux Enterprise Server 15

Situation

When running the ./manage-database.sh database_type updateDatabase command to update the database getting the following error:

Unexpected error running Liquibase: org/kablink/liquibase/change/custom/Mirgrate/MirroredFoldersChange has been compiled by a more recent version of the Java Runtime (class file version 54.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Resolution

Vibe 4.0.5 installs JDK 10 automatically. if you are gettting this error, it is looking at the old path for JDK. Before you run the updateDatabase command, enter in the correct path variable:

PATH=/opt/novell/teaming/jre/bin:$PATH

Disclaimer

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.

Related:

7023314: Newest kernel-xen updates on dom0 makes guests fail to start

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

Environment

SUSE Linux Enterprise Server 11

SUSE Linux Enterprise Server 12

Situation

Since the new updates for xen the domU’s are not starting and crashing:
(XEN) d2 L1TF-vulnerable L1e 000000003bd63160 - Shadowing

(XEN) d2 Failed to enable PG_SH_forced: -12
(XEN) domain_crash called from common.c:3964
(XEN) Domain 2 reported crashed by domain 32767 on cpu#0:

Resolution

As a workaround disable autoballooning on dom0, which is enabled by default.

Add autoballoon=0 to /etc/xen/x1.conf

https://www.suse.com/documentation/sles-12/book_virt/data/sec_xen_vhost_memory.html

As soon as a permanent fix is available this Bulletin will be updated

Cause

This is caused by the implementation of the L1TF mitigation fixes.

Disclaimer

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.

Related:

7023306: Error: Registration server returned ‘Error while deleting the system ‘ (500)

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

Environment

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

Situation

A system is registered against an SMT Server. Trying to de-register the server with

SUSEConnect –de-register
returns the following error:

Error: Registration server returned ‘Error while deleting the system ‘ (500)

Resolution

On the SMT server check /etc/smt.conf for the Mirror credentials found under:
NUUser
NUPass
Compare these with the ones found in SUSE Customer Center by selecting your Organization and then the Proxy Tab.
The Mirror credentials are in the right upper corner.

Disclaimer

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.

Related:

  • No Related Posts