Category Archives: Opensuse 13.2

Tipps zu Opensuse 13.2

Opensuse Leap 42.1 und 13.2 – aktuelle Versionen des freshplayerplugin-Pakets führen zum Crash von Eclipse mit GTK2

Posted on by

Es gibt Probleme, deren Ursachen sind schwer zu finden und können einen in den Wahnsinn treiben. So zuletzt das Phänomen, dass Eclipse mit GTK2 nach Updates sowohl von Opensuse 13.2 als auch Opensuse Leap 42.1 permanent und zunächst scheinbar erratisch abstürzten.

Interessanterweise tauchen die Probleme mit Eclipse unter GTK3 nicht auf. Allerdings zeigt die Eclipse UI unter GTK3 noch einige unschöne Grafik-Probleme.

Es dauerte eine Weile, bis ich herausfand, dass die Abstürze von Eclipse/GTK2 nur auftraten, wenn ich Content Assist Funktionalitäten benutzte (was ich natürlich sehr regelmäßig tue) und dabei Zusatzinformationen zu Elementen der Vorschlagsliste angezeigt wurden. Typischerweise ist es so, dass diese Zusatzinformationen aus HTML-Vorgaben gerendert werden. Die Java Runtime JVM nutzt hierzu “webkit”-Funktionalitäten (der Umgebung).

Es dauerte noch einige Zeit mehr, bis ich herausfand, dass das Problem auf einer frischen Installation von OS 13.2 oder LEAP 42.1 nicht auftrat – wohl aber nach einer Reihe von Updates der Opensuse-Umgebung. Leider ist es durchaus schwierig, herauszufinden, welches Paket unter hunderten genau der Verursacher der Probleme ist. Dass es mit Web/HTML-Rendering zu tun haben musste, war aber klar.

Durch eine Backtrace-Analyse des JVM-Absturzes kam ich heute einen substanziellen Schritt weiter:

Die erhaltenen Absturz-Informationen der JVM zeigten, dass im Rendervorgang auch eine “freshwrapper”-Bibliothek tangiert wurde – genauer:
“/usr/lib64/browser-plugins/libfreshwrapper-pepperflash.so” aus dem Paket freshplayerplugin.

Das Paket “freshplayerplugin” liefert einen nützlichen Firefox-Wrapper für Chromes/Chromiums “pepper-flash”-Plugin. Letzteres ermöglicht das Abspielen von Flash-Inhalten auch unter Firefox – das ist u.a. nützlich für Live-Streams des einen oder anderen Fernsehsenders, der bislang noch nicht auf vernünftige Formate umgestellt hat.

Ich hatte das Paket “freshplayerplugin” unter Leap 42.1 und OS 13.2 im Zuge von Updates in der aktuellsten Variante “0.3.4-20.1” vom Packman-Repository installiert.

Tatsächlich zeigte sich, dass mit einer Installation der Paketversion “0.3.2” aus den jeweiligen Hauptrepositories von SuSE die Eclipse-Absturz-Probleme unter Opensuse Leap 42.1 verschwanden. Bzgl. OS 13.2 muss ich mich noch kundig machen.

Ich hoffe, diese Info zumindest zu Leap 42.1 hilft auch anderen Betroffenen, die Eclipse mit GTK2 nutzen wollen.

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

Linux, Opensuse 13.2, Firefox: Flash bei Bedarf über Wrapper aktivieren

Posted on by

Ich bin wahrlich kein Freund von Flash. Aber es gibt einige (veraltete) Webseiten, auf denen man bestimmte sinnvolle Inhalte halt nur mit Flash ansehen kann. So hängen ja u.a. einige deutsche Fernsehsender der technischen Entwicklung hinterher. Und dann gibt es da in unserer Familie auch noch ein paar Enkel, die zwar einen Linux-Laptop nutzen, aber trotzdem irgendwelche Flash-Inhalte “unbedingt(!!Opa, unbedingt!!)” sehen “müssen”. Welche Optionen hat man dann?

Erstens kann man auf den “Chrome” oder vorzugsweise auf den “Chromium”-Browser ausweichen. Für beide gibt es ja bekanntermaßen das “Pepper-Flash”-Plugin von Google. “Pepper” steht dabei für eine neue Art von generellem Browser-Plugin-Interface (PPAPI), das aber z.Z. auf Chrome/Chromium begrenzt ist. Siehe hierzu u.a.
http://www.howtogeek.com/193876/using-firefox-on-linux-your-flash-player-is-old-and-outdated/
Dieses Plugin ist möglicherweise nicht sicherer, aber immerhin schneller als das originale Flash von Adobe.

Was aber tun Firefox-Anwender, nachdem Adobe Linux ja generell nicht mehr unterstützt und das mit den Linux-Distributionen noch erhältliche Plugin in der Version 11.2 uralt und mit Sicherheit unsicher ist?

Mozilla selbst unterstützt die Flash-Plugin-Technologie nicht mehr aktiv – und unter Linux schon gar nicht (s. u.a. http://www.linux-magazin.de/NEWS/Firefox-blockiert-Flash-Inhalte). Ich finde das völlig OK – aber was mache ich nun mit veralteten Webseiten oder den lieben Enkeln, die Flash unter FF “unbedingt” nutzen “müssen”?

Nun, ein paar nette Leute haben solche Situationen wohl vorhergesehen und eine Wrapper-SW – das sog. “Fresh Player Plugin” – für das Chrome/Chromium pepper-based Flash-Plugin entwickelt. Siehe etwa:
http://www.makeuseof.com/tag/how-to-get-chromes-latest-flash-player-to-work-in-firefox-on-linux/
http://www.webupd8.org/2014/05/fresh-player-plugin-pepper-flash.html
https://github.com/i-rinat/freshplayerplugin

Es war aber gar nicht so einfach herauszufinden, wie man eine Installation unter Opensuse 13.2 auf einfache Art über Pakete und ohne Kompilieren hinbekommt. Dann fand ich nach etwas Herumsuchen im Packman Repository http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_13.2/
das Paket “freshplayerplugin”.

Das habe ich mal testweise installiert, und damit war das Problem auch schon gelöst. Allerdings hatte ich auf dem betroffenen System bereits eine Chromium-Installation aus den SuSE-Standard-Repositories an Bord, die ich um das Paket “chromium-pepper-flash” – ebenfalls aus dem Packman-Repository – ergänzt hatte. Wer bislang weder Chrome noch Chromium auf seinem Linux-System zur Verfügung hat, kommt jetzt nicht darum herum, entweder Chrome komplett – oder aber zumindest das Paket “chromium-pepper-flash” zu installieren. (Vorzugsweise verzichtet man auf Chrome – und nutzt Chromium.)

Zum “freshplayerplugin” – also dem Wrapper für FF – gehört eine umfangreiche Konfigurationsdatei. Die steht nach der Paketinstallation unter “/etc/freshwrapper.conf”. Sie enthält eine Zeile, in der der Pfad zur eigentlichen Bibliothek für den Chrome- oder Chromium Pepper-Flash-Player “libpepflashplayer.so”. [Die “so”-Datei wird im Zuge der Installation von “chromium-pepper-flash” angelegt.]

Da ich Chrome, wegen der ständigen Ausforschung durch Google nicht benutze, habe ich bei
mir die Pfadangabe auf das Chromium-Verzeichnis verkürzt.

#pepperflash_path = “/opt/google/chrome/PepperFlash/libpepflashplayer.so:/usr/lib64/chromium/PepperFlash/libpepflashplayer.so”
pepperflash_path = “/usr/lib64/chromium/PepperFlash/libpepflashplayer.so”

Danach muss man im Firefox unter “Extras >> Add-Ons >> Plugins” das aktuelle (pepper-based) Shockwave Flash Plugin nur noch aktivieren.

pepper1

Bei mir haben der Wrapper und das pepper-based Flash auf den (wenigen) Flash-Seiten, die ich mir angesehen habe, problemlos funktioniert. Herzlichen Dank also – im Besonderen von den Enkeln – an die Entwickler des Wrappers!

Wer Wert auf Sicherheit legt, für den mag folgender Hinweis noch interessant sein:
Man kann Firefox (bei aktiviertem Flash Plugin) mit Hilfe von “firejail” auch in einer Art Sandbox-Umgebung laufen lassen. Sieh dazu einen ausführlichen Artikel im aktuellen Linuxuser-Magazin 10/2015.

Bumblebee auf Laptops mit Opensuse 13.1 / 13.2

Posted on by

Ich nutze ja auch einige Laptops unter Linux. U.a. einen nun schon etwas älteren “Terra 17 Zoll Laptop”, bei dem netterweise fast die gesamte Hardware unter Linux unterstützt wird. Dieser Laptop hat einen “i7-3632QM” Prozessor mit integrierter Intel HD 4000 Grafikkarte; ferner existiert eine zusätzliche Nvidia GT 645M.

Diese “Nvidia Optimus” Ausstattung erfordert unter Linux Bumblebee.

Bumblebee erlaubt das gezielte Aufrufen des Nvidia-Treibers für 3D-Grafik-Applikationen, die dann durch die dedizierte Nvidia-Karte beschleunigt in ein Fenster des von der Intel-Grafikkarte gesteuerten Desktops eingeblendet werden. Aus meiner Sicht ist das eine fast optimale Methode, die leistungsstarke, aber auch energiehungrige Nvidia-Grafikkarte nur dann zu zuzuschalten, wenn sie wirklich benötigt wird.

Eigentlich ist die Installation von Bumblebee aus den entsprechenden Opensuse Repositories inzwischen ein Leichtes. Dennoch erhalte ich immer mal wieder ein Problem, wenn ich Updates des Systems vornehme – u.a. der Kernelversion. Danach laufen die Kommandos “bbswitch” bzw. “optirun” und “primusrun” zum An- und Ab-Schalten der Nvidia-Karte bzw. zum Starten von 3D-Applikationen meist nicht mehr wie erwartet. In der Regel erinnere ich mich dann auch nicht mehr an alle Voraussetzungen, die gegeben sein müssen, damit Bumblebee ordentlich funktioniert. Für alle, denen es ähnlich geht, stelle ich nachfolgend ein paar Schritte und Voraussetzungen zur Nutzung von Bumblebee zusammen.

Wichtige Ergänzung 08.08.2016:
Dieser Artikel ist nicht mehr ganz gültig, was die für neuere Kernelversionen notwendigen Repositories anbelangt. Im Besonderen funktioniert bbswitch zum An- und Abschalten der Nvidia-Karte u.U. nicht mehr. So sollte man statt der nachfolgenden Bumblebee-Repositories das Repository für das Bumblebee3-Projekt heranziehen; es steht für verschiedene Opensuse-Versionen zur Verfügung (s. http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee3/). Das dortige Paket “dkms-bbswitch” ist dasjenige, was mit neueren Kernelversionen und Nvidia-Treibern funktioniert. Ferner sollte man ein Repository für einen neueren Nvidia-Treiber wählen, etwa Treiberversion 361.42. Einen upgedateten Artikel finden Sie unter
https://linux-blog.anracom.com/2016/08/08/bumblebee-auf-optimus-notebooks-und-laptops-mit-opensuse-13-1-13-2-leap-42-1/

Installation und Einrichtung von Bumblebee

Folgende RPM-Repositories sollte man der SW-Verwaltung unter YaST für Opensuse 13.1 Installationen verfügbar machen:
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/346.35/openSUSE_13.1/

Unter Opensuse 13.2 ist “13.1” in den Adressen natürlich jeweils durch “13.2” zu ersetzen.

Will man den neuesten Treiber nutzen, so sollte man sich statt des dritten genannten Repositories für
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/latest/openSUSE_13.1/
bzw.
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/latest/openSUSE_13.2/
r
entscheiden

Das erste der oben genannten Repositories umfasst z.Z. den Umfang des zweiten fast vollständig. Der Unterschied besteht in der Bereitstellung eines zusätzlichen Pakets für acpi Calls im zweiten Repository. Ganz entscheidend ist jedoch das dritte Nvidia-bezogene Repository; dieses bietet die Installation des proprietären Nvidia-Treibers in einer für Bumblebee geeigneten Form an.

Folgende Pakete habe ich bei mir unter Opensuse 13.1 konkret installiert:
bumblebee1

bumblebee2

Entscheidend ist die Installation des Nvidia-Kernel-Modules “nvidia” über das Paket “X11-video-nvidia” aus dem 3-ten Repository. Während der Installation wird die erforderliche Kompilation für den aktuellen Kernel vorgenommen.

Blacklisten des nouveau-Treibers

Nach einer Neuinstallation von Opensuse auf einem Laptop mag es sein, dass der Nouveau-Treiber installiert ist. Ich habe Bumblebee bislang nicht mit dem Nouveau-Treiber ausprobiert, sondern aus verschiedenen Gründen immer den proprietären Nvidia-Treiber (erfolgreich) genutzt. Damit dies möglich wird, muss der Nouveau-Treiber, soweit auf dem Laptop-System vorhanden, deaktiviert werden. Ich habe ihn deshalb zur Sicherheit in eine Blacklist für Kernelmodule aufgenommen. Die Dateien “/etc/modprobe.d/50-blacklist-nouveau.conf” und auch “/etc/modprobe.d/50-blacklist.conf” enthalten somit folgende Statements:

blacklist nouveau
options nouveau modeset=0

Keine Installation des proprietären Nvidia-Treibers über das Linux-Installationsprogramm von der Nvidia-Web-Seite!

Versuchen Sie bitte weder während der Opensuse-Erstinstallation noch später den proprietären Treiber von Nvidia mit den Installationsroutinen von der Nvidia Webseite zu installieren! Das wird in einer Optimus-Konfiguration zu keinem Erfolg führen! Der proprietäre Nvidia-Treiber sollte auf Optimus Laptops statt dessen immer aus dem oben genannten “Bumblebee-Project:/nVidia”-Repository geladen werden.

KMS nicht abschalten!

KMS (Kernel mode setting; s. http://de.wikipedia.org/wiki/Mode-Setting) wird für das “i915”-Modul (also den treiber für die Intel Graka) zwingend benötigt – DKMS sollte man also (im Gegensatz zu früheren Desktop-Installationen mit Nvidia-Karten) nicht über Kernelparameter wie “nomodeset” beim Starten des Systems deaktivieren.

Ferner gilt: Das Opensuse Community Repository für Nvidia Treiber sollte deaktiviert sein; keines der Nvidia RPMs – sprich kein Nvidia-Treiber-Paket – aus diesem Community Repository sollte installiert sein.

Welche Services sind zu aktivieren?

Folgende Services müssen für den Systemstart unter systemd ggf. noch explizit aktiviert werden:

systemctl enable bumblebeed.service
systemctl enable dkms.service

Desktop-User als Mitglied der Gruppe “bumblebee” einrichten

Zudem muss der User, unter dem man den Desktop nutzt, Mitglied der ggf. neu anzulegenden Gruppe “bumblebee” werden.

xorg.conf-Datei

Es lohnt sich ein Blick in das Verzeichnis /etc/bumblebee”: Dort befindet sich eine spezielle Datei “xorg.conf.nvidia”, die von Bumblebee genutzt wird. Eine evtl.
vorhandene “/etc/X11/xorg.conf” im Verzeichnis “/etc/X11” sollte man entfernen !

Sind alle Voraussetzungen geschaffen, startet man das System am besten neu. Man sollte dann auf der gewohnten Desktop-Oberfläche landen. Diese wird vom Intel Treiber – in meinem Fall vom kernel-Modul “i915” – gesteuert. KDE-3D-Effekte lassen sich auch über die Intel-Grafikkarte nutzen; dafür reicht deren Performance allemal.

“lsmod” sollte folgende Module anzeigen, die im Zusammenhang mit Grafik von Bedeutung sind:

i915 710403 8
bbswitch 13943 0
drm 313440 11 i915,drm_kms_helper
drm_kms_helper 56806 1 i915
video 19507 1 i915
button 13952 1 i915
thermal_sys 36646 5 x86_pkg_temp_thermal,intel_powerclamp,thermal,video,processor
 
videobuf2_core 44595 1 uvcvideo
videodev 141701 2 uvcvideo,videobuf2_core
videobuf2_vmalloc 13216 1 uvcvideo
videobuf2_memops 13362 1 videobuf2_vmalloc

Start von 3D-Anwendungen

Spezielle 3d-Applikationen, wie etwa Spiele (z.B. “alienarena”)oder OpenGL-Anwendungsprogramme, die mehr Rechenpower erfordern, kann man dann als Desktop-User über

optirun alienarena

oder

primusrun alienarena

starten.

bumblebee4

“primusrun” reduziert die Framerate der Graka auf die Schirmrate, wenn keine weiteren Parameter angegeben werden. Frame- und vertikale Bildschirmfrequenz werden also synchronisiert. Für volle Performance muss man

vblank_mode=0 primusrun alienarena

benutzen.

Folgender Artikel liefert ein paar Hinweise zum ursprünglichen Unterschied zwischen “primusrun” und “optirun”: http://www.webupd8.org/2012/11/primus-better-performance-and-less.html
Faktisch sind die aktuellen Performance-Unterschiede zwischen “primusrun” und “optirun” auf meinem System jedoch minimal.

“lsmod” zeigt nach dem Starten einer 3d-Applikation dann folgende zusätzlichen Module an:

nvidia 8370147 37
drm 313440 11 nvidia,i915,drm_kms_helper

Aufruf des Tools nvidia-settings

Übrigens: Das Tool “nvidia-settings” ruft man wie folgt auf:

optirun -b none nvidia-settings -c :8

Ab- und An-Schalten der Nvidia-Karte im normalen Desktop-Betrieb

“optirun” und “primusrun” aktivieren die Nividia-Karte bei Bedarf selbständig und deaktivieren sie auch wieder. Zum gezielten Abschalten der Nvidia-Karte im normalen Desktop-Betrieb benutzt man als root-User dagegen folgendes Kommando:

tee /proc/acpi/bbswitch <<< OFF

Anschalten geht über

tee /proc/acpi/bbswitch <<< ON

Der Laptop zeigt die Aktivität der Nvidia-Graka i.d.R. über eine LED an. Ein gezieltes Anschalten im normalen Desktop-Betrieb kann dann nützlich sein, wenn man – wie in meinem Fall – durch ein erratisches Anspringen des Laptop-Lüfters gerade bei zu kühlem Zustand des Laptops genervt wird. Manchmal hilft die zusätzliche Abwärme der Nvidia-Graka im Leerlauf, einen kontinuierlichen Lüfterbetrieb zu erzwingen.

nStartbedingungen zum An- und Abschalten der Nvidia Graka legt man über entsprechende Parameter in der Datei “/etc/modprobe.de/50-bbswitch.conf” fest:

options bbswitch load_state=0 unload_state=1

Was ist nach einem Kernelupdate und Neustart des Systems zu tun ?

Nach einem Kernelupdate läuft der “intel915” Treiber ja typischerweise noch. Man gelangt dadurch auf die grafische Oberfläche. Am einfachsten ist dann eine Deinstallation und anschließende Neuinstallation der oben dargestellten Pakete aus den Bumblebee Repositories – u.a. dkms, dkms-nvidia, bbswitch, vor allem aber “X11-video-nvidia”. Der Nvidia-Treiber wird dabei neu kompliert.

Und was ist mit Opensuse 13.2?

Ich gehe davon aus, dass die Voraussetzungen für eine reibungslosen Bumblebee-betrieb unter Opensuse 13.2 mehr oder weniger analog zu dem oben Beschriebenen für Opensuse 13.1. sind. Siehe auch die entsprechenden nachfolgenden Links.

Links

http://linuxandblues.com/linux/opensuse-13-2-easy-nvidia-bumblebee-guide-update-23-december-14/
http://www.opensuse-forum.de/allgemeines/system-einrichten-und-verwalten/10600-erledigt-nvidia-bumblebee-optirun-probleme/
https://github.com/Bumblebee-Project/Bumblebee/wiki/Install-and-usage
https://wiki.archlinux.org/index.php/Bumblebee

Nun bleibt nur noch, viel Spaß mit Nvidia 3D Beschleunigung auf Optimus Laptops unter Linux zu wünschen.

Opensuse 13.2, Libreoffice, fehlendes Paket libreoffice-clipart

Posted on by

Bestimmte Themen tauchen komischerweise immer wieder auf. Im Zusammenhang mit Opensuse 12.3 hatte ich vor ein paar Jahren darauf hingewiesen, dass zeitweise die deskriptiven Dateien “*.sdg, *.sdv, *.str, *.thm” für die thematische Gliederung der Openclipart-Dateien fehlten. Siehe
Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Im Moment ist es unter Opensuse 13.2 ähnlich schlimm:

Man kann zwar die Openclipart-Pakete herunterladen. Leider bietet aber keines der üblichen Repositories ein Paket an, dass dafür sorgen würde,

  • dass die Verlinkung der Clipart-Verzeichnisse in das zu Libreoffice gehörige “gallery”-Verzeichnis (/usr/lib64/libreoffice/share/gallery/) ordnungsgemäß vorgenommen wird
  • dass die notwendigen deskriptiven Dateien für die Themenfelder der Openclipart-Sammlung bereitgestellt werden.

Üblicherweise gab es hierfür in der Vergangenheit ein Paket namens “libreoffice-openclipart”. Debian und Ubuntu bieten entsprechende, aktuelle “deb”-Pakete nach wie vor an. Bei SuSE ist das entsprechende RPM jedoch verschütt gegangen.

Deshalb sind vielen netten Openclipart-Bilder leider unter Libreoffice auf einem aktuellen Opensuse 13.2-System nicht unmittelbar und nicht ohne Klimmzüge nutzbar. Ich selbst merkte das natürlich auch erst, als ich für eine anstehende Kunden-Präsentation dringend ein paar Cliparts benötigte. Der in meinem früheren Beitrag erwähnte Workaround ist jedoch für die Menge der aktuellen Openclipart-Themenbereiche leider viel zu umständlich. Die alternativ einsetzbare Libreoffice-Erweiterung “openclipart.oxt” , mit der man ggf. Cliparts auch direkt aus dem Internet beziehen kann, finde ich viel zu träge. Man erhält aufgrund der notwendigen Suchvorgänge auch keinen schnellen Überblick. Ferner wird die Erweiterung seit längerem nicht mehr gepflegt. Was also tun ?

Möglicher Workaround
Man kann schlicht auf eine ältere Version aus Opensuse 13.1-Zeiten zurückgreifen. Ich habe mir z.B. aus dem Repository
http://rpmfind.net/linux/opensuse/distribution/13.1/repo/oss/suse/noarch/
die Pakete

  • openclipart-svg-0.18-155.1.2.noarch.rpm
  • openclipart-png-0.18-155.1.2.noarch.rpm
  • libreoffice-openclipart-4.1-2.1.3.noarch.rpm

heruntergeladen und in dieser Reihenfolge zusätzlich zum laufenden Libreoffice 4.3.5 installiert. Die Datei “libreoffice-openclipart-4.1-2.1.3.noarch.rpm” stellt dann wie gewohnt die erforderlichen deskriptiven Dateien bereit.

Danach ist u.U. noch ein wenig Aufräumen angesagt. In meinem Fall war es so, dass es im Verzeichnis “/usr/share/clipart” bereits ein Unterverzeichnis

“/usr/share/clipart/openclipart”

gab. Und zwar aus der früheren Installation der aktuellen Openclipart-Variante, zu denen Opensuse ja leider keine deskriptiven Dateien anbietet. Der Installer hatte die Dateien zur älteren Openclipart-Version 0.18 deshalb unter einem zusätzlichen Verzeichnis:
“/usr/share/clipart/openclipart-0.18”
angelegt. Das verträgt sich jedoch nicht mit den Links der deskriptiven Dateien. Also (als user root oder mit sudo):

mytux:~ # mv /usr/share/clipart/openclipart /usr/share/clipart/openclipart-0.20
mytux:~ # mv /usr/share/clipart/openclipart-0.18 /usr/share/clipart/openclipart

Danach noch checken, dass unter “/usr/lib64/libreoffice/share/gallery” die notwendigen deskriptiven Dateien der Openclipart-Themenbereiche tatsächlich als Links angelegt wurden – man erkennt diese (vielen) Links leicht am führenden ”
openclipart” im Namen. Ferner zur Sicherheit noch folgenden Link prüfen und ggf. ersetzen:

mytux:~ # rm /usr/lib64/libreoffice/share/gallery/clipart
mytux:~ # ln -s /usr/share/clipart/openclipart/ /usr/lib64/libreoffice/share/gallery/clipart

Nun mit dem aktuellen Libreoffice-Writer testen. Bei mir hat dann alles einwandfrei funktioniert. Ich bin damit zwar nicht auf dem neuesten Stand – kann aber wenigstens die Cliparts von Opensuse 13.1 nutzen.

Hoffentlich merkt ein Verantwortlicher bei Opensuse für das aktuelle Libreoffice-Repository bald mal, dass die dortigen Pakete nicht zusammen mit den Openclipart-Dateien funktionieren.