Upgrade of a server host from Opensuse Leap 15.1 to 15.2 – II – smartd configuration, 3ware controllers, mdadm RAID

During the upgrade of one of my server systems from Opensuse Leap 15.1 to 15.2 I noticed that the smartd-daemon did not start successfully. Logs revealed that the upgrade itself was NOT the cause of this failure; it is nevertheless a good occasion to briefly point out how one can configure the smartd-daemon to keep an overview over the evolution of disk properties on a Leap 15.X system - even when the disks are an integral part of one or more Raid-arrays. "Overview" is also a reason why I use "rsyslog" in addition to a pure systemd journal log to track the SMART data.

A problem with a 3ware based Raid array

The main cause of the smartd-failure on the upgraded server was an active line with the command "DEVICESCAN" in Opensuse's version of the configuration file "/etc/smartd.conf". As the command's name indicates, the system is scanned for disks to monitor. Unfortunately, smartd did not find any SMART enabled devices on my server.

Feb 05 17:01:55 MySRV smartd[14056]: Drive: DEVICESCAN, implied '-a' Directive on line 32 of file /etc/smartd.conf
Feb 05 17:01:55 MySRV smartd[14056]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Feb 05 17:01:55 MySRV smartd[14056]: Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting...

Well, this finding was correct. All internal disks of the server were members of Raid arrays on elderly 3ware controllers. 3ware controllers are supported by the Linux kernel - in my case via a module "3w_9xxx". During the installation an Opensuse Leap system the driver module was automatically added to the configurations of GRUB, the initramfs and the list of modules loaded by the eventually booted kernel. Upgrades have respected the configuration so far.

But with hardware RAID controllers the attached individual disks are NOT directly accessible to standard "smartd" directives or a standard plain "smartctl" command. You need to a special options. The HW-RAID-array is seen by the Linux system and smartd as a block device - without an inner structure. And the block device corresponding to the HW-controlled RAID-array has no SMART capabilities - which is, of course, very reasonable. Thus DEVICESCAN fails.

I wondered a bit why I had not seen the problem on the same system with Leap 15.1. Actually, this was my fault: Looking into a backup I saw in the last logs of the host during its time with Leap 15.1 that the problem had existed already before the upgrade - and was caused by an old, original "smartd.conf"-file from SuSE with which I had accidentally overwritten my own version of "smartd.conf". Stupid me! But the really concerning thing was that I should have noticed the consequences in some logs. But, since I became a almost full-time employee I have been too lazy to work regularly with specific filter-options of systemd's command "journalctl" - so I missed the relevant messages within the flood of messages in the journal. Time to reactivate rsyslog to get specific information into specific files - see below.

Anyway ... It is reasonable that the failure of a standard DEVICESCAN should lead to a failure of the smartd service. The attentive admin thus gets a clear hint that his intention to watch disk health variables is not working as expected - even if the "smartd.conf" should contain other valid lines. The comments in "/etc/smartd.conf" clearly say:

# The word DEVICESCAN will cause any remaining lines in this configuration file to be ignored: 
# it tells smartd to scan for all ATA and SCSI devices. DEVICESCAN may be followed by any of the
# Directives listed below, which will be applied to all devices that are found.
# Most users should comment out DEVICESCAN and explicitly list the devices that they wish to monitor.

I changed the line breaks a bit to stress the last statement. The obvious and trivial solution in my case was to comment out the DEVICESCAN-line and activate some explicit statements for the individual disks in the 3ware array. To make things a bit more interesting, let us look at a different system MySYS which uses a combination of 3ware controlled hard-disk arrays and mdadm controlled SSD-arrays.

The server host discussed above does not require a particular high disk throughput. Storage capacity in TB is more important. Actually, I would never buy a 3ware or LSI controller again for a semi-professional Linux machine. Too much money for a too low performance. With Linux you are certainly better off with mdadm and SW-RAID on a modern multi-core-processor. The general impact on an i7 or i9 on the overall performance is negligible in my experience. Especially, when you have a lot of fast RAM. In addition mdadm gives you much (!) more flexibility. You can, for example, build a set of multiple RAID-arrays working in parallel with one and the same stack of disks/SSDs by assigning different partitions to different distinct arrays - which may even be of a different type. But this is another story ...

Entries for disks attached to 3ware controllers and SSDs in mdadm-Raid-arrays in the "/etc/smartd.conf" file

In the system MySRV I use a configuration

  • of multiple mdadm RAID-arrays consisting of assigned SSD-partitions of a stack of 4 SSDs
  • and 4 conventional hard-disks attached to a 3ware controller, forming a RAID 10-array.

In addition the host contains a further stand alone SSD.

For disks attached to a 3ware-controller we need a special form of the directives in the "smartd.conf"-file. Actually, some examples for such directives are given in a 3ware-related commentary section of "/etc/smartd.conf". You may find something directly suitable for your purposes there.

What about devices which are members of mdadm-controlled SW-Raid arrays? Well, the nice thing is that in contrast to HW-controlled Raid-disks the SMART-daemon can access SSDs (or hard disks) on a mdadm-controlled SW-Raid-array directly! Without any special options! Actually, folks familiar with "mdadm" would have expected this for very basic reasons ... But this is yet another story ... We just accept the fact as one example ofthe power of Linux.

Thus, for my special system MySYS I just disabled the line with "Devicescan" and inserted the following lines into "/etc/smartd.conf":

DEFAULT -d removable -s (S/../../7/03)
# Monitor SSDs contributing to different mdadm based SSD-Raid-arrays via (vertical) stacks of partitions 
/dev/sda -d sat -a -o off
/dev/sdb -d sat -a -o off
/dev/sdc -d sat -a -o off
/dev/sdd -d sat -a -o off

# Monitor additional stand alone SSD 
/dev/sde -d sat -a -o off

# Monitor HDs attached to 3ware controller with a Raid 10 configuration 
/dev/twa0 -d 3ware,0 -F samsung -a -o off
/dev/twa0 -d 3ware,1 -F samsung -a -o off
/dev/twa0 -d 3ware,2 -F samsung -a -o off
/dev/twa0 -d 3ware,3 -F samsung -a -o off

Disclaimer: Never copy the statements and later discussed smartctl-commands above without a thorough study of the literature and documentation on smart, smartctl and smartd. Check the preconditions of applying the directives and commands carefully with respect to your actual HW-/SW-configuration and the type of SSDs and hard disks used there! You have to find out about the correct settings for your system-configuration on your own.
Warning: The effects of the "-a" option and especially of the planned automatic disk tests initiated via the "DEFAULT"-statement may be different for SCSI or SATA-disks. Some options may even lead to data loss on older Samsung disks. I will not take any responsibility for any problems caused by applying the settings displayed above to YOUR systems. Get advice of a professional regarding RAID-configurations and smartctl ahead of any experiments.

Having this said, the expert sees that I plan short self tests of the disks on every Sunday at 3 AM. Such tests will temporarily reduce the performance of the affected disks and as a consequence also of the various RAID-configurations the disk or any of its partitions might be a part of. At least on my system such a test will, however, not render the defined RAID-arrays unusable.

I could test this for a SATA-device and mdadm e.g. by using a suitable smartctl-command as

smartctl -t short /dev/sdc

and watching the continuing operation of a related RAID-array by

mdadm -D /dev/mdxxx

The corresponding smartcl-command for a 3ware RAID-disk would e.g. be

smartctl -t short /dev/twa0 -d 3ware,3 -F samsung.

As said above: Be careful with such tests on productive systems.

By the way: Only for the 3ware disks you may get an information about the starting of the test in a smartd related log-file (see below). If no errors are found, the logs will NOT show any special message.

At least on an Opensuse system the other settings and options for the various disks are discussed and explained in the commentary sections of the file:

#   -d TYPE Set the device type: ata, scsi, marvell, removable, 3ware,N, hpt,L/M/N
#   -o VAL  Enable/disable automatic offline tests (on/off)
#   -H      Monitor SMART Health Status, report if failed
#   -l TYPE Monitor SMART log.  Type is one of: error, selftest
#   -f      Monitor for failure of any 'Usage' Attributes
#   -p      Report changes in 'Prefailure' Normalized Attributes
#   -u      Report changes in 'Usage' Normalized Attributes
#   -t      Equivalent to -p and -u Directives
#   -a      Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198
#   -F TYPE Use firmware bug workaround. Type is one of: none, samsung


# Monitor 4 ATA disks connected to a 3ware 6/7/8000 controller which uses
# the 3w-xxxx driver. Start long self-tests Sundays between 1-2, 2-3, 3-4, 
# and 4-5 am.
# NOTE: starting with the Linux 2.6 kernel series, the /dev/sdX interface
# is DEPRECATED.  Use the /dev/tweN character device interface instead.
# For example /dev/twe0, /dev/twe1, and so on.
#/dev/sdc -d 3ware,0 -a -s L/../../7/01
#/dev/sdc -d 3ware,1 -a -s L/../../7/02
#/dev/sdc -d 3ware,2 -a -s L/../../7/03
#/dev/sdc -d 3ware,3 -a -s L/../../7/04

On my system (with one a 3ware controller and mdadm Raid-arrays) the smartd daemon started without any problems afterwards.

Configure rsyslog to write smartd-information into a distinct separate log-file

Old fashioned as I am, I use rsyslog aside systemd's journal-logging. rsyslog can easily be configured to write log entries for selected daemons/processes into predefined separate log-files. Such files can directly be opened as they are plain text-files. Let us configure rsyslog for the smartd daemon:

  • Step 1: We create an empty file "/var/log/smartd.log" (as root) on the host in question by the command

    "touch /var/log(smartd.conf"

  • Step 2: Change rights by "chmod 640 /var/log/smartd.log"
  • Step 3: Add the following line to the file "/etc/rsyslog.conf" (close to the end)

    :programname, isequal, "smartd" /var/log/smartd.log

  • Step 4: Restart the rsyslog-daemon by "systemctl restart rsyslog"

You surely have noticed that this is for local logging. But it is easy to adapt the settings to logging on remote systems.

What do smartd-logs look like?

Depending on your hardware you may get specific messages for your devices at the start of the smartd-daemon. Depending on the execution of scheduled self-tests you may get some messages about starting such test. After some time you should (hopefully) see successful messages regarding short or long self-tests - depending on your settings. In my case:

2021-02-11T14:29:43.511950+01:00 MySYS smartd[1723]: Device: /dev/sda [SAT], previous self-test completed without error
2021-02-11T14:29:44.026256+01:00 MySYS smartd[1723]: Device: /dev/twa0 [3ware_disk_00], previous self-test completed without error

In addition that you will get continuous information about changes of variables describing the health-status of your disks. In my case only the variation of the temperature due to changing airflow is shown:

2021-02-11T14:59:43.340341+01:00 MySYS smartd[1723]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 76 to 78
2021-02-11T14:59:43.350339+01:00 MySYS smartd[1723]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 77 to 78
2021-02-11T14:59:43.353660+01:00 MySYS smartd[1723]: Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 77 to 79
2021-02-11T14:59:43.357007+01:00 MySYS smartd[1723]: Device: /dev/sdd [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 77 to 79
2021-02-11T14:59:43.360136+01:00 MySYS smartd[1723]: Device: /dev/sde [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 77 to 78


If for some reason the "smartd"-daemon and the related service does not start on a Linux host with Opensuse Leap 15.2 it is easy to get it running again. Even, when your disk devices are members of RAID arrays. The configuration file "/etc/smartd.log" contains a lot of hints how to set up reasonable directives regarding various HW-RAID-controllers supported by the kernel. A really good thing is that we do not need any special commands or options regarding disk devices whose partitions are members of mdamd-controlled SW-RAID arrays.




Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing

In these times of Corona, home-office and of increased Internet usage some of us Linux guys may experience an old phenomenon: screen and video tearing. In my case it happened with an Nvidia card and with X11 (Wayland does not yet work on my Opensuse Leap 15.1 - I am too lazy to investigate why). I have ignored the tearing already for some months - but now it really annoyed me. I saw tearing already some years ago; at that point in time activating triple buffering helped. But not these days ...

Where did I see the tearing?

I observed tearing effects

  • when moving "wobbling windows" (one of KDE's desktop effects) across the screen - strangely enough when moving them slowly,
  • when watching TV and video streams in browsers (independent of FF, Opera or Chromium) - mostly when major parts of the video changed quickly.

Not much, not always - but enough to find it annoying. So, I invested some time - and got rid of it.

Driver and contents of the xorg.conf file

Driver: Latest Nvidia driver from Opensuse's NVidia Repository: nvidia-glG05, x11-video-nvidiaG05.

I have three screens attached to my NVidia card (GTX 960); two of them are of the same type, but one has a lower resolution than the others. The screens are configured to work together as a super wide screen via the Xinerama setting in the xorg configuration file. Below, you find the contents of the file "/etc/X11/xorg.conf" with details about the screen configuration and modes.


# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 450.80.02

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"

Section "Files"

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
    Option         "DPMS"

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 960"

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "ForceFullCompositionPipeline"  "on"
#    Option         "ForceCompositionPipeline"  "on"
    Option         "metamodes" "DP-4: nvidia-auto-select +0+0, DP-0: nvidia-auto-select +2560+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1920x1080 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1680x1050 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1600x1200 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1440x900 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x1024 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x960 +5120+0"
    Option         "SLI" "Off"
    Option         "TripleBuffer" "True"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24


The most important statement regarding the suppression of tearing is

    Option         "ForceFullCompositionPipeline"  "on"


    Option         "ForceCompositionPipeline"  "on"

seems to work equally well. Use the latter, if your graphics should react a bit sluggish.

We find more information about these options in the "nvidia-settings" application:

When you move your mouse over the option for "ForceCompositionPipeline" and "ForceFullCompositionPipeline", you get

The Nvidia driver can use a composition pipeline to apply Xscreen transformations and rotations. "ForceCompositionPipeline" can be used to force the use of this pipeline, even when no transformations or rotations are applied to the screen. This option is implicitly set by ForceFullCompositionPipeline.

and, respectively,

"This option implicitly enables "ForceCompositionPipeline" and additionally makes use of the composition pipeline to apply ViewPortOut scaling."

Important: If you want to test the setting via nidia-settings, you have to activate the options it for all three screens!.

When I first tested "ForceCompositionPipeline" I just set it on the page of "nvidia-settings" for the first screen of my three, wrongly assuming that this setting was applied in general. However, tearing did not disappear. I realized after some time that it still happened on 2 screens predominantly. I even suspected a different quality of the display-port cables to my screens to be the cause of tearing. Wrong ... the ForceCompositionPipeline had been applied to one screen, only.

So, switch to the other screens by using the first combo-box on the "nvidia-settings"-page and set "ForceCompositionPipeline" for all screens. Do this before you eventually save the settings to a "xorg.conf"-file (as root). Your resulting xorg.conf file may look a bit different; the CompositionPipeline-settings might be included as a side-option of the meta-mode settings - and not in form of a special separate line as shown above.

Regarding Xvideo- and OpenGL-settings you should activate syncing;

KDE Plasma settings

KDE Plasma settings for the screens should be consistent with the "nvidia-settings". You use KDE's "system-settings" >> "Display and Monitor" >> "Displays" and "Compositor".

The combination of all the settings discussed above worked in my case - the tearing disappeared for videos in browsers, in video applications as well as on the Xinerama KDE Plasma screen in general.


It is easy to suppress video and screen tearing on an Opensuse Leap system with KDE PLasma and a Nvidia graphics card. The most important point is to activate "ForceCompositionPipeline" on all individual screens via "nvidia-settings" or to activate this option globally for the Xinerama screen of a multi-monitor configuration.

Bumblebee for Optimus systems on Opensuse 15.1

Recently, I upgraded a laptop from Opensuse Leap 15.0 to Leap 15.1. I successfully followed the upgrade procedure described by the Linux Kamarada in

kamarada: how-to-upgrade-from-opensuse-leap-150-to-151/ .

The only problems I got had to do with the Optimus-design of my old laptop. When I followed my own description how to install and use Bumblebee as described in

Installation Opensuse Leap 15 auf Laptop – Grafik Probleme, Optimus

I always got an error message when trying to load the nvidia kernel module:

mytux:~ # sudo modprobe nvidia

modprobe: ERROR: could not insert 'nvidia': No such device

The reason was given by the command "dmesg"; the Nvidia device was no longer available on the PCI bus:

NVRM: The NVIDIA GPU 0000:01:00.0
               NVRM: (PCI ID: 10de:134d) installed in this system has
               NVRM: fallen off the bus and is not responding to commands.
[    3.312435] nvidia: probe of 0000:01:00.0 failed with error -1

The bbswitch-module could, however, be loaded without any problems.


A workaround is described in here :

After having started KDE or Gnome issue the following commands as root in a terminal:

mytux:~ # echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
mytux:~ # echo 1 > /sys/bus/pci/devices/0000:00:02.0/rescan

Afterwards my Nvidia card (640M) was available on the bus again - and e.g. "primusrun glxgears" worked.

So, something with starting the dkms.service and the bumblebeed.service, switching off the Nvidia card by the bbswitch module during system startup and later on loading of the nvidia-module was failing. I suspected the bbswitch-module to be the cause ...


In my case I could solve the problem by installing the RPM packets

bumblebee, dkms, bbswitch, bbswitch-kmp-default

from the standard Update repository of Opensuse Leap 15.1


instead of installing them from the Bumblebee-repository


Otherwise I followed the instructions in
Installation Opensuse Leap 15 auf Laptop – Grafik Probleme, Optimus .

I.e.: I installed only the packets

nvidia-bumblebee, nvidia-bumblebee-32bit

from the Bumblebee repository.

Do not forget to issue a "mkinitrd" after you have successfully tested e.g. "optirun glxgears" and "tee /proc/acpi/bbswitch <<< OFF". Then reboot and use Optimus as you were used to. I do not know what is wrong with the packets in the Bumblebee repository - but I hope this bug is fixed soon. It is a bit annoying when one has to play around with packets of different repositories.

Addendum, 03.08.2020: A problem with VirtualGL

The present Bumblebee repository of Opensuse contains a new version of the VirtualGL library (version 2.6.4). Do NOT install this RPM-file. It will break your optirun/primusrun with an error:

Error: undefined symbol: glXGetProcAddressARB

Although this type of error is discussed in various forums on the Internet I have no clue how to mend it.

Workaround: Use the original VirtualGL RPM of the Opensuse Leap 15.1 Update repository! Works on my system.