Opensuse 12.3 – OX 6.22 lässt sich mit systemd nicht starten

Nach dem Upgrade von Opensuse 12.2 auf Opensuse 12.3 musste ich leider feststellen, dass der Dienst “/etc/init.d/open-xchange” nicht mehr automatisch gestartet werden kann. Im Gegensatz zu Opensuse 12.2 führt ein "systemctl start open-xchange" nun leider ins Nirwana:

mysystem:/etc/init.d # systemctl status open-xchange.service
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:30:19 CET; 5min ago
Process: 13365 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 13349 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13349]: Starting open-xchange ..done
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
Mar 27 12:30:19 mysystem.mydomain.de su[13360]: (to open-xchange) root on none
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13365]: Shutting down open-xchange ..done

Jeder Start mit systemd führt also auch zu einem sofortigen Stop. Und der Service ist danach regelmäßig "dead".Was dem User beim Versuch, sich in OX 6 einzuloggen mit 503-Fehlermeldungen quittiert wird.

Na da freuen wir uns doch mal wieder herzlich über die "wunderbare" Welt von systemd! Was für OX 6.22 unter Opensuse 12.2 anstandslos lief, läuft unter Opensuse 12.3 nicht mehr. Und die Fehleranalyse ist für systend so kompliziert und unüberschaubar, dass ich im Moment keinerlei Lust verspüre, auf Fehlersuche zu gehen.

Workaround
Netterweise geht aber nach wie vor ein direkter Start über das Skript:

mysystem:/etc/init.d # ./open-xchange start
redirecting to systemctl start
Starting open-xchange done
mysystem:/etc/init.d # ./open-xchange status
Checking for service open-xchange running
Checking for service open-xchange running
mysystem:/etc/init.d # systemctl status open-xchange
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:57:05 CET; 1min 39s ago
Process: 15646 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 15636 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15636]: Starting open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15646]: Shutting down open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
mysystem:/etc/init.d #

Man beachte die Kleinigkeiten und erfreue sich an dieser berauschenden Logik: Das Startscript wird angeblich an systemctl redirected. Open-Xchange wird danach auch erfolgreich gestartet. Der Status ist bei normaler Abfrage per Script auch running. Man kann sich regulär per Browser in seinen OX6-Account einloggen. Aber systemd kann mit dem erfolgreichen Start offenbar gar nichts anfangen und sieht nicht mal, dass der Service läuft! Was für ein grandioses Chaos!

Jedenfalls läuft der Dienst nur nach einem normalen Start – also über /etc/init.d/open-xchange start regulär. Nicht aber das Rauf- und Runterfahren über systemd. Damit kann man den inzwischen auf ein Minimum reduzierten “Runlevel-Editor” von YaST für eine Aktivierung von OX 6.22 schlicht vergessen. Runlevels gibt es dort nicht mehr – und für OX funktioniert das Starten beim
Hochfahren in das Systemd-Default-Target mit systemd nicht.

Also gilt bis auf weiteres unter Opensuse 12.3: OX 6.22 händisch starten und vor dem Runterfahren auch wieder stoppen.
Schöne neue Welt …. Seufz ….

Nachtrag 08.06.2013 und Lösung:
Die Opensuse-Leute haben mir inzwischen wirklich geholfen, das Problem analysiert und ein service-file für den “open-xchange”-Service zusammengestellt. Dadurch ist nun ein Hochfahren von open-xchange beim Systemstart möglich.
Siehe
https://bugzilla.novell.com/show_bug.cgi?id=813767
Man beachte auch die gute Erklärung der Problem-Ursache.

Vielen Dank an Frederic Crozat !!

Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Ich habe ja vor kurzem auf zwei Systemen Opensuse 12.3 installiert. Im Zuge davon habe ich auch ein Update der Libreoffice-Installation vorgenommen. Danach wollte ich im Rahmen eines Projektes mit Hilfe der Clipart-Gallery ein paar Draw-Zeichnungen anfertigen. Die notwendigen Clipart-Pakete

  • libreoffice-openclipart
  • openclipart-svg (in der Version 0.18

hatte ich natürlich installiert.

Zur Voransicht der Cliparts gibt es in den Libreoffice-Anwendungen ein Fenster, in dem die Cliparts nach thematischen Bereichen gegliedert dargestellt werden. Soweit ich mich erinnern kann, hatte ich dort zumindest in einer OS 12.1 / LibreOffice 3.5-Installation für alle Themenbereiche der Gallery auch eine Voransicht zugehöriger Ciparts gefunden.

Leere Ansicht für viele Gallery-Themenbereiche unter OS 12.2 und OS 12.3

Leider wird nun für die meisten thematischen Gallery-Bereiche in Libreoffice 3.5 bis 4.0.2 unter Opensuse 12.2 oder Opensuse 12.3 gar nichts mehr angezeigt. Beispiele liefern "Science" oder "Shapes" ; im Gallery-Fenster ist zu beiden Themenbereichen kein Clip zu sehen:

gallery_leer_600

Das ist ein typischer Mangel an qualitätsgesicherter Paket-Aufbereitung, wie er mich an der Verbreitung von Opensource-Produkten durch einige Distributoren manchmal an den Rand der Verzweiflung treibt. Was macht denn eine normaler Anwender bei einem solchen Befund? Er zuckt mit den Achseln, wundert sich und geht davon aus, dass es da halt keine Bilder gibt. das ist zugleich falsch und schade!

Eine Fehlersuche zeigt, dass es im Verzeichnis /usr/lib64/libreoffice/share/gallery/ Softlinks auf *sdg-Dateien gibt, die im korrespondierenden Verzeichnis /usr/share/libreoffice/share/gallery/ leider ins Nirwana führen. Für die entsprechenden Themenbereich wird in der Clipart-Ansicht der Libre-Office-Bereiche deshalb nichts angezeigt, obwohl im thematischen Subverzeichnis unter /usr/share/openclipart/ haufenweise svg-Dateien vorhanden sind.

Ein Blick in die Verzeichnisliste des Openclipart-Pakets von Opensuse zeigt, dass die beschreibenden "sdg"-Dateien für viele Themenberieche tatsächlich nicht ausgeliefert werden – also bereits im RPM-Paket von Opensuse selbst fehlen. Warum auch immer …. Ein Bug?

Eine parallele Windows-Installation ist wenigstens ehrlicher – die bietet von Haus aus nur wenige gefüllte Themenbereich an. Den Rest muss man sich sowieso selbst zusammenstellen.

OpenClipart-Download als Alternative ? Nein !

Alternativ und naiv dachte ich nun daran, mir etwas von der OpenClipart-Seite im Web herunterzuladen. Da wurde alles nur schlimmer; ein Download aktuellerer Clipart-Pakete ab Version 0.19 führt in den Abgrund.

Man erhält dann nämlich keine vorsortierte thematische Zusammenstellung an Files mehr, die man in ein Subverzeichnis von "/user/share/clipart/" einfügen könnte. Stattdessen kommen HTML-Dateien mit Bildern aus einem Verzeichnis, das nach allen möglichem (u.a. Autoren) aber nicht thematisch untergliedert ist. Vielmehr wird hier eine komplexe Installation von HTML-Seiten mit PHP-MySQL-basierter Suchmaschine erwartet. Leider funktioniert das vorgesehen “make install” unter OS 12.3 gar nicht. Schauder … – in dieser Form ist OpenClipart 2.x weder für LibreOffice noch sonst irgendwie brauchbar. Keine Zeit, mich damit zu befassen. Ich will doch nur ein paar faktisch vorhandene Cliparts unter Libreoffice sehen und nutzen!

Workaround

Ich habe dann versuchsweise Libreoffice komplett deinstalliert, alle zugehörigen Konfigurationsdateien in meinem Home-Verzeichnis entfernt und Libreoffice neu installiert. Das half leider auch nichts. Aus Zeitmangel habe ich nun einen Workaround per Handarbeit vorgenommen:

Schritt 1: Man muss in Libreoffice im Gallery-Fenster selbst ein neues Thema zu einem der vorhandenen thematischen, aber leider als leer angzeigten Bereiche wie “Shapes” anlegen. Ich gebe dem neuen Thema z.B. den Namen "shapes_2".

Schritt 2: Im Subdialog-Fenster zu diesem neuen Thema lässt man im thematischen Unterverzeichnis von /usr/share/openclipart/ [hier also im Verzeichnis "/usr/share/clipart/openclipart/shapes/" ] alle passenden Dateien zusammensuchen, markiert dann alle oder eine Unterauswahl und drückt auf den Button "Hinzufügen". Die Anzeige des folgenden kleinen Dialoginhalts ist unter meinem KDE 4.10 dann leider nicht vollständig zu erkennen – aber man wartet einfach, bis der Übernahmeprozess erfolgt ist.

Schritt 3: Das Ergebnis sind dann 3 Dateien unter /home/USER/.config/libreoffice/4-suse/user/gallery/ (USER ist dabei dein Username):

  • sgxxx.sdg,
  • sgxxx.thm,
  • sgxxx.sdv

xxx steht dabei für eine 2- oder dreistellige Ziffer. Das eben installierte Clipart-Thema hat die höchste Nummer.
Man wird in unserem Beispiel feststellen, dass Libreoffice nun im Gallery-Fenster unter "shapes_2"alle svg-Dateien von "/usr/share/clipart/openclipart/shapes/" tatsächlich anzeigt. Die drei beschreibenden Dateien, im besonderen die sdg-Datei, sind dafür hinreichend.

Schritt 4:
Nun ermittelt man unter Libreoffice im Galleryfenster durch einen Rechtsklick auf das ursprüngliche “Shapes” dessen "Eigenschaften". In einem Dialofenster wird u.a. ein File-Pfad und ein File-Name einer zugehörigen Deskriptionsdatei sgxxx.sdg angezeigt – bei mir ist Shapes z.B. mit dem File "sg85" assoziiert.

Man fertige nun eine Kopie der obigen drei Dateien sgxxx.sdg, sgxxx.thm, sgxxx.sdv an und benenne die Ziffern "xxx" in "85" (bzw. die eben ermittelte Nummer) um. Danach verschiebe man diese deskriptiven Dateien als root (!) in das Verzeichnis "/usr/share/libreoffice/share/gallery/". (Root-rechte sind dort zum Schreiben erforderlich.

Danach funktioniert auch die Anzeige der Dateien unter dem ursprünglichen Themenbereich "Shapes" und nicht nur unter "shapes_2".

gallery_voll_600

Den für den Workaround angelegten Themenbereich "shapes_2" kann man nun eigentlich auch löschen löschen. Ich würde ihn aber behalten, da die Deskriptonsdateien für "Shapes" bei einer Neuinstallation der Opensuse-RPMs möglicherweise wieder gelöscht werden. Dann kann seine alte Auswahl im Eigenschaftsdialog von shapes_2 aktualisieren lassen und wie oben beschrieben weiterverfahren.

Nach diesem kleinen Desaster zur Korrektur einer unvollständigen OpenClipart-V18–Installation unter Opensuse 12.3 bleibt abzuwarten, wie Opensuse und LibreOffice mit der Integration von OpenClipart-Galleries der aktuellen Versionen 0.19 und 2.X umgehen werden.

Opensuse 12.2 – textbasierter Boot Screen ohne Plymouth Animation

Leider ist unter einem aktuellem Suse oder Red Hat System Plymouth so stark in das Gespann grub2 und systemd integriert, dass ich mich eher davor hüte, alle Plymouth bezogenen Pakete zu deinstallieren. Nebenbei: Inzwischen ist wohl auch unter Ubuntu eine starke Einbindung von Plymouth in die Prozesse beim Systemstart vorgenommen worden. Siehe: http://ubuntuforums.org/showthread.php?t=1457388

Dennoch kommt ab und zu der Wunsch auf, den animierten Plymouth-Splash-Screen während des Boot-Vorgangs los zu werden, um ohne Umwege die Boot-Meldungen sehen zu können. Diesen Wunsch hatte zumindest ein Admin, der mich vorgestern per Mail anschrieb.

Auf meinen Opensuse 12.2-Systemen mit Grub2 half hier folgendes Vorgehen:

Deaktivieren des animierten Plymouth-Boot-Screens mit Hilfe von YaST2

Man öffne unter YaST2 das Modul “Boot Loader”. Im sich öffnenden Fenster gehe man zum Button “Boot Loader Options”. Das nächste Fenster zeigt eine Zeile zu Kerneloptionen:

no_plymouth_600

In dieser Zeile setzt man

splash=0

ein. Zudem entfernt man ein evtl. vorhandenes Schlüsselwort “quiet”. In Fall meines betrachteten Systems lautet die fertige Zeile dann:

video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts

Auf anderen Systemen wird natürlich das Resume-Device für den Swap-Bereich eine andere Bezeichnung haben. Danach schließt man sukzessive die YaST2-Fenster.

YaST2 speichert die eben angegebenen YaST2-Bootloader-Daten übrigens in der Datei “/etc/default/grub” ab. Es lohnt sich, bei Gelegenheit mal einen Blick in diese Datei zu werfen! In dieser Datei kann man Basisoptionen für Grub2 hinterlegen. Auch ganz ohne YaST2, wenn es ein muss.

Auf dem hier veränderten System sieht die Datei dann so aus:

GRUB_DISTRIBUTOR=openSUSE
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=300
GRUB_CMDLINE_LINUX_DEFAULT=” video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts”
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY=”showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe”
GRUB_CMDLINE_LINUX=””
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD …)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command "vbeinfo"
GRUB_GFXMODE=auto
# Uncomment if you don’t want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png

Die dortigen Infos werden dann von einem der Scripts unter /etc/grub.d aufgegriffen, sobald YaST2 im Hintergrund
zusätzlich
grub2-mkconfig -o /boot/grub2/grub.cfg
ausführt, um die eigentliche grub2-Konfigurationsdatei unter /boot/grub2/grub.cfg erstellen zu lassen. Dort findet man die getroffenen Einstellungen letztlich natürlich auch wieder.

Bootet man nun neu, fährt das System dann schön im Textmodus hoch und man kann einen Blick auf die schnell vorbeiziehenden Meldungen von systemd und den gestarteten Applikationen zum Bootvorgang werfen.

——–
Drei ergänzende Hinweise

Hinweis 1:Grub 2
Nebenbei haben wir mal wieder gelernt, dass Grub2 relativ kompliziert – nämlich teils über die über die “/etc/default/grub”, teils über Script-Dateien – zu konfigurieren ist. Hierzu ein paar Links;
http://www.dedoimedo.com/computers/grub-2.html
http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/grub2.html
http://manual.siduction.org/de/sys-admin-grub2-de.htm

Hinweis 2: Etwas Tipparbeit beim Umgang mit grub2 sparen
Übrigens (off topic):
Um beim Experimentieren mit Grub etwas Tipparbeit zu sparen und eine Ähnlichkeit mit (älteren) Debian-Derivaten herzustellen, kann man sich unter SuSE einen abgekürzten Befehl “update-grub” als Skript (an geeigneter Stelle im Suchpfad) hinterlegen:

#!/bin/sh
set -e
exec grub2-mkconfig -o /boot/grub2/grub.cfg “$@”

Wer sich über das “$@” wundert: grub2-mkconfig hat z.Z. zwar nur 3 Parameter, kann ja aber künftig noch mehr bekommen:

mysystem:~/bin # ./update-grub -v
grub2-mkconfig (GRUB2) 2.00
mysystem:~/bin # ./update-grub -h
Usage: grub2-mkconfig [OPTION]
Generate a grub config file
 
-o, –output=FILE output generated config to FILE [default=stdout]
-h, –help print this message and exit
-v, –version print the version information and exit
 
Report bugs to <bug-grub@gnu.org>.
mysystem:~/bin #

Hinweis 3: Kein graphischer Grub2-Bildschirm
Übrigens: Will man neben Plymouth auch den grafischen Grub2-Schirm loswerden, so muss man im oben dargestellten YaST2-Fenster den Haken bei der Option “use graphical console” entfernen. Dies führt dann zu einem Eintrag “GRUB_TERMINAL=console” in der “/etc/default/grub”.