KVM-Host – Mounten “virtueller” Gast-Partitionen aus logischen LVM-Volumes

Beim Aufsetzen eines neuen Servers schlage ich zur Zeit einen Weg ein, bei dem bestimmte Serveraspekte in virtuellen KVM-basierten Maschinen gekapselt werden sollen. Nun nutze ich auf dem KVM-Host als Basis einer flexiblen Partitionierung LVM. Die virtuellen KVM-Systeme erhalten ihre virtuellen Platten und zugehörige Partitionen in Form der Zuweisung von logischen LVM-Volumes, die auf dem KVM-Host vorliegen. Der Zugriff des Gastes auf dieses Raw-Device erfolgt in meinem Fall über “virtio”. Im Zuge der Installation des Gast-Systemes werden innerhalb der virtuellen Harddisk dann “virtuelle” Partitionen des Gastsystems angelegt. Die nachfolgende Darstellung illustriert dies:

KVM_Host_mit_LVM_V01

Aufgabenstellung: Mounten virtueller Partitionen eines KVM-Gastes auf dem KVM-Host

Der Inhalt der Aufgabenstellung hört sich nur scheinbar widersprüchlich an. Es kann tatsächlich mal vorkommen, dass man aus bestimmten Gründen gerne vom Host aus auf eine der “virtuellen” Partitionen des KVM-Gastes zugreifen möchte. Natürlich nur, wenn das KVM-Gastsystem nicht aktiv läuft und die virtuelle Harddisk nicht vom Gastsystem genutzt wird.

Bei ein wenig Nachdenken wird sofort klar: Ein solcher Zugriff des KVM-Hostes erfordert ein zwischengeschaltetes Tool – in den Partitionsverzeichnissen des Hosts wird die virtuelle Partition eines Gastes, die sich innerhalb eines logischen LVM-Volumes befindet, nicht direkt als mountbares Device bereitstehen. Die Situation ist hier vergleichbar mit der internen Struktur von Files, die als Loopback-Devices genutzt und gemountet werden. Der YaST2-“Partitioner” des Opensuse 12.3-Systems etwa lässt die interne Partitionierungs-Struktur logischer LVM-Volumes nicht erkennen. Schließlich wird ja das gesamte logische LVM-Volume von KVM als Raw-Device behandelt und enthält keine unmittelbaren Filesystem-Informationen wie eine normale formatierte (LVM-) Partition des Hosts.

Gründe für einen Zugriff auf virtuelle Partitionen der KVM-Gastsysteme vom Host aus können vielfältig sein – u.a. sind zu nennen:

  • Erstellung von Sicherungen bestimmter Inhalte des Gast-Filesystems.
  • Bearbeitung bestimmter Files des Filesystems des KVM-Gastes auch bei nicht laufendem KVM-Gast.

In meinem Fall hatte ich eine Konfigurationsdatei das Gastes verpfuscht, die ein normales Starten dieses KVM-Gastes verhinderte. Diese Datei hätte ich nun gerne vom Host aus bearbeitet, um das Gastsystem ohen Rückgriff auf Sicherungen wieder zum Laufen zu bringen.

Lösung: kpartx

Gibt es nun ein Linux-Tool mit dem man die Struktur des Raw-Devices auslesen und die Partitionen erkennen kann ? Ja, das gibt es – es heißt “kpartx”. Ich zitiere aus der zugehörigen “man-page”:

Name : kpartx – Create device maps from partition tables
Synopsis : kpartx [-a | -d | -l] [-v] wholedisk
Description : This tool, derived from util-linux’ partx, reads partition tables on specified device and create device maps over partitions segments detected. It is called from hotplug upon device maps creation and deletion.

“kpartx” kann man für verschiedene Devices oder Platten-Images einsetzen. Neben der Bereitstellung interner Partitionen von Raw-Device-Harddisks für virtuelle KVM-Systeme eignet es sich z.B. auch für den Zugriff auf Loopback-Device-Files.

Die verschiedenen Optionen von “kpartx” sehe man sich selber an. Mittels der Option “-a” erzeugt man eine vollständige Liste der Partitionen eines Raw-, LVM- oder Loopback-
Devices im Verzeichnis:

/dev/mapper

Die dortigen Einträge entsprechen unter Opensuse Links übrigens Devices der Form “/dev/dm-xx”. Diese Devices kann man dann im KVM-Host benutzen und u.a. mounten.

Ein Beispiel

Nachfolgend zur Illustration ein paar typische Kommandos für ein Testsetup:

Das Harddisk-Array der Testmaschine ist ein Raid 10-Array aus vier 2 TB-Platten. Das Array wurde mit GPT partitioniert. Die bislang aufgesetzten logischen Volumes befinden sich unter “/dev/volgrp1”. Einem virtuellen KVM-Gast wurde u.a. das logische Volume “/dev/volgrp1/vm_imap_hd0” als virtuelle Harddisk per virtio-Treiber zur Verfügung gestellt und beim Installieren des Betriebssystems OS 12.3 mit 2 “virtuellen” Partitionen – einem Swap-Bereich und einer ext4-Partition – ausgestattet.

Folgender Screenshot liefert einen Überblick:

kvm_partitions_1

Man erkennt, dass “fdisk” und “parted” den internen Aufbau z.B. des logischen LVM-Volumes “/dev/volgrp1/vm_imap_hd0” durchaus erkennen. Allerdings finden sich unter “/dev/mapper” noch keine entsprechenden Devices, die im Host direkt brauchbar und mountbar wären.

Hierfür benötigen wir nun den Befehl “kpartx” in der Form

kpartx -a /dev/volgrp1/vm_imap_hd0

kvm_partitions_2

Es wird klar, dass “kpartx -a /dev/volgrp1/vm_imap_hd0” denn internen Aufbau des logischen Volumes analysiert und entsprechende Devices unter “/dev/mapper” bzw. in unserem Fall als “/dev/dm-5” und “/dev/dm-6” bereitstellt. “/dev/dm-6” entspricht der Partition, die im virtuellen Gast als root-Filesystem gemountet wird.

Abschluss der Arbeiten mit Gast-Partitionen durch “kpartx -d”

Bitte nicht vergessen, nach dem Abschluss der Arbeiten mit den “virtuellen” Partitionen im KVM Host die Partitionen vor dem Neustart der virtuellen Maschinen wieder zu “umounten” und zur Sicherheit auch aus dem Device-Mapper zu entfernen. Letzteres ermöglicht “kpartx -d” – in unserem Beispiel:

kpartx -d /dev/volgrp1/vm_imap_hd0

Links

Natürlich ist die dargestellte Vorgehensweise nicht auf meinem Mist gewachsen. Deshalb stellvertretend für viele andere Links ein paar Hinweise auf Artikel, die für mich nützlich waren:

http://backdrift.org/mounting-a-file-system-on-a-partition-inside-of-an-lvm-volume
http://blog.normation.com/2011/04/07/mounting-partitions-stored-in-a-logical-volume-or-a-disk-image/
http://serverfault.com/questions/376421/how-to-access-partitions-inside-a-logical-volume-from-the-host-machine

Einige meiner Leser werden sich fragen, wie man die virtuellen Partitionen innerhalb eines logischen Volumes nun bei Bedarf in ihrer Größe abändern kann. Ein direktes Resizing mit LVM im Host ist hier natürlich nicht ohne größere Umwege möglich. Die Entwickler bei Red Hat haben aber den Befehl “virt-resize” bereitgestellt, der
im Zusammenspiel mit dem LVM-System des KVM-Hostes die erforderlichen Schritte sehr erleichtert. Hierzu seien dem interessierten Leser folgende Links ans Herz gelegt:

!!!!
http://unix-heaven.org/resizing-kvm-disk-image-lvm-the-easy-way
!!!!
http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file
http://libguestfs.org/virt-resize.1.html

Viel Spass nun mit KVM, LVM, logischen Volumes und “virtuellen” Partitionen !

Erster Check Opensuse 12.3

Der Artikel ist wegen eines laufenden arbeitsintensiven Projektes zwar schon etwas veraltet, aber vielleicht interessiert meine Erfahrungen mit dem Upgrade auf Opensuse 12.3 doch noch jemanden – zumal sie sehr positiv ist und SuSE ein Lob verdient:

Ich war mutig und habe inzwischen auf gleich drei Systemen ein Upgrade von Opensuse 12.2 auf Opensuse 12.3 vorgenommen. Das ging auf 2 Opensuse 12.2 Systemen (fast) wie geschmiert. Ich habe selten ein so problemfreies Upgrade wie auf diesen Systemen erlebt!
Auf einem dritten System (alter Laptop mit Nvidia FX 1500M-Karte gab es größere Probleme mit Nvidia-Treibern – sowohl unter Windows als auch unter Linux). Die ließen sich durch das Zuschalten des Nvidia-Community-Repositories für Opensuse 12.3 lösen. Das wars dann aber auch schon.

Upgrade eines einfachen Server-Testsystems

Das erste System war ein rel. schlankes Testsystem mit einem aktuellen Opensuse 12.2, vielen Server-Komponenten (LAMP, LDAP, KVM, …) und KDE 4.9 – ohne weitere Updates aus anderen Zusatzrepositories – also nur mit Paketen aus dem OSS_Update-Repo von SuSE und dem KDE-Repository. Bzgl. der Grafik-Karte lief vor und nach dem dem Upgrade der Nouveau-Treiber mit einer GTX9800+.

Zu diesem System gibt es hinsichtlich des Upgrades fast nichts zu sagen:

CD rein, 1920×1200-Auflösung und deutsche Sprache wählen, Partition mit dem upzugradenden 12.2-System auswählen, Start drücken und (im falle meiner Paketzusammenstellung) ca. 6,5 GB installieren lassen. Was die SuSE-Installationsroutine dann an Schritten durchführte, ging ohne jede Schwierigkeiten über die Bühne.

Als Bootloader wurde ein vorhandenes Grub2 upgedated. Während der Installation führte die Installationsroutine auf diesem System einen expliziten Neustart durch, bevor die Installation dann in einer zweiten Phase regulär beendet wurde.

Es wurde im Gegensatz zu früheren Installationen auf diesem System kein Kernelstart mit kexec versucht. Es gab vor und nach dem Neustart zu meiner Überraschung und im Gegensatz zu Opensuse 12.1/12.2 keinerlei Schwierigkeiten mit der Grafikkarte und dem Nouveau-Treiber. (Vielleicht sollte der SuSE-Installer das kexec-Spielchen in Zukunft ganz unterlassen?)

Der KDE-Desktop erschien schließlich im neuen SuSE-Layout, Kontact lief mit seinen Anbindungen an 2 Imap-Server (einer im lokalen Netz, einer extern) und an 2 Open-Xchange-Server (OX5, OX6, beide im lokalen Netzwerk) problemfrei. Alles im grünen Bereich. Auch die Nachinstallation eines geeigneten Treibers von der NVidia-Webseite bereitete keine Probleme.

Danach habe ich KDE auf 4.10 upgegradet sowie meine anderen üblichen Repositories geladen und entpr. Updates durchgeführt. No problem – außer den üblichen internen KDE-Themen.

Upgrade eines produktiven Entwicklungs-Systems mit etlichen Serverkomponenten

Ein wenig hakeliger lief es mit einem anderen System, das eine andere Nvidia-Karte (GTX 460) beherbergt und sich bereits auf dem Stand von KDE 4.10.1 befand. Auch hier lief alles glatt bis zum Neustart des Systems. Der wurde hier mit kexec versucht, was nach früheen Erfahrungen fast erwartungsgemäß schief ging. Irgendwie hat auf diesem System das Umschalten der Grafik-Modi mit dem Nouveau-Treiber noch nie geklappt. Es taucht noch die Meldung auf “Der Kernel wird mit kexec geladen”. Dann kommt noch “rcnscd: no such service nscd”. Anschließend reagiert der Schirm nicht mehr. Ich kenne dieses Verhalten seit Opensuse 12.1 auf verschiedenen Systemen. Irgendwie habe ich den Eindruck, dass das bei mir immer dann passiert, wenn vor dem Upgrade eines Systems der proprietäre Nvidia-Treiber von der NVidia-Webseite der aktive war. Irgendwie bekommen SuSE’s Upgrade-Routinenn dann den Wechsel zum Nouveau-Treiber nicht hin.

Das System läuft trotz
eingefrorenem Schirm allerdings weiter und installiert auch brav weiter. Man lausche ein wenig auf die Festplatten (soweit noch vorhanden und nicht durch SSDs ersetzt), warte bis die Aktivitäten aufhören und probiere dann mal CTRL-ALT-DEL. In meinem Fall half das. Das System fuhr runter, startete neu, zeigte mir ein Grub1 im neuen dunklen Opensuse-Look und ließ mich dann das neue OS 12.3-System (Desktop-Kernel) hochfahren. (Netterweiser gibt es im Grub1-menü auch eine Verzweigung in ein Grub2-Menü).

Auf diesem System erscheinen dann, wenn man die Startmeldungen von systemd und den LSB-Init-Skripten verfolgt (CTRL-ALT-F1), Fehlermeldungen zum Start von VMware (logisch, das muss ja erst neu kompiliert werden). Und dann stoppt der Prozess des Hochfahrens beim Versuch, die grafische Oberfläche zu starten.

Ein “CTRL-Alt-F2” bringt mich allerdings auf ein nutzbares Konsolenfenster. Von dort kann ich sshd starten. Dann kopiere ich mir von einem anderen Rechner per “scp” einen aktuellen Nvidia-Treiber aufs System. Achtung: Bei mir ging mit dem Kernel 3.7.10 nur die Version 310.40 des Nvidia-Treibers. Ältere Versionen bringen im Zuge der Nvidia-Installationsroutine Fehlermeldungen zu fehlenden Header-Dateien. Zur Sicherheit setze ich als Kernelparameter über YaST “nomodeset”, installiere den NVidia-Treiber und starte das System neu.

Alles läuft – die grafische Oberfläche von SuSE erscheint. Das gesamte System ließ sich dann anstandlos über diverse Repositories hinsichtlich aller Desktop- und Server-Komponenten (LAMP-Entw.-System) auf den neuesten Stand bringen und läuft nun unter KDE 4.10.2. VMware-Workstation musste ich auf die Version 9.0.2 bringen, damit die sich für den neuen Kernel kompilieren ließ. Jetzt laufen auch Win XP und Win 7 wieder im Fenster mit. Mit virtuellen Linux-Maschinen unter einem upgedaten KVM hatte ich keinerlei Probleme.

Etwas unangenehme Schwierigkeiten bereitet mir auf diesem System gerade eine vorhandene Open-Xchange 6.22-Installation. Der OX 6.22 Daemon lässt sich seit den letzten Paketupdates auf meinem System nicht mehr mit systemd (“systemctl start open-xchange”) oder “rcopen-xchange” starten. Es hilft nur ein Wechsel in das Verzeichnis /etc/init.d und dort ein manueller Start mit “./open-change start”. Das Problem ist sowohl an Open-Xchange wie auch Novell gemeldet (https://bugzilla.novell.com/show_bug.cgi?id=813767). Das Server-Backend von OX 6.22. läuft übrigens trotzdem – von Kontact aus kann man problemfrei zugreifen. Nur die OX6-Web-Dienste gehen nicht ohne den Workaround des manuellen Starts mit “./open-xchange start”.

Upgrade eines alten Dell-M90-Laptops mit alter Nvidia FX 1500M Quadro

Opensuse 12.3 habe ich auf diesem System von Opensuse 12.1 aus upgegraded. Das lief problemfrei – bis auf den Nvidia-Treiber. Meine übliche Strategie, einen Treiber von der Nvidia-Web-Seite zu nehmen, funktionierte hier gar nicht. Der Treiber 310.40 unterstützt die alte Karte nicht mehr – ältere Treiber melden dagegen Probleme mit Header-Dateien. Hier ist Nvidia offenbar zu faul, noch was für Besitzer älterer Karten in Hinblick auf 3-er Kernelversionen von Linux zu tun. Als hilfreich und zeitsparend erwies es sich dann, auf die Treiber des Opensuse Nvidia-Repositories zurückzugreifen. Der im Paket “nvidia-gfxG02-kmp-desktop” enthaltene Treiber funktioniert anstandslos mit der Quadro FX 1500M. Alle anderen Systemkomponenten des alten Dell M90 wurden durch Opensuse 12.3 anstandslos, auf Anhieb und perfekt unterstützt. Super!

Ich möchte ausdrücklich sagen, dass ich auf diesem Laptop-System aus Projektgründen auch Windows 7 (64Bit) als Dual-Boot-Option installieren musste. Win 7 (64Bit) bootet zugegebenermaßen zwar rasch und ist insgesamt spürbar schneller als XP – aber die Installation erwies sich hinsichtlich von Treibern als viel, viel größeres Problem als das Linux-Upgrade.

Ich musste Zusatztools installieren, um überhaupt an
geeignete Treiber für etliche Systemkomponenten zu kommen. Die Windows-Installation (natürlich ohne Serverkomponenten) kostete mich insgesamt etwa doppelt so viel Zeit wie der Opensuse 12.3 Upgrade. Und – ehrlich – der Windows 7 Desktop wirkt nicht nur langweilig – er ist es gegenüber modernen Linux-Desktops auch. Man muss sich die Tortur mit Windows doch immer mal wieder antun, damit man wieder mal weiß, was man an einem modernen Linux-System hat!

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”.