Category Archives: Opensuse

Opensuse Leap 42.1 – nerviger YaST Bug

Posted on by

Auf meinem Mehrschirm-Arbeitsplatz offenbarte sich in den letzten Tagen ein sehr nerviger Bug von YaST:

Startet man YaST (yast2) über das Startmenü, authentifiziert sich danach als root und ruft dann die “Softwareverwaltung auf, so geschieht u.U. und erratisch Folgendes: Das Fenster für die SW-Verwaltung öffnet sich, die Repositories werden eingelesen und das Fenster strong>schließt sich sofort wieder.

Das passiert nicht, wenn man “yast2” als root über ein Terminal startet, u.U. aber auch sehr wohl, wenn man als normaler User in einem Terminalfenster “/usr/bin/xdg-su -c /sbin/yast2” absetzt.

Es hat mich ein Weilchen gekostet herauszufinden, unter welchen Umständen dieser Bug überhaupt auftritt:

Es geschieht nur in Mehrbildschirm-Konfigurationen und immer nur dann, wenn YaST nicht von der Kontroll-Leiste des Hauptschirms gestartet wird. Oder: Wenn das anschließend gestartete YasT-Übersichts-Fenster auf einem anderen als dem Hauptschirm positioniert wird. Dito für den Start über ein Terminalfenster.

Workaround:
Das grafische YaST unter Leap 42.1 z.Z. immer über das Startmenü des Hauptbildschirms starten. Das sich öffnende YaST2-Übersichtsfenster anschließend auf den Hauptschirm verschieben, falls es nicht dort geöffnet worden sein sollte. Erst dann die Softwareverwaltung aufrufen.

Na, es wird wohl noch eine Weile dauern, bis Leap mit KDE 5 so stabil sein wird wie Opensuse 13.2! es ist bei weitem nicht so schlimm wie bei der Einführung von KDE 4.0 oder systemd. Aber bei dem einen oder anderen Erlebnis der letzten Tage werden bei mir jedenfalls finstere Erinnerungen wach ….

Opensuse Leap 42.1- grafischer Login als root

Posted on by

Opensuse setzt wie andere Distributionen aus Sicherheitsgründen darauf, dass “root” möglichst nicht unter dem X-Window-System arbeiten soll. Das ist natürlich sehr vernünftig – blockiert aber ggf. Anfänger bei der notwendigen Durchführung elementarer Aufgaben.

Hinzu kommen manchmal banale Dinge – wie etwa aktuelle KDE Fehler. So erscheinen z.Z. im aktuellen KDE 5 Desktop von Leap 42.1 diverse GTK-Applikationen, die man als User root von einem Terminalfenster aus startet, mit deutlich kleineren Standardfonts als der Fontgröße, die die man für die eigene User-Oberfläche (und QT-Anwendungen) aber auch für GTK-Styles und GTK-Anwendungen eingestellt hat.

Das gilt für YaST, die “systemsettings5” aber z.B. auch für das VMware User-Interface. Startet man YaST2 als normaler User etwa über

/usr/bin/xdg-su -c /sbin/yast2

so werden die Fonts in der erwarteten, voreingestellten Größe dargestellt. Loggt man sich dagegen als root auf einem Terminalfenster ein und startet dort am Prompt “yast2 &”, so erscheinen die Fonts wesentlich kleiner (und pixeliger). Die fehlerhafte Anzeige passiert auch, wenn man als User root die (root-eigenen) Fonts und GTK-Stile über die “Systemeinstellungen” bereits geändert hat. Das alles war beim KDE 4.14 unter Opensuse 13.2 nicht der Fall.

Manche werden sagen: Na und? Antwort und Gegenfrage: Schon mal an einem hochauflösenden 4K-Schirm gearbeitet? Da werden zu kleine Font-Darstellungen in der Praxis total nervig.

Nicht jeder Anfänger beherrscht alternativ die Klaviatur von Systemkommandos am “bash”-Prompt. Zudem muss man die Namen und Pfade diverser ausführbarer Programme ggf. kennen oder ermitteln können, um die überhaupt aufrufen zu können. Und wenn dann noch eine fehlerhafte Darstellung kommt …

Also ich habe im Umfeld des noch fehlerbehafteten KDE5 einiges Verständnis dafür, wenn jemand als root mal temporär unter der X-Window-Oberfläche arbeiten will.

Wie kann man sich als root unter Leap 42.1 Zugang zur grafischen Oberfläche verschaffen? Man wird schnell feststellen, dass der neue Breeze-Anmeldebildschirm einen Login als root (in seiner Standardeinstellung) nicht zulässt. Es gibt dann 3 Möglichkeiten:

Möglichkeit 1 – die harte Tour über startx:
Aus der grafischen Oberfläche ausloggen => Wechsel zur Konsole mit “Ctrl-Alt-F1” => als root einloggen => “init 3” absetzen (ggf. nochmal Ctrl-Alt-F1, falls man nicht wieder am Prompt landet) => “startx”

Möglichkeit 2 – Andere Einstellung des Breeze Anmelde-Bildschirms:
Startmenü => Einstellungen => Systemeinstellungen => “Starten und Beenden” => Anmeldebildschirm (SDDM) => Erweitert => Feld “Minimale UID auf den Wert “0” (ohne Anführungszeichen) setzen.

Möglichkeit 3 – Wahl eines anderen geeigneten Designs des Anmeldebildschirms:
So lässt etwa “Maldives” ein Login als root zu.

Dennoch gilt natürlich: Als User root so viele Aufgaben wie möglich direkt in einem Terminal und auf der Kommandozeile erledigen.

Opensuse Leap 42.1 – Amarok – Abstürze, Freezes – Wechsel zu Packman Paketen erforderlich

Posted on by

Eine Testapplikation für die Funktionstüchtigkeit neuer KDE-Versionen – wie nun KDE 5 – ist für mich u.a. Amarok. Ich nutze für die Musikberieselung beim Arbeiten in der Regel zwar lieber das übersichtlichere und in seinen Funktionen i.d.R. auch stabilere Clementine. Aber Amarok offenbart oftmals Schwächen im Zusammenspiel mit Phonon und den Phonen-Backends sowie mit Codecs.

Besonders interessant war ein Amarok-Test im vorliegenden Fall für ein frisch installiertes Opensuse Leap-System auch deshalb, weil Amarok nur in der Version 2.8 vorliegt, die meines Wissens eigentlich für KDE 4.14 entwickelt wurde. Unter Leap 42.1 kommt aber KDE 5 zum Einsatz.

Nach meinen ersten Erfahrungen mit Opensuse Leap 42.1 und KDE 5 gilt grundsätzlich: Eigentlich kann man die Pakete, die SuSE einem auf der Leap 42.1-Installations-DVD anbietet, vergessen. Damit bekommt man auf einem etwas komplexeren Desktop-System mit Nvidia-Karte und mehreren Soundkarten jedenfalls kein dauerhaft stabiles und flüssig funktionierendes System mit KDE-Plasma-Desktop hin.

So führte bei mir u.a der Aufruf von Amarok in den Abgrund. Es gab ganz verschiedene und erratisch auftretende Varianten von Fehlern, die ein Amarok-Start (und ggf. auch ein Aufruf des integrierten Equalizers) bei mir auf einer Leap-Standardinstallation provozierte – Absturz des Plasma-Desktops, Freeze des Desktops, Freeze von Amarok, kein Start von Musik-Dateien möglich (weder MP3 noch Ogg Vorbis, noch ….). Mit und ohne Pulseaudio ….

Dabei lief/läuft Clementine auf Anhieb anstandslos. Also war das Sound-System des KDE 5-Desktops wohl grundsätzlich lauffähig. Eine Lösung brachten schließlich folgende Schritte:

  1. Update aller installierten Pakete mit Hilfe der Standard Opensuse Online Repositories.
  2. Packman und VideoLan-Repositories in den YaST-Paketmanager einbinden.
  3. Diverse Codec-Pakete, Lame und was man sonst noch für seine Sound-Applikationen braucht aus dem Packman-Verzeichnis laden.
  4. Wechsel für alle Pakete, bei denen das möglich ist (u.a. zu Gstreamer), von den Versionen der Opensuse Standard- und Upgrade-Repositories zu den Versionen des Packman-Repositories.
    Nachtrag 25.01.2016:
    Es gibt eine bemerkenswerte Ausnahme: Das Paket “freshplayerplugin” sollte man in seinen neuesten Versionen weder aus dem Packman- noch aus dem Multimedia-Repository installieren, wenn man Eclipse Mars mit GTK2 betreiben will. Siehe hierzu einen kommenden, gesonderten Blog-Beitrag.
  5. Löschen sämtlicher “amarokrc”- und relatierter Dateien sowie auch der Datei “.gstreamer-0.10” im eigenen Home-Verzeichnis. Die werden automatisch neu angelegt.
  6. Zur Not einen anderen neuen User aufsetzen und mal für diesen neuen User testen. Bei Erfolg, den ursprünglichen User komplett neu aufsetzen.

Nun laufen sowohl Amarok als auch Clementine.

Dass ich auf Desktop-Systemen außerdem Pulseaudio abschalte (geht am einfachsten über YaST2 und die dortige Sound-Konfiguration) und lieber auf Plain Alsa vertraue, wissen die Leser meines Blogs eh’ schon. Das hat aber mit dem Amarok-Problem und der dahinter liegenden Inkonsistenz diverser Pakete des SuSE-Systems weniger zu tun ….

Opensuse Leap 42.1 – Nvidia – KDE 5 – unregelmäßiger Crash des Windowmanagers

Posted on by

Der KDE Plasma-Desktop von Opensuse Leap 42.1 macht mir immer wieder erhebliche Schwierigkeiten. Leider auch bzgl. elementarer Dinge wie etwa der Bedienbarkeit der Fenster. Ich habe zwar den neuesten proprietären Treiber von Nvidia installiert; der hilft aber ebensowenig wie ältere Treiber oder ein Wechsel von OpenGL 2.0 zu OpenGL 3.1:

Bei Drag- und Drop-Aktionen mit komplexeren Applikationen wie etwa “kontact” oder Eclipse auf dem Desktop zerreißt es manchmal den Windowmanager. Danach haben sämtliche Fenster keine Bedienleiste mehr.

Ähnliches passiert auch bei Änderungen der Fensterdekoration über die KDE-“Systemeinstellungen”.

Es ist nun nicht notwendig, sich nach einem solchen desaströsen Vorfall ab- und wieder anzumelden. (Leider funktioniert nämlich auch das Abmelden nicht verlässlich … ). Solange man noch ein Terminalfenster öffnen kann, kann man den Windowmanager erneut starten.

Man muss dazu jedoch wissen, das sich das Kommando geändert hat. Statt “kwin &” ist das jetzt zu verwendende Kommando:

ich@mytux:~> kwin_x11 &

Ich hoffe, dieser Tipp hilft dem einen oder anderen.

systemd Logging Protokolle – journalctl – Abfrage nach Services und Kommandos mit Autocompletion-Hilfe für Vergessliche

Posted on by

Als alter “syslog-ng” Nutzer tue ich mir immer wieder hart mit der Protokollierung durch “systemd”. Der Schlüssel-Befehl “journactl” ist mir natürlich präsent – aber welche Opionen muss ich dann wählen, um die Unzahl von Journal-Einträge nach solchen zu ganz bestimmten Services oder Kommandos zu filtern?

Den entscheidenden Tip für Dummies wie mich habe ich hier gefunden:
http://blog.delouw.ch/2013/07/24/why-journalctl-is-cool-and-syslog-will-survive-for-another-decade/
(Vielen Dank für den hilfreichen Blog-Artikel).

journactl hat eine Autocompletion-Funktionalität über die Tab-Taste:

Generelle Filter-Optionen erreicht man über

journalctl <TAB>[<TAB>]

Ggf. muss man die TAB-Taste 2-mal drücken. 

mytux:~ # journalctl 
CODE_FILE=                   _KERNEL_DEVICE=
CODE_FUNC=                   _KERNEL_SUBSYSTEM=
CODE_LINE=                   _MACHINE_ID=
COREDUMP_EXE=                _PID=
ERRNO=                       _SELINUX_CONTEXT=
MESSAGE=                     _SOURCE_REALTIME_TIMESTAMP=
MESSAGE_ID=                  _SYSTEMD_CGROUP=
PRIORITY=                    _SYSTEMD_OWNER_UID=
SYSLOG_FACILITY=             _SYSTEMD_SESSION=
SYSLOG_IDENTIFIER=           _SYSTEMD_UNIT=
SYSLOG_PID=                  _TRANSPORT=
_AUDIT_LOGINUID=             _UDEV_DEVLINK=
_AUDIT_SESSION=              _UDEV_DEVNODE=
_BOOT_ID=                    _UDEV_SYSNAME=
_CMDLINE=                    _UID=
_COMM=                       __CURSOR=
_EXE=                        __MONOTONIC_TIMESTAMP=
_GID=                        __REALTIME_TIMESTAMP=
_HOSTNAME=

 
Das ist doch schon sehr hilfreich. Da die meisten System-Services direkt zu irgendwelchen “systemd UNITs” korrespondieren, kommt man hier schon ein gutes Stück weiter. Beispiel: 

mytux:~ # journalctl _SYSTEMD_UNIT=sshd.service 
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:02:35 CEST. --
......
-- Reboot --
Jan 24 10:49:37 mytux sshd-gen-keys-start[5942]: Checking for missing server keys in /etc/ssh
Jan 24 10:49:37 mytux sshd[5947]: Server listening on 0.0.0.0 port 22.
Jan 24 10:49:37 mytux sshd[5947]: Server listening on :: port 22.
Jan 24 10:50:03 mytux sshd[5971]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33032 ssh2
Jan 24 10:50:03 mytux sshd[5971]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 10:50:03 mytux sshd[6013]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33033 ssh2
Jan 24 10:50:03 mytux sshd[6013]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 12:10:20 mytux sshd[13201]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33310 ssh2
.......

 
Oder: 

mytux:~ # journalctl _SYSTEMD_UNIT=vmware.service 
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:07:41 CEST. --
Jan 03 09:31:07 mytux vmware[1475]: Starting VMware services:
Jan 03 09:31:07 mytux vmware[1475]: [33B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [49B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [50B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [30B blob data]
Jan 03 09:31:07 mytux vmnetBridge[1775]: Bridge process created.
Jan 03 09:31:07 mytux vmnetBridge[1775]: RTM_NEWLINK: name:enp8s0 index:2 flags:0x00011043
Jan 03 09:31:07 mytux vmnetBridge[1775]: Adding 
interface enp8s0 index:2
Jan 03 09:31:07 mytux vmnetBridge[1775]: Started bridge enp8s0 to virtual network 0.
.......

 
Erinnert man sich nicht mehr an laufende Services bzw. systemd-Units, so benutzt man die TAB-Taste erneut:

mytux:~ # journalctl  _SYSTEMD_UNIT=<TAB>[<TAB>]
Display all 196 possibilities? (y or n)

Das Ganze geht auch für Optionen:

journalctl  –<TAB>[<TAB>]

Also: 

mytux:~ # journalctl  -<TAB>[<TAB>]
--all             --system
--boot            --this-boot
--cursor          --unit
--directory       --until
--disk-usage      --update-catalog
--field           --user
--file            --user-unit
--follow          --verify
--full            --verify-key
--header          --version
--help            -D
--interval        -F
--lines           -a
--list-boots      -b
--list-catalog    -c
--local           -f
--merge           -h
--new-id128       -l
--no-pager        -m
--no-tail         -n
--output          -o
--priority        -p
--quiet           -q
--setup-keys      -u
--since

 
Wie so oft führen bzgl. eines bestimmten Dienstes bzw. eines korrespondierenden Kommandos mehrere Wege zum Ziel:

mytux:~ # journalctl  _SYSTEMD_UNIT=sshd.service

oder

mytux:~ # journalctl  -u sshd

oder

mytux:~ # journalctl  –unit sshd

und

rux:~ # journalctl  _COMM=sshd

führen zu sehr ähnlichen Outputs. Der letzte Befehl zeigt am meisten an.

“_COMM” steht dabei für “Command” – das ermöglicht natürlich sehr vielfältige Filtermöglichkeiten – je nach Logging-Einstellungen.

Nun kombiniert man den Filter für eine Unit oder ein Komamndo noch mit einer Zeiteinschränkung über die Optionen “–since” und “–until” und jeweiligen Zeitstempeln im Format „2015-06-30 10:13:16“ – und schon fühlt man sich als Admin bzgl. der Analyse etwas besser. Z.B.:

mytux:~ # journalctl -u sshd –since “2015-06-30” –until “today”

Fazit: Durch die Autocompletion-Funktionalität wird einem der Gewöhnungsprozess an “journalctl” doch erheblich erleichtert. Man muss es halt nur wissen – und irgendwann sitzen die Kommando-Optionen auch bei mir.

Links:
https://wiki.archlinux.org/index.php/Systemd
http://0pointer.de/blog/projects/journalctl.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-Using_the_Journal.html
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs