MySQL – SELECT INTO OUTPUT FILE – vermeide zusätzliche UNION Statements!

Posted on 8. January 2015 by Ralph Mönchmeyer

Wenn es um den Export relativ großer Tabellen in CSV-Dateien geht, greift man bei MySQL-Datenbanken auf eine spezielle Form des SELECT Statements, nämlich “SELECT INTO OUTPUT FILE … “. Ich nenne das nachfolgend der Einfachheit halber ein “Export SELECT”. Siehe hierzu:
http://dev.mysql.com/doc/refman/5.7/en/select-into.html

Oftmals benötigt man aber nicht nur die reinen Daten sondern eine CSV-Datei mit einer führenden Zeile, in der die Bezeichnungen der einzelnen Felder/Spalten auftauchen (“column heading”). Die gängige Empfehlung vieler Beiträge zu diesem Thema ist, das Ergebnis des oben genannten Statements “SELECT INTO OUTPUT FILE … ” per UNION mit einem “künstlichen SELECT-Statement zu verbinden, dass genau die Strings der ersten Zeile erzeugt. Siehe hierzu etwa
http://stackoverflow.com/questions/356578/how-to-output-mysql-query-results-in-csv-format (und dort einen entsprechenden Kommentar zum Lösungsansatz der Forums-Frage)
oder aber
http://www.mysqltutorial.org/mysql-export-table-to-csv/
und dort der Abschnitt zu “Export Data with Column Headings”.

Entsprechende Vorschläge folgen dem Muster A

(SELECT 'Name of Column 1', 'Name of Column 2', 'Name of Column 3')
UNION
(SELECT column_name_1, column_name_2, column_name_3
FROM TABLE_NAME
INTO OUTFILE 'absolute_path_to_csv_file'
FIELDS ENCLOSED BY '"' TERMINATED BY ';' ESCAPED BY '"'
LINES TERMINATED BY '\r\n');

Festzustellen ist hierzu Folgendes:

Ein solches Statement funktioniert zwar und produziert das gewünschte Ergebnis; aber es reduziert die Performance des Daten-Exports in eine Datei drastisch – speziell wenn man mit großen Tabellen und mehreren Millionenen oder gar Hunderten von Millionen Records arbeitet. Dann entfaltet sich das UNION-Statement zu einem echten Performance-Killer!

In einem konkreten Testbeispiel konnte ich den Export aus einer Datei mit einer Million Records vergleichen. Der Export mit einem Union Statement dauerte fast 50 Sekunden; läßt man die Kopfzeile dagegen nach dem Muster B

SELECT column_name_1, column_name_2, column_name_3
FROM TABLE_NAME
INTO OUTFILE 'absolute_path_to_csv_file'
FIELDS ENCLOSED BY '"' TERMINATED BY ';' ESCAPED BY '"'
LINES TERMINATED BY '\r\n';

weg, so dauerte der Export nur 1,8 Sekunden. Das Verhältnis wird noch schlimmer bei größeren Record-Zahlen der Tabelle.

Ein wenig tieferes Nachdenken und eine SQL-Analyse mit “Explain” machen auch klar, woran das liegt: Der Einsatz von UNIONS erfordert das Zusammenfügen der Resultsets der verschiedenen SELECTs. Dazu muss jedes Resultset aber erstmal generiert werden. Dazu müssen temporäre Datenhaltungsstrukturen aufgebaut werden. Dies kollidiert jedoch mit der ansonsten speziell optimierten Funktionalität des “SELECT INTO OUTPUT FILE”-Statements, nämlich die Tabelleninhalte aus den Datenbankfiles mit speziellen Methoden direkt auszulesen und sofort in eine Datei zu schreiben.

Ich kann daher nur jedem raten, beim Export wirklich großer Tabellen in CSV-Dateien auf jegliche Kombination des “SELECT INTO OUTPUT FILE”-Statements mit anderen SELECTS unter Rückgriff auf “UNION” zu verzichten. Das zieht ggf. den Verzicht auf eine erste führende Zeile nach sich.

Änderung und Nachtrag 08.01.2015:
In Fällen mit kleineren Dateien von bis zu n x 100 MByte kann es – je nach RAM-Ausstattung des Systems
– u.U. besser sein, zunächst den reinen Daten-Export (gem. Muster B) durchzuführen und danach die erzeugte Datei mit PHP File-Funktionen oder Systemfunktionen nachzueditieren und die gewünschte erste Zeile mit der Feldinformation hinzuzufügen. Das ist aber zu testen. In meinem Testfall mit 1 Million Datensätzen war das File kleiner als 50 MByte und lag auf einer SSD. Zudem ist das System hinsichtlich der Plattenzugriffe gut gepuffert. In diesem Fall erhöhte sich die benötigte Zeit durch das Hinzufügen der Kopfzeile untr PHP kaum spür- und messbar über die 1,8 Sekunden hinaus. Die Änderung war gegenüber dem oben erwähnten Zeitunterschied des UNION-Statements völlig vernachlässigbar.

Bei Dateigrößen von mehreren hundert Mbyte oder gar im GByte-Bereich wird ein nachträgliches Editieren unter PHP aber ebenfalls zu Problemen führen, da das File erst einmal zu lesen und dann mit dem String für die erste Zeil zu konkatenieren ist. Man muss in Tests prüfen,

ob das für solche Operationen erlaubte Memory unter PHP hinreichend ist (und es ggf. anpassen)
und ob sich die Lesezeit unter PHP als kleiner oder größer als die von MySQL aufgebrachte Zeit für ein UNION herausstellt.

Am besten erscheint es mir, bei wirklich großen Datenmengen im Sinne der Performance schlicht und einfach auf die führende Kopfzeile zu verzichten. Derjenige, der das exportierte CSV-File in irgendeiner Weise nutzen will, muss eben über die Feldreihenfolge Bescheid wissen.

PHP Code Content Assists und Inline Type Hinting in Eclipse

Posted on 6. January 2015 by Ralph Mönchmeyer

Vor ein paar Jahren war ich sehr happy, als ich entdeckte, dass Eclipse mit dem PHP Pluging (PDT) etliche Möglichkeiten im Bereich des PHP Content Assistings bietet. So nutze ich die Möglichkeiten des Type Hintings mittels “phpDocumentor tags” ausgiebig oberhalb der Deklaration von Class Member Variablen oder bei der Definition von Funktionen (frei oder als Objekt-Methoden). Es ist einfach schön, bequem und sehr effizient, wenn “Ctrl-Space” das Tippen von neuem Code in einem PHP-Projekt mit passenden Vorschlägen aufgrund der Definition von Klassen etc. in anderen Dateien unterstützt. Fast magisch !

Was ich bisher nicht hinbekommen hatte, war das Type Hinting und “Content Assisting” zu Variablen im PHP-Code, die im Rahmen einer dynamischen Namensgebung über die Nutzung der Funktion “call_user_func” als Objekt einer Klasse instanziiert werden. Das braucht man z.B., wenn man das Singleton-Pattern benutzt und das Singleton-Objekt entweder erstmalig instanziiert werden muss oder aber die Referenz auf das ggf. schon existierende Singleton-Objekt geholt werden soll – soweit es bereits woanders instanziiert wurde.

Aber auch das geht unter Eclipse PDT mit sog. “Inline Type Hinting”. Ein Beispiel:

	$get_instance ="getInstance"; 
	$Class_SS_Run_Data_Name = "Class_SS_Run_Data";
	$ay_SS_Run_Data		= array($Class_SS_Run_Data_Name, $get_instance);

	/* @var $SS_Run_Data Class_SS_Run_Data */		
	$SS_Run_Data = call_user_func($ay_SS_Run_Data);
	unset($ay_SS_Run_Data);

getInstance ist hier eine statische Methode, die gemäß des Singleton Patterns entweder das Objekt instanziiert oder die Referenz auf das Singleton Objekt aus einer statischen Variablen ermittelt.

Wichtig ist hier aber die Kommentar-Zeile und ihr Aufbau. Die Klasse “Class_SS_Run_Data” ist in einer anderen Datei definiert, deren Source Pfad natürlich im Bereich des BUILD Path des PHP-Projektes liegen muss.

Tippe ich nun später “$SS_Run_Data->” im Code erhalte ich je nach Einstellungen des Content Assistings umgehend oder spätestens über Ctrl-Space eine Vorschlagsliste zu Variablen oder Methoden der Klasse. Super !

Gelernt habe ich das nach Lesen eines Artikels von Norm McGarry, der sich mal die Mühe gemacht hat, die verschiedenen Arten des “Type Hintings” für “Content Assist”-Zwecke unter Eclipse PDT zusammenzustellen. Siehe:
PHP Type Hinting with Eclipse

Herzlichen Dank an Norm McGarry!

Münchens LIMUX und ein Editorial des Linux-Magazins

Posted on 3. January 2015 by Ralph Mönchmeyer

Eine Bekannte hat mich im September diesen Jahres fast schadenfroh darauf aufmerksam gemacht, dass das LIMUX-Projekt der Stadt München in Gefahr sei. Verwiesen hat sie in diesem Zusammenhang auf einen Artikel in der SZ:
http://www.sueddeutsche.de/muenchen/muenchner-stadtverwaltung-von-microsoft-zu-linux-und-zurueck-1.2090611

Auch wenn inzwischen im Magazin Linux-User und in anderen Zeitungen “Entwarnung” gegeben wurde, lohnt es sich dennoch, sich etwas ausführlicher mit dem Vorgang zu befassen. Ein Grund unter mehreren ist für mich die Art und Weise, wie in diesem Fall von einem nicht ganz unwichtigen Linux-Befürworter mit Kritik an einem Linux-Desktop umgegangen wurde. Aus meiner Sicht wurde – wie zu oft – zu schnell abgebügelt. Dabei bleiben dann valide Punkte auf der Strecke, und man kocht schön weiter im eigenen Saft. Ist ja auch bequemer so …

Aber der Reihe nach.

Eine Diskussion zum LIMUX-Projekt mit IT-Professionellen in meinem Bekanntenkreis verläuft meist so,

dass Linux-Befürworter das Desktop-Projekt der Münchner Stadtverwaltung als Beleg dafür heranziehen, dass Linux sehr wohl auch am Arbeitsplatz und nicht nur auf Servern einsetzbar sei,
dass Linux-Skeptiker dagegen den Nutzen und die Einsparungen bezweifeln,
dass Linux-Skeptiker grundsätzlich nicht glauben, dass die betroffenen Anwender zufrieden sind und sie dafür gerne belastbare Belege sehen würden.

Dabei sind die Linux-Skeptiker – meist Leute, die täglich mit Windows arbeiten und oft auch eine frustrierende Erfahrung mit dem Versuch einer eigenen Linux-Installation hinter sich haben – in der erdrückenden Überzahl. (Das sind natürlich trotzdem nette Menschen …). Repäsentatives, belastbares Material zu Kosten und User-Zufriedenheit im Umgang mit Linux-Desktops legen beide Seiten in der Regel nicht vor. Und nur selten werden die Anforderungen an einen modernen Desktop in der Arbeitswelt und die erforderlichen Applikationen als Grundlage einer sachlichen Diskussion spezifiziert.

Die SZ-Nachricht platzte ins Ende der Sommerpause. So ging das Thema in der interessierten Öffentlichkeit zunächst fast unter. In der kurz darauf erschienenen Ausgabe 10/14 des Linux-Magazins, in dem das LIMUX-Projekt auch schon in der Vergangenheit (trotz vieler Verzögerungen und Probleme) vielfach gelobt wurde, platzierte man LIMUX auf Platz 11 unter den größten 20 “Tops” der Linux-Geschichte.

Generell ist festzuhalten, dass das LIMUX-Projekt in den deutschen Postillen der Linux-Welt immer wieder als Vorzeige-Projekt dargestellt und positiv kommentiert wurde. So wurde im Linux-Magazin oder in der Schwester-Zeitschrift Linux-User mal der Fortschritt des Rollouts auf geplante ca. 15000 Arbeitsplätze positiv gewürdigt oder der wohltuende Einfluss von Ubuntu auf das Projekt hervorgehoben.

Nach genauem Studium der jeweiligen Artikel fällt auf, dass das SW- und Applikationsangebot des LIMUX-Desktops auch in der Fachpresse so gut wie nie spezifiziert oder diskutiert wurde. Auch als Linux-Befürworter fragt man sich zwangsläufig, wieviel die Autoren eigentlich über den wahren Leistungsstand des LIMUX-Desktops im Vergleich z.B. zu einem aktuellen KDE 4.x-Linux-Desktop in einer dazu passenden leistungsfähigen Serverlandschaft recherchiert hatten. Siehe zu aktuellen Spekulationen bzgl. dieses offenen Punktes etwa
https://debianforum.de/forum/viewtopic.php?f=15&t=150995. Überhaupt ist die Frage zu stellen, welcher Maßstab eigentlich zur Bewertung des Erfolges eines SW-Rollouts heranzuziehen wäre – die Tatsache, dass der Rollout für die geplante Useranzahl gelungen ist, reicht alleine vielleicht nicht. So wäre u.a. die weiterführende Frage zu
stellen:
Was zeichnet eigentlich das LIMUX-Anwendungsangebot im Verhältnis zu den Bedürfnissen von Verwaltungsangestellten aus ?

Es verwundert wenig, dass in einem faktenarmen Diskussionsumfeld bei den Linux-Skeptikern angesichts der SZ-Meldung ein Schuss Schadenfreude zu spüren war. Aber schon früher kam offene Kritik – manchmal sogar aus einer Ecke, wo zumindest ich das zuletzt erwartet hätte (http://www.silicon.de/41595329/ob-kandidatin-kritisiert-limux-projekt-in-muenchen/). Auf der anderen Seite machen es sich die Linux-Befürworter zu leicht, wenn sie den Erfolg von LIMUX oftmals ausschließlich am Projektverlauf festmachen. Wenn dann plötzlich Kritik an der Leistungsfähigkeit auftaucht, ist man eher überrascht.

Wie reagierten nun publizistische Vertreter der Linux-Community auf die Kritik der Münchner Bürgermeister?

Ein Editorial im Linux-Magazin

Im Linux-Magazin 11/2014 bezog als einer der Ersten Chefredakteur Jan Kleinert Stellung:

In seinem Editorial “Ende der Fahnenstange” werden der Münchner OB und einer der Bürgermeister als “Außerirdische” karikiert, die nicht verstünden, um welch komplexe Technik es sich bei den eingeführten Systemen handeln würde. LIMUX wird dabei salopp mit “IT einer 1,4 Millionen Stadt” gleichgesetzt. Herr Kleinert verweist ferner darauf, dass ein Tablet-PC (oder gar ein Handy) nur wenig komplexe Aufgaben zu verrichten habe und deshalb (im Gegensatz zu einem Desktop?) eine gute Usability bieten könne. Ferner sei Sicherheit (“Funktionssicherheit”) beim Tablet-PC nur mäßig relevant (?!?). Kleinerts Text impliziert weiter, dass Linux in der Verwaltung einer Millionenstadt natürlich wesentlich mehr und Fundamentaleres leisten müsse – er rekuriert dabei nach meiner Ansicht in völlig unangebrachter Weise auf das extreme Beispiel der Steuerung von Brennstäben in Reaktoren. Damit sollte wohl das Spektrum an IT-Anwendungen und Technologie aufgezeigt werden. Bei der sensiblen Reaktorsteuerung kämen ja auch nicht moderne Usability-Kriterien zum Tragen. Die von einem der aktuellen Münchner Bürgermeister vorgebrachte Kritik, dass er zu Hause unter Linux nicht mal einen mobilen E-Mail- und Kalender-Client zur Verfügung habe, erscheint im Kontext der Gedankenführung des Editorials dann natürlich fast kleingeistig. Das Wesen der IT bestehe im Gegensatz zur geäußerten Kritik an LIMUX eben im Kompromiss zwischen Komplexität, Funktionssicherheit und Innovation. Aha!

Alles also nur eine fachlich unfundierte, politische Welle der neuen Stadtregierung? Vorgebracht von voreingenommenen Linux-Skeptikern? (Zu denen manche gerade die Bürgermeister zählen; s. http://www.linux-magazin.de/NEWS/Microsoft-Fan-Muenchens-neuer-OB-Reiter-will-in-Sachen-Limux-neue-Loesung-finden, http://www.heise.de/open/meldung/Muenchner-Buergermeister-sieht-deutliche-Schwaechen-bei-LiMux-2391735.html, http://www.golem.de/news/limux-kopf-einziehen-und-ueber-verschwoerung-tuscheln-1412-110908-4.html).

Ich habe dazu eine andere – und durchaus kritischere – Meinung als der ansonsten von mir sehr geschätzte Herr Kleinert. Denn selbst wenn man den von ihm geforderten Kompromiss als Basis für die Bewertung einer bereits in die Jahre gekommenen IT-Lösung heranziehen würde, könnte man die Kritik der Bürgermeister ja so deuten, dass die LIMUX-Lösung unter den vielen technischen Möglichkeiten womöglich gerade nicht den optimalen Kompromiss darstellt. Und das führt dann zu einer Fragestellung, bei der
auch Herr Kleinert mit Sicherheit einige Mühe hätte, eine faire und vor allem fundierte Antwort zu finden.

Im Gegensatz zu den professionellen Linux-Meinungsmachern erlaube ich mir ferner, den Verdacht zu hegen, dass sich in den zitierten Äußerungen der Bürgermeister (neben einer evtl. politisch begründeten Neuausrichtung der IT-Politik der Stadt München) eine vielleicht nicht nur positive Erfahrung der inzwischen vielen Anwender bei der Landeshauptstadt München ihren Weg bahnt. Auch wenn wir das als Linux-Anhänger natürlich nicht gerne hören mögen. Denn vielleicht hat ja gerade die Einführung von etlichen sich schnell entwickelnden und lange Zeit keinesfalls fehlerfreien Linux-Anwendungen (wie etwa das wohl auch unter LIMUX genutzte Thunderbird, Open- bzw. Libreoffice sowie etliche KDE-Applikationen) oder gar ein Mangel an integrierten Anwendungen die gewohnte “Funktionssicherheit” aus Sicht der Anwender beeinträchtigt ?

Je mehr ich im Laufe der vergangenen 2 Monate darüber nachdachte, desto mehr ärgerte mich eigentlich das Editorial von Herrn Kleinert, dessen Aufmacher im Linux-Magazin und dessen kritische Begleitung aktueller Ereignisse im Linux- und IT-Umfeld ich ansonsten wirklich sehr schätze. Das sei ausdrücklich gesagt!

Der Grund meines Ärgers ist die Pauschalisierung bei der Abqualifizierung von vermeintlich unbedarften Nutzern, die schnell als eingefleischte Linux-Skeptiker entlarvt werden. Aber müssen wir uns als Linux-Befürworter nicht gerade der Kritik dieser Leute stellen ? Nicht nur bei Herrn Kleinert kommt leider viel zu oft das Muster zum Tragen, sich selbst mit Verweis auf die Inkompetenz und die Vorurteile anderer konsequent an der kritischen Betrachtung eventuell ausgeblendeter Fakten und Hintergründe zu hindern.

Warum ist das Editorial des Linux-Magazins wenig hilfreich?

Die Haltung des Editorials im Linux-Magazin verdient aus meiner Sicht deutliche Kritik :

So geht der Leitartikel des Linux-Magazin bezeichnenderweise nicht darauf ein, dass es sich beim LIMUX-Projekt und dem zugehörigen Rollout primär um Desktop-Technologie handelt. Ob die funktioniert, können die Betroffenen – darunter auch die Bürgermeister – ja womöglich doch aus eigener Anschauung beurteilen. Denn was ein moderner Desktop an Mindestfunktionalität bieten kann oder muss, erfahren sie nicht nur im eigenen täglichen Umgang mit der bereitgestellten Funktionalität. Nein, sie sehen Beispiele für andere Lösungen selbstverständlich auch an den Arbeitsplätzen anderer Verwaltungsorganisationen. Oder erleben im persönlichen Kontakt, welche Möglichkeiten andere Bürgermeister und Verwaltungsangestellte mit deren dienstlichen, mobilen Devices nutzen können. Und dann könnte es ja zumindest theroretisch möglich sein, dass der Vergleich für den einen oder anderen betroffenen Münchner Anwender aus guten Gründen negativ für LIMUX ausfällt – nicht nur bei oberflächlicher Betrachtung.

Der direkte Vergleich mit anderen Benutzeroberflächen wartet beim normalen Anwender zudem meist zu Hause – in Form von Windows-PCs, modernen Smartphones, Tablet-PCs … Trotz aller berechtigten Sicherheitsfragen – der moderne Linux-Desktop muss sich an der von anderen Systemen gebotenen Usability messen lassen. (Wobei ich keine Zweifel habe, dass ein aktueller Linux-Desktop dabei sehr gut abschneiden würde, wenn denn im Rahmen der finanziellen Möglichkeiten das Beste aus dem Desktop und den im Hintergrund zu nutzenden Serverdiensten herausgeholt würde).

Warum Herr Kleinert das Anliegen eines Managers (und als solchen sehe ich einen Bürgermeister unter anderem), einen mobilen E-Mail- und Kalender-Client mit Anbindung an einen städtischen Mailserver nutzen zu wollen, übel nimmt, verstehe ich nun überhaupt nicht. Das ist aus meiner Sicht zunächst ein völlig (!) berechtigtes Anliegen – ebenso wie der Abgleich der mobilen Devices mit Client-Applikationen am Arbeitsplatz oder
bestimmten Inhalten bestimmter Server. Typischerweise erledigt man diese Aufgaben an einem Windows-Arbeitsplatz über eine Groupware-Anwendung. Nun dürfte auch Hrn. Kleinert nicht verborgen geblieben sein, dass gerade dieser Bereich eine Schwachstelle so mancher Opensource-Group- und Kollaborations-Software darstellt. Aber stellt er die für eine sachliche Bewertung erforderliche Frage, was LIMUX denn in diesem Bereich an Lösung anbietet?

Dass man im Zuge einer Umsetzung der genannten Ansprüche Sicherheitsaspekte bedenken und dem User Kompromisse abnötigen muss, versteht sich von selbst. Aber Schritt 1 ist, die Anforderung des Users ernst zu nehmen und dann (u.a.) zu fragen, was eine durch Linux geprägte IT-Landschaft benötigt, um diese Anforderung so optimal wie möglich umzusetzen. Dabei ist natürlich mehr zu betrachten als nur der Desktop – jedoch in anderer Weise, als Herr Kleinert das tut. Ich komme darauf weiter unten zurück.

Es stimmt zwar – und da stimme ich Hrn. Kleinert zu :
Ein moderner Desktop allein stellt heute auch schon ein recht komplexes System dar – erst recht, wenn man seine Interaktion mit unterstützenden Server-Systemen in Betracht zieht.

Aber es gilt auch:
Die Einsetzbarkeit eines Desktops und dazu gehöriger Komponenten im täglichen Business bewerten zu können, liegt sicherlich nicht außerhalb des Beurteilungsvermögens der Anwender. Und ist nicht grundsätzlich gerade der Anwender selbst die letzte Instanz, die man im Zusammenhang mit Desktop-Funktionalität ernst nehmen sollte?

Ich finde es einfach kontraproduktiv, wenn Anwender, die sich in ihrer täglichen (mobilen) Arbeit nicht hinreichend durch die IT unterstützt fühlen und dies in ihrer amtlichen Funktion auch äußern, in der Linux-Presse nicht ernst genommen werden. So ist es zwar wohlfeil und einfach, Kritiker von LIMUX oder anderer Linux-Desktop-Varianten in eine bestimmte Ecke zu stellen – sinnvoller wäre es aber, zu recherchieren und sich offen damit auseinanderzusetzen, welche Resonanz denn der LIMUX-Desktop bei seinen ca. 15000 Anwendern wirklich erfahren hat und ob es nicht auch an der einen oder anderen Stelle berechtigte Kritik am Leistungsumfang geben mag. Davon könnte man dann vielleicht etwas lernen und der eigenen Augenwischerei gerade im Interesse von Linux ein Ende setzen. Und man muss das viel systematsicher angehen als der wohlgemeinte Versuch der PC-Welt (http://www.pcwelt.de/ratgeber/LiMux__Wohin_steuert_Linux_in_Muenchen_-Windows-Ersatz-8920737.htmls).

Nur weil die Stadt München sich vor langer Zeit aus sicher guten Gründen für einen Linux-Desktop entschieden hat, ist dies nicht mit einem Qualitätsurteil zu Linux gleichzusetzen. Zumal die Einsparung von Lizenzkosten und die Reduktion von Abhängigkeiten bei der Einführung sicher ebenso wichtige Motive waren wie eine hinreichende Anwenderfreundlichkeit.

Nebenbei: Typischerweise gehört die Gruppe der professionellen Linux-Desktop-User – wie Herr Kleinert – nicht zur Gruppe der Angestellten in der öffentlichen Verwaltung. Sonst wäre das LIMUX-Projekt ja gar nichts Außergewöhnliches. Es darf daher mit Fug und Recht bezweifelt werden, ob gerade Herr Kleinert die Anforderungen eines Bürgermeisters an eine Desktop- oder Laptop-Oberfläche (im Zusammenspiel mit Mobilität und anderen mobilen Devices) richtig einordnen kann.

Spekulationen statt Fakten zum LIMUX-Desktop

Ich hatte selbst Gelegenheit und in gewisser Weise auch das Privileg, täglich über mehrere Jahre mit dem Linux-Desktop der Landeshauptstadt München arbeiten zu dürfen. Ich hatte und habe allerdings keine Einsicht in Interna des LIMUX-Projektes und zugehörige Entscheidungen. Deswegen halte ich mich bzgl. einer Kommentierung des LIMUX-Projektes und des Rollouts der zugehörigen Systeme insgesamt explizit zurück. Auch die Entscheidung der
Verantwortlichen für eine bestimmte Desktop-Variante will und mag ich im Moment überhaupt nicht in Frage stellen.

Als erfahrener Linux-Anwender hatte ich selbst auch nie ernsthafte Probleme, mit dem Desktop im Rahmen der angebotenen Möglichkeiten zu arbeiten. Aber: Ich habe mich so manches Mal nach den Möglichkeiten meiner eigenen (frei-) beruflich und professionell genutzten Linux-Desktops und -Notebooks innerhalb der für sie spezifisch ausgelegten Netzwerk-, Server- und Groupware-Umgebung gesehnt. Und dabei musste ich beim LIMUX-Einsatz nicht mal mobil arbeitsfähig sein wie die jetzigen Bürgermeister.

Auf Details der angebotenen Lösung mag ich hier aus guten Gründen nicht eingehen. Bezeichnend finde ich allerdings für die gesamte Diskussion, dass bei den Linux-Befürwortern erst in letzter Zeit zum Leistungsvermögen von LIMUX spekuliert und recherchiert wurde:
https://debianforum.de/forum/viewtopic.php?f=15&t=150995 und dort den Beitrag von MrGerardCruiz oder
http://www.pcwelt.de/ratgeber/LiMux__Wohin_steuert_Linux_in_Muenchen_-Windows-Ersatz-8920737.html

Nehmen wir mal an, die in den oben genannten Links diskutierten Punkte würden zutreffen. Würde man eine integrierte Groupware-und Daten-Abgleich-Funktionalität, wie ich sie aus meinem eigenen Linux-Umfeld und anderen Installationen seit nunmehr einem Jahrzehnt von Lotus-, Open-Xchange, Zarafa oder auch Kolab-Lösungen in ganz praktischer Form kenne, nicht vermissen? Speziell an einem Verwaltungsarbeitsplatz? Hallo Hr. Kleinert, genau das kritisieren die Bürgermeister im Rahmen ihres technischen Verständnisses!
(Von Workflow-Vernetzung und der mobilen Nutzung von Kollaborationsdiensten unter Portallösungen wie Liferay will ich erst gar nicht reden …)

Dazu käme – soweit zutreffend sicher aus wohlüberlegten Gründen – ein Client, der schon 2009 in seiner Konfiguration gegenüber damals aktuellen “KDE 4”-Clients angestaubt wirken musste. Und was das Linux-Magazin nicht erwähnt: Ubuntu als neuer Unterbau würde dem Anwender nur begrenzt etwas nutzen, wenn man darauf z.B. eine eigene (Trinity-basierte) KDE-3.5-Oberfläche aufsetzte und – soweit die von der PC-Welt durchgeführten Interviews denn zuträfen – entsprechend veraltete Client-Software anböte.

Sicher, man kann sich als Linux-Anwender damit arrangieren – toll und überzeugend wäre eine solche Lösung aber noch lange nicht.

Aus meiner langjährigen eigenen Erfahrung mit dem manchmal schwierigen Update- und Upgrade-Management einer professionell genutzten Linux-KDE-Umgebung möchte ich allerdings auch Folgendes klar zum Ausdruck bringen:

An dem Vorhaben, eine eigene Linux-Desktop-Distribution für viele User auf Dauer zu managen, kann man sich in der Praxis die Zähne ausbeißen. Gerade weil das Innovationsmoment unter Linux so extrem hoch ist. Das Bedürfnis nach durchgehender Stabilität der Desktop-Umgebung UND ihrer vielfältigen Anwendungen sieht in einem großen Unternehmen mit tausenden von Standardarbeitsplätzen nun wirklich ganz anders aus als an privaten Linux-Arbeitsplätzen oder an Linux-Arbeitsplätzen für hochqualifizierte, flexible Entwickler und Linux-Fans.

Aus meiner Meinung, dass das Qualitätsmanagement unter Linux im Sinne einer Langzeit-Stabilität von Desktops und der von Hrn. Kleinert beschworenen “Funktionsstabilität” ihrer Anwendungen schlecht funktioniert und dass hier u.a. die Distributoren in der Rolle eines zwischengeschalteten QM-Managements völlig versagen, habe ich schon mehrfach keinen Hehl gemacht. [Auf der Server-Seite bietet sich mir dagegen ein viel positiveres Bild – im Fokus steht hier aber Desktop-Technologie].

Die Aufgabe, auf Dauer eine stabile Linux-Desktop-Umgebung bereitzustellen, würde aus meiner Sicht jedes größere
Unternehmen vor enorme Herausforderungen stellen. Insofern kann man den Schwierigkeitsgrad der Aufgabe, vor der die Verantwortlichen der Stadt München standen gar nicht überschätzen und Fundamentalkritik wäre völlig unangebracht. Vielmehr sollte sich die Linux-Community selbst mal fragen, was man für stabile Linux-Desktops in Großunternehmen und in der öffentlichen Verwaltung eigentlich an Qualitäts- und Stabilitätsmanagement aufbauen müsste. Obwohl gerade im KDE-Bereich in den letzten Jahren vieles sehr viel besser geworden ist, glaube ich dennoch, dass das Innovationsinteresse der Entwickler noch nicht hinreichend mit Stabilitätsinteressen der Anwender und vielleicht auch professioneller SW-Firmen, die gerne kommerzielle Anwendungen für einen Linux-Desktop entwicklen wollen, in Einklang gebracht wurde.

So gesehen, ist die Tatsache, dass der LIMUX-Desktop tatsächlich auf Tauende von Arbeitsplätzen ausgerollt werden konnte, eher eine hervorragende Leistung der Münchner IT-Verantwortlichen und Projekt-Manager.

Man sieht: Der Erfolg oder Mißerfolg eines Linux-Desktop-Projektes hängt vom angelegten Maßstab ab. Und genau da verläuft die Diskussion auch bei den Linux-Befürwortern jenseits einer sachlichen Grundlage.

Ein moderner Linux-Desktop muss sich selbstverständlich auch für einen Bürgermeister als Anwender mit besonderen Anforderungen bewähren

Trotz des formalen Abschlusses des LIMUX-Projektes gilt mit Sicherheit: Gerade ein Desktop muss sich im Alltag erst bewähren. Erst recht in der Welt der Verwaltung und den dortigen Ansprüchen an kontrollierte Arbeitsflüsse. Hierzu zählt in einer modernen arbeitsteiligen Welt übrigens auch die (von den Bürgermeistern kritisch gewürdigte) Austauschbarkeit der Arbeitsergebnisse mit den Anwendungen anderen Verwaltungen und nicht zuletzt auch mit den elektronischen Systemen der betrofenen oder interessierten Bürger.

So ist also auch ein Bürgermeister – egal welcher politischen Richtung – ein Anwender mit berechtigten Bedürfnissen. Aus Sicht der fachlichen und technischen Ansprüche (Mobilität, verschiedene Clients, Home Office, Sicherheitsbedürnisse) sogar ein hochinteressanter:

Als intern und extern vielfach geforderter, mobiler Mensch bedarf er in seiner Arbeit an PCs, Laptops, Smartphones, Tablet-PCs der technischen Unterstützung durch so schöne Dinge wie Web-Services, Portallösungen, Web-Clients für Groupware-Lösungen, VPNs etc.. Und wenn wir uns einige der Worte mal in ihrem technischen Gehalt ausmalen, dann entdecken wir etwas ganz Banales, aber für ein Desktop-Einführungsprojekt wie LIMUX etwas Grundlegendes, das im Zusammenhang mit der vorgebrachten Kritik von größerer Bedeutung sein könnte:

Die Einführung eines Desktops allein genügt für ein funktionierendes, modernes Linux/LIMUX-Environment in der Verwaltung womöglich gar nicht …. man braucht dann auch ein geeignetes Portfolio an anpassbaren Serverdiensten, eine hinreichend (segmentierbare) Netzwerk- und Infrastruktur sowie eine Vielzahl von Security Appliances, mit deren Hilfe man von außen und innen initiierte Interaktionen mit (Server-) Systemen in sicherer Weise abwickeln kann.

Aber wird dieser wichtige, vielleicht entscheidende Punkt im Editorial von Herrn Kleinert aufgegriffen? Nein! Dabei könnte man gerade an diesen Aspekt die Frage knüpfen, woran es denn wohl liegen mag, dass die Bürgermeister und andere Anwender nicht von mobilen Geräten aus einen hinreichenden Zugriff auf bestimmte Daten bekommen. Denn vielleicht liegt es ja gar nicht am Linux-Desktop – vielleicht liegt es an Sicherheitsfragen im Zusammenhang mit einer ggf. (z.Z. noch) unzureichenden Netzwerk-, Server- und vor allem (serverbasierten) Dienste-Infrastruktur? Vielleicht haben wir es mit einer Desktop-Einführung zu tun, zu der die weitere Infrastruktur erst noch nachgezogen werden muss? Aus welchen (vielleicht durchaus berechtigten) Gründen auch immer?
n
Möglicherweise ist ja ganz generell eine hinreichende serverbasierte Dienste-Landschaft eine notwendige Voraussetzung für die erfolgreiche Ablösung von Windows-Desktops und/oder zugehöriger Desktop-Anwendungen, die der Anwender in der Verwaltung benötigt? Vielleicht könnte man aus den Erfahrungen mit LIMUX wichtige Schlüsse für die Vorbereitung anderer Linux-Desktop-Projekte in ähnlicher Größenordnung ziehen?

Der technisch unbedarfte städtische Anwender des Linux/Limux-Desktops spürt ggf. nur : Mir fehlt was. Er sieht nicht unbedingt die Ursachen – aber seine Ansprüche sollten doch zumindest ernst genommen werden. Denn erst dann kann man sich sinnvoll auf die Suche nach den Ursachen der Defizite begeben und diese Ursachen auch bewerten. Der karikierende Verweis auf Außerirdische nutzt jedenfalls gar nichts und bringt weder die Linux-Kritiker noch Befürworter einen einzigen Schritt weiter.

Eine ausführliche Analyse der Anwender-Erfahrungen mit dem LIMUX-Desktop im Zusammenhang mit der der sonstigen Infrastruktur könnte dagegen im Interesse von Linux helfen, die Frage zu klären, was die erfolgreiche Einführung eines im modernen Büro-Alltag arbeitstauglichen Linux-Desktops eigentlich an Voraussetzungen in der Netzwerk- und Server-Umgebung sowie an Serverdiensten erfordert. Auch die Verwaltung der Stadt München könnte hier mit einer offenen Darstellung der Fakten zur Versachlichung und Verbesserung der Diskussion beitragen – und im Gegenzug Hilfestellung der Linux-Community (z.B. der OSB Alliance) bekommen. Aber dazu müssten alle Seiten die vorgebrachte Kritik ja erstmal ernst nehmen…

So muss man sich doch auch als Linux-Befürworter fragen, wieso es eigentlich erst Ende 2013/Anfang 2014 – also viele Jahre nach dem Beginn des LIMUX-Projektes – zu einer Entscheidung für eine einzuführende Groupware kam (http://www.linux-magazin.de/NEWS/Limux-und-Kolab-Auch-die-Muenchner-Groupware-wird-Open-Source, http://www.heise.de/ix/meldung/Muenchen-entscheidet-sich-fuer-Open-Source-Groupware-Kolab-2123512.html). Und erzähle mir bitte keiner, es ginge an einem modernen Verwaltungsarbeitsplatz unter Linux auch ohne Groupware und ein breites, gegliedertes und technisch abgesichertes Serviceangebot auch für mobile Clients …. Ja, es geht auch ohne. Aber wäre das eine zeitgemäße Lösung?

Eine faire Diskussion muss auch die umgebende Server- und Netzwerk-Infrastruktur einbeziehen

Der LIMUX-Rollout konzentrierte sich – meines beschränkten Wissens nach und sicher aus guten Gründen – auf einen managebaren Client. Aber damit Linux am Arbeitsplatz wirklich angenehm wird, bedarf es sicherlich noch ganz anderer, flankierender und massiver Maßnahmen im Server- und Infrastruktur-Bereich. Den Status solcher Zusatzmaßnahmen bei der Stadt München kennen wir alle nicht – aber man kann und darf sie im Sinne einer fairen und weiterführenden Bewertung einer Linux-Desktop-Einführung und der Kritik daran nicht ausblenden. Genau einen solchen Hinweis hätte ich u.a. vom renommierten Linux-Magazin erwartet.

Wie wichtig eine Betrachtung des Server-Umfeldes und der dort laufenden Services für die in der Kritik stehenden Desktop-Anwendungen ist, offenbarte auch für IT-Laien der vor kurzem aufgetretende Mail-Zwischenfall. Siehe:
http://www.golem.de/news/e-mail-ausfall-in-muenchen-und-wieder-wars-nicht-limux-1412-111129-3.html

Gewiss, man kann nicht alles auf einmal angehen – und Innovation bedarf des wohlabgewogenen Kompromisses. Da hat Herr Kleinert recht. Angebote für mobile Devices bringen zudem enorme Sicherheitsrisiken mit sich. Aber das
LIMUX-Projekt lief und läuft ja nun auch schon viele, ja inzwischen sehr viele Jahre. Und gerade deshalb darf man die aktuelle, späte Kritik betroffener Anwender – und seien es Bürgermeister – nicht vom Tisch wischen. Gerade als Linux-Befürworter! Oder man verpasst endgültig die vorhandenen Chancen für die Zukunft mit Linux an den Arbeitsplätzen einer sich ständig modernisierenden Verwaltung.

Dass hinreichende, solide und userfreundliche Lösungen für Verwaltungsarbeitsplätze unter Linux möglich sind, stelle ich am allerwenigsten in Zweifel. Ob die Kritik am LIMUX-Projekt berechtigt ist und wo ggf. die Ursachen liegen, muss man deshalb im Interesse von Linux und weiteren Desktop-Projekten sehr sorgfältig und unter Einbeziehung von IT-Prozessen, die über den Desktop hinausreichen, analysieren. Danach ist aufzuzeigen, wie man evtl. Defizite innerhalb der sicher hinreichenden Möglichkeiten von Linux systematisch beheben kann. In diesem Sinne waren die kritischen Beiträge der Bürgermeister zu LIMUX eher wertvoll – und keineswegs “außerirdisch”.

Ich bin jedenfalls gespannt auf das Ergebnis der in Auftrag gegebenen Analysen. Herr Kleinert hoffentlich auch ….

Probleme mit OS 13.2-Upgrade, Backup der OS 13.1 Partition, Grub2, UUIDs

Posted on 21. December 2014 by Ralph Mönchmeyer

Manchmal geschehen Dinge, die einen zum Verzweifeln bringen können – obwohl man selbst daran schuld ist und den Wald vor lauter Bäumen nicht mehr sieht.

Ich habe gestern versucht, Opensuse 13.2 von einer DVD auf einem System mit konventiionellem BIOS zu installieren. In der Vergangenheit habe ich das eine oder andere Mal schlechte Erfahrungen mit Opensuse-Upgrades gemacht. Deshalb habe ich ein Backup der gesamten Partition angelegt, die das aktuelle laufende Betriebssystem Opensuse 13.1 beinhaltet. Das sollte jeder tun! Und gerade bei einer versuchsweisen Installation von OS13.2 oder einem versuchsweisen Upgrade von OS13.1 auf OS 13.2 von einer DVD lohnt sich das. Siehe unten. (Hinweis: Hat man systemrelevante Verzeichnisse über mehrere Partitionen verteilt, so ist natürlich jede der Partitionen zu sichern.)

Da ich faul bin, habe ich diesmal das Backup in eine freie Partition desselben Systems kopiert. Das mache ich sonst nicht; es gibt bei uns nicht umsonst einen Backup-Server.

Meine Systempartitionen halte ich meist im Bereich von 80 GByte. Meine Entwicklungssysteme haben eine oder 2 SSDs für solche Partitionen, auf denen es schnell zugehen muss, und zusätzliche langsamere Raid-Systeme mit konventionellen Harddisks mit Partitionen für die sonstige Datenhaltung. Eine der dortigen freien Partitionen habe ich nun für die Kopie der SSD-Betriebssystem-Partition genutzt. Die SSD ist als “/dev/sda” und das Raid-System als “/dev/sdb” zugänglich. Beide GPT partitioniert.

Das Backup habe ich habe ich mit “dd” vorgenommen:

dd if=/dev/sda2 of=/dev/sdb15 bs=4K

Dieser Schritt war von der Hoffnung getragen, dass der OS-Prober von Grub 2 während der Opensuse-Installation die kopierte Partition erkennen und auch dafür einen Boot-Menü-Eintrag anlegen würde. Für alle Fälle sozusagen. Viel zu kurz gedacht, weil ich in der Hektik einen wichtigen Punkt vernachlässigt hatte! Siehe unten. Dieser Artikel mag daher für ähnlich unbedarfte User eine Warnung und hoffentlich auch Hilfe darstellen.

Jedenfalls ging das Opensuse 13.2 Upgrade schief und ich wollte/musste das Backup nach einem Rückschreiben auf die ursprüngliche Partition wieder nutzen – das klappte dann zunächst aus verschiedenen Gründen zunächst nicht wie vorgesehen. Aber der Reihe nach.

Opensuse 13.2 Installer versagt

Naiv versuchte ich, das Upgrade wie zuletzt bei OS 13.1 über den DVD-Installer durchzuführen. Also: Auf dem Eingangsschirm über F2 Sprache und über F3 die Auflösung gewählt. Und dabei schon den ersten Fehler gemacht – nämlich nicht auf den neuen Menüpunkt “Keine KMS” in der Vorauswahl für die gewünschte Biddschirmauflösung geachtet. Was immer “Keine KMS” implizieren soll… Ich habe den Punkt zunächst ignoriert – obwohl ich natürlich “Kernel Mode Setting” assoziierte, mir dazu aber keine weiteren Gedanken machte.

Jedenfalls brachte der Installer nach der Auswahl meiner Standardauflösung von 1920×1200 kaum lesbare Zeichen auf den grafischen Installer-Schirm. OK, Grafikkartenproblem – ich habe in besagtem System eine Nvidia GTX 750 TI. Da spinnt halt der Nouveau-Treiber, denke ich. Da ich den Schirminhalt mit ein wenig Phantasie manchmal gerade noch lesen konnte, versuchte ich einfach weiterzumachen. In der Hoffnung, dass sich nach der Grundinstallation und einer Installation des Nvidia-Treibers alles zum Guten wenden würde.

Jedoch : Die Installation scheiterte letztlich bei der automatischen Konfiguration kurz vor dem Reboot mit gleich zwei roten Fehlermeldungen, die ich allerdings wegen des zu geringen Farbkontrastes nicht entziffern konnte – außer, dass man einen Fehler melden solle. Sehr hilfreich …. Nach dem Reboot-Versuch ging dann gar nichts mehr. Mein altes Grub2-Menü war zwar noch da, aber das “upgegradete” System blieb zu Beginn des
Bootvorgangs stehen – ohne jede Chance, auch nur irgendetwas zu tun (ach, du schöne neue Welt von grub2, systemd und KMS!).

OK, dachte ich, wozu hast du eine Sicherung? Also mit “dd” die kopierte Partition an ihren Ursprungsort zurückgeschrieben – und leider wieder nicht darüber nachgedacht, was das eigentlich bedeutet (s.u.). Immerhin: Der Bootvorgang ins alte OS13.1 lief (irgendwie, s.u.). Bis zum grafischen Login. Da war ich erstmal beruhigt.

Weiterer Installationsversuch

Ich habe danach versucht – wieder mit kaum lesbarem Schirm – eine minimale Installation von OS 13.2 ohne KDE oder ein anderes grafisches System vorzunehmen. Ich modifzierte ferner die Partitionierung nach einem bislang gewohntem Muster – wiederum ohne richtig nachzudenken. Und eliminierte dabei eine BIOS Boot Partitiion, die ich unter OS 13.1 auch nicht hatte. Die Quittung kam prompt:
Nach dem Reboot meldete das BIOS, dass es kein bootfähiges System gebe. Ich solle eine Systemdisk einstecken … Na, super ! Nun half die zurückgespielte Sicherung auch nichts mehr …

“Keine KMS” unter dem Installerpunkt F3 Auflösung”

Nach einem Beruhigungstrunk war dann der Ehrgeiz geweckt. Neuer Anlauf mit genauerem Hinsehen und Hin und Her-Schalten zwischen den Spracheinstellungen des grafischen Opensuse DVD-Installers. Das erste, was ich dann ernst nahm, war der neue Punkt (nach “F3”) oberhalb der verfügbaren Auflösungen: “No KMS” – “Keine KMS”.

Unabhängig von “keine” ist “KMS”, interpretiert als “Kernel Mode Setting”, durchaus interessant. Die proprietären NVidia Treiber nutzen ja KMS nicht. Aber die Idee hinter KMS ist ja eigentlich was Gutes. Siehe etwa:
https://wiki.archlinux.org/index.php/kernel_mode_setting
Vielleicht nutzt der OS-Installer jetzt frühzeitig KMS ? Und vielleicht kann ja der Installer im KMS Modus mit aktuellen Nvidia Karten nicht umgehen?

Also mal die Option “Keine KMS” gewählt. Und siehe da: Es wurde zwar für Textmeldungen auf tty1 ein Text-Terminal mit schrecklicher 80×20-Basis-Auflösung eingerichtet, aber der grafische Installer funktionierte plötzlich mit meiner Nvidia-Karte und zeigte ein einwandfreies grafisches Schirm- und Text-Bild. Das ist etwas, worüber die Opensuse-Leute mal nachdenken sollten! Wie soll ein Anfänger mit dieser Situation klar kommen?

Installation von Opensuse 13.2 mit dem Kernelparamter “nomodeset”

Ok; KMS macht dem Installer also Probleme beim Umgang mit meiner speziellen Nvidia-Karte (oder ggf. auch mit anderen Nvidia-Karten). Da ich mich nach der Installation nicht mit niedrig auflösenden Text-Konsolen (tty1 bis tty6) und deren Rekonfiguration rumschlagen will, habe ich mir dann für einen erneuten Installation vorgenommen, zwar eine Auflösung von “1920×1200” statt der Option “Keine KMS” zu wählen, aber gleichzeitig mit dem Kernel-Parameter

“nomodeset”

zu arbeiten. Gott sei Dank hat Opensuse die Eingabezeile für Kernelparameter auf dem Installer-Schirm beibehalten!

Der Vorteil dieser Installationsmethode ist, dass einerseits das Problem mit dem grafischen Installer vermieden wird – aber gleichzeitig die Konsol-Terminals tty1 bis tty6 auf maximale Auflösung konfiguriert werden.

Partitionierung mit BIOS Boot Partition

Mein System war eines mit einem konventionellen BIOS. Kein UEFI. Grub 2 in aktuellen Versionen benötigt aber aus Platzgründen (begrenzter MBR; angrenzender Platz wird belegt) eine kleine Bios Boot Partition, wenn

ein System mit
konventionellem BIOS gebootet werden soll UND
die Festplatte, auf der Grub2 installiert wird, eine reine GPT-Partitionstabelle enthält oder ein MBR/GPT Hybrid ist.

Für mehr Informationen zur BIOS Boot Partition siehe

http://en.wikipedia.org/wiki/BIOS_boot_partition
http://wiki.ubuntuusers.de/GRUB_2/Grundlagen
http://www.rodsbooks.com/gdisk/booting.html
http://de.news.siduction.org/2011/10/15/gpt-disks-mit-herkommlichem-bios-booten/

Für mein System mit konventionellem BIOS und GPT-Platten schlug der Opensuse Installer deshalb eine solche Partition im Zuge der versuchten Neuinstallation vor. Ist man bislang ohne eine solche Partition ausgekommen, so war das vielleicht Glück (Grub2 kann manchmal mit Umwegen arbeiten), oder man hatte noch eine älter Grub 2 Version. In jedem Fall sollte man vor der Neu-Installation von OS 13.2 auf eine freien Partition, aber auch vor dem Upgrade eines vorhandenen OS 13.1 unbedingt eine kleine “BIOS BOOT” Partition anlegen, wenn denn die primäre Platte GPT-partitioniert ist und dort eine solche Partition noch nicht existiert.

Diese “BIOS BOOT”-Partition wird vom User zwar nicht formatiert, erhält aber ein spezielles Flag. Der Partitioner von Opensuse, der im Installer aufgerufen wird, stellt dann die Größe automatisch auf etwa 7.3 MByte ein. Man darf alles an den Partitionierungsvorschlägen des Installers ändern, aber die Existenz der Boot Partition sollte man gewährleisten. Im YaST-Partitioner muss man beim Anlegen der Partition folgende Optionen wählen :

Partition nicht formatieren
Dateisystem ID 0x00 BIOS Grub

Der Typ einer solchen Partition ist übrigens “0xEF02” (falls man Tools wie “gdisk” zur Anlage verwenden will).

Erfolgreiche Installation

Und – oh Wunder – mit dem Kernelparameter “nomodeset” und vorhandener BIOS Boot Partition klappte sowohl die Installation eines neuen Systems auf einer freien Partition (als auch das spätere Upgrade eines vorhandenen OS 13.1). Das vom Installer installierte Grub 2 enthielt nach der testweisen Neuinstallation von OS 13.2 auf einer freien Partition der SSD prompt auch 2 Menüpunkte für

sowohl das alte ursprüngliche OS 13.1 auf der SSD (/dev/sda1)
wie auch das als Backup kopierte OS 13.1 auf dem Raid-System (/dev/sdb15)

Grub2 bootet trotz korrektem Menüeintrag das vorhandene OS13.1 nicht von “/dev/sda1” sondern von “/dev/sdb15”

Nun probierte ich, das inzwischen ja aus der Sicherung auf “/dev/sda1” zurückkopierte OS 13.1-System zu booten. Das ging zwar – es wurde aber nicht die Partition /dev/sda1 auf das Wurzelverzeichnis “/” gemounted, sondern vielmehr die (langsamere) “/dev/sdb15”.

Warum denn das nun wieder? Der zugehörige Grub2-Menüeintrag sah doch korrekt aus und enthielt sogar den Hinweis auf die “/dev/sda1” im Titel! Auch die Einstellung der “/boot/grub2/grub.cfg” sahen fehlerfrei aus. Ich hatte einfach einen schlechten Tag und bekam das trotz einiger Anläufe und mehrfacher Kontrolle der Grub2 Konfigurationsdatei und der “/etc/fstab” zunächst nicht in den Griff. Dabei war die Lösung bei etwas aufmerksamerem Hinsehen stocksimpel – und dem Profi ist mein oben begangener Fehler sicher nicht entgangen:

“dd” kopiert natürlich 1:1 die komplette Filesystem-Information zwischen den Partitionen mit. Damit auch die
UUID der Partition! Diese war nach dem Kopieren also nicht mehr eindeutig in meinem System!

Siehe zur Bedeutung der UUID z.B.:
http://wiki.ubuntuusers.de/UUID

Grub 2 benutzt in der aktuellen Version aber UUIDs an etlichen Stellen, um die zu einem Menüeintrag zugehörigen Partitionen zu identifizieren. Hierzu ein entsprechender Ausschnitt aus der “/boot/grub2/grub.cfg” :

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'openSUSE 13.1 (x86_64) (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-d05ea945-8416-45bb-8697-2710a753520e' {
	insmod part_gpt 
	insmod ext2
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  d05ea945-8416-45bb-8697-2710a753520e
	else
	  search --no-floppy --fs-uuid --set=root d05ea945-8416-45bb-8697-2710a753520e
	fi
	linux /boot/vmlinuz-3.11.10-7-desktop root=UUID=d05ea945-8416-45bb-8697-2710a753520e video=1920x1200 resume=/dev/disk/by-id/scsi-1AMCC_1ZC032077E68A3005C91-part5 splash=silent quiet showopts
	initrd /boot/initrd-3.11.10-7-desktop
}

Der wichtigste Punkt ist dabei

root=UUID=d05ea945-8416-45bb-8697-2710a753520e

Leider gab es auch nach dem Zurückkopieren des Inhalts der (Backup-)-Partition von “/dev/sdb15” auf “/dev/sda1” die UUID “d05ea945-8416-45bb-8697-2710a753520e” natürlich zweimal auf dem System – eben für “/dev/sdb15” und “/dev/sda1”.

Überprüfen kann man die UUID als User root mittels des Kommandos

mytux:~ # blkid /dev/sda1
/dev/sda1: UUID="d05ea945-8416-45bb-8697-2710a753520e" TYPE="ext4" PTTYPE="dos" PARTLABEL="primary" PARTUUID="5db53bbc-3db1-4860-8c67-6d9d8391ef29" 
mytux:~ # blkid /dev/sdb15
/dev/sdb15: UUID="d05ea945-8416-45bb-8697-2710a753520e" TYPE="ext4" PTTYPE="dos" PARTUUID="000616c5-0f" 
mytux:~ #

Siehe zum “blkid”-Befehl http://wiki.ubuntuusers.de/UUID und die man-Seiten.

Das dargestellte Ergebnis führte in meinem Fall natürlich ins Chaos.

Was also tun? Man muss in der von mir herbeigeführten Situation die UUID des Filesystems auf der kopierten Partition “dev/sdb15” ändern! Danach muss man den OS-Prober von Grub2 erneut laufen lassen und Grub2 neu installieren.

Zum Umsetzen der UUID von “/dev/sdb15” darf diese Partition nicht gemounted sein. Ist sie wie in meinem Fall mit “ext4” formatiert, ändert man die UUID (nach dem Unmounten) mit “tune2fs”:

mytux:~ # tune2fs -U `uuidgen` /dev/sdb15      
mytux:~ # blkid /dev/sdb15
/dev/sdb15: UUID="1dffa36e-b8ba-484b-81aa-577fe4c600c6" TYPE="ext4" PTTYPE="dos" PARTUUID="000616c5-0f"

Ok. Im Anschluss die üblichen Schritte für die Konfiguration und Installation von “grub2” durchführen:

mytux:~ # grub2-mkconfig -o /boot/grub2/grub.cfg
mytux:~ # grub2-install --boot-directory=/boot /dev/sda

Siehe für Hintergrundsinformationen
https://activedoc.opensuse.org/book/opensuse-reference/chapter-10-the-boot-loader-grub2

https://fedoraproject.org/wiki/GRUB_2?rd=Grub2
http://www.dedoimedo.com/computers/grub-2.html
http://wiki.gentoo.org/wiki/GRUB2_Quick_Start

Die, die es sich einfacher
machen wollen, verwenden im aktuell gebooteten Opensuse-System (in meinem Fall also in dem eben neu installierten OS13.2) “Yast2 >> Bootloader”. Ich gehe hier nicht näher auf die von Opensuse gewählten Einstellungen zum Grub2-Bootloader ein. Wichtig ist, dass unter dem Reiter “Bootloader-Optionen” die Checkbox “Fremdes OS testen” einen Haken hat.

Danach wurde OS 13.1 sowohl von seiner ursprüglichen Partition “/dev/sda1/” als auch vom backup “dev/sdb15” scheinbar korrekt und mit konsistenten Einstellungen gebootet.

Stimmt das ? Nein, nicht wirklich. Denn wenn man sich die “/etc/fstab” der Kopie auf “/dev/sdb15” ansieht, steht da ja immer noch die ursprüngliche Partition der SSD als Boot-Partition drin :

/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAF109572J-part1 /	ext4  acl,user_xattr  1 1

Erstaunlicherweise funktioniert der Boot-Vorgang von der backup-Partition trotzdem und es ist danach gemäß der Grub2-Konfiguration auch wirklich “/dev/sdb15” auf “/” gemounted (man prüfe das mit “mount”). Den Eintrag in “/etc/fstab” müsste man natürlich noch ändern, falls man das “Backup” wirklich zum Arbeiten nutzen wollte und dafür eine konsistente Konfiguration haben möchte. Aber eigentlich ist das Arbeiten mit der Sicherungskopie nicht Sinn der Sache – das Backup soll ja eigentlich unangetastet bleiben. Ok, im vorliegenden Fall diente der Versuch der Vermehrung von Wissen …

Nachdem die Welt nun wieder in Ordnung und das Wissen um die Tücken des OS13.2-Installers hinreichend vermehrt war, konnte ich nun endlich auch ein erfolgreiches Upgrade des vorhandenen OS 13.1 auf “/dev/sda1” fahren!

Was haben wir durch die Upgrade- und Installationsversuche zu Opensuse OS 13.2 gelernt ?

Bzgl. Grub 2:

Behalte immer im Kopf, dass Grub2 UUIDs heranzieht, um Partitionen zu identifizieren. Überlege dir auf dieser Basis deine Backup- und Restaurierungs-Strategie bzgl. aller Konsequenzen (unter Vermeidung der Erzeugung doppelter UUIDs im gleichen System).
Lege Backups einer Partition, die du mit “dd” erzeugst, deshalb am besten nicht auf ein und demselben System an! Wenn doch ändere ggf. die UUID des Backup-Filesystems und merke dir die alte UUID für evtl. Restaurierungsarbeiten.
Bist du nach Neuinstallationen oder anderen Systemexperimenten gezwungen, das (mit “dd” erzeugte) Backup (evtl. ohne geänderte UUID) zurückzukopieren, dann ändere spätestens vor diesem Schritt die UUID der Backup-Partition. Und kümmere dich darum, dass die zurückgeholte Partition eine UUID erhält, die mit den aktuellen Grub2-Einstellungen kompatibel ist – oder lege mit Hilfe eines anderen, noch bootfähigen Systems Grub2 nach dem Rückkopieren komplett neu an (inkl. Durchlaufen des OS-Probers!).
Bei Booten eines Systems mit konventionellem BIOS : Unbedingt vorab oder während der Installation eine (kleine) unformatierte Partition vom Typ “BIOS GRUB” anlegen, wenn man eine reine GPT-partitionierte Festplatte oder eine MBR/GPT-Hybrid-Platte besitzt. Im Falle von (U)EFI ist sowieso eine EFI-Partition anzulegen.

Bzgl. der Opensuse 13.2 Installation von der DVD:

Unbedingt das alte System sichern.
Der grafische “Opensuse 13.2”-Installer kann Probleme mit Nvidia-Karten bekommen (grafisches Schirmbild mit fast unleserlichem Text, verwaschenem Kontrast und fehlerhafter Glättung). Er hat mit Sicherheit Probleme mit einer GTX 750 TI. Dann bei der Installation mal als Kernelparameter “nomodeset” eingeben oder unter F3 die Option “Keine KMS” wählen.
Ein Upgrade mit aktivem KMS führte bei mir (Nvidia-Karte, Opensuse 13.1) zum Scheitern der Installation im Verlauf der automatischen Konfiguration (der Systemgeräte) kurz vor dem Reboot.

Viel Spass nun bei euren eigenen Experimenten mit einem Opensuse 13.2 Upgrade oder einer OS 13.2 Installation!

Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1

Posted on 17. December 2014 by Ralph Mönchmeyer

Im letzten Artikel dieser kleinen Serie zur Asus Sonar D2X
Asus Xonar D2X unter Linux / Opensuse 13.1 – II
hatte ich festgestellt,

dass Soundsignale neben der Digital-Analog Umwandlung nicht modifiziert werden und vom User nur hinsichtlich der Kanal-Lautstärke direkt beeinflusst werden können,
dass die Karte deshalb nur in Grenzen regelbar ist. So fehlen Möglichkeiten zur systemweiten Bass/Höhen-Regelung und die Varianten eines Stereo-Upmix auf mehr als 2 Kanäle sind begrenzt. So kann man über einen entsprechende Schalter nur auf 4.0 oder 6.0 Sound hochmixen. Ein Upmix auf 5.1 oder 7.1 Sound ist jedoch nicht direkt möglich.
dass ein Regler zur globalen Lautstärkeregelung, der das Lautstärkeverhältnis der Kanäle zueinander nicht verändert, fehlt.

Hinsichtlich der Klangeigenschaften und der Bass/Höhen-Verteilung müssen unter KDE player-spezifische “Equalizer” helfen, wie sie z.B. Clementine und Amarok zur Verfügung stellen (zumindest bei Einsatz des Gstreamer-Backends für Phonon).

Bzgl. eines weitergehenden Stereo-Upmixes und des fehlenden Reglers müssen wir auf die sehr weitgehenden Konfigurationsmöglichkeiten von ALSA zurückgreifen. Dazu brauchen wir kein Pulse-Audio! ALSA erlaubt dabei eine userspezifische Einstellung über eine Datei “~/.asoundrc“.

Upmix von 2.0-Stereo-Sound auf 5.1-Kanal-Sound (oder 7.1-Kanal-Sound) mittels ALSA und einer “~/.asoundrc”-Datei

Ich definiere und erläutere nachfolgend der Reihe nach die erforderlichen Abschnitte einer Datei “~/.asoundrc“, die unsere D2X-Karte dazu bringt, z.B. zusammen mit den Playern Clementine und Amarok unter KDE folgendes zu tun:

Ergänzung von Kmix um einen Regler zur Lautstärkenänderung über alle Kanäle hinweg, wobei das Lautstärekverhältnis zwischen den Kanälen gleich bleibt.
Upmix des Outputs von Stereo-Audio-Quellen zu einem 5.1 (bzw. 7.1) Sound.

Ich zeige dabei zunächst nur eine simple, aber wirkungsvolle Methode, die das generische ALSA Device “surround 5.1” und die Asus Sonar D2X als 6 Kanal-Gerät benutzt. Das ist für Leute interessant, die nur 5.1 Lautsprecher-Sets zur Verfügung haben. Aus dem unten Ausgeführten ergibt sich der 7.1-Fall (mittels “surround71”) jedoch ganz zwanglos.

Wer bzgl. ALSA und der “~/.asoundrc”-Datei kein Hintergrundswissen mitbringt, dem seien folgende Artikel empfohlen:
http://www.volkerschatz.com/noise/alsa.html
http://www.alsa-project.org/main/index.php/Asoundrc

Dort findet man einige grundsätzliche Erläuterungen. Für Entwickler erschließen sich danach ein paar Begrifflichkeiten ggf. auch über
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html

Identifiziere die richtige Nummer der Soundkarte

Bevor wir die Datei “~/.asoundr” editieren, benötigen wir ein paar Informationen zu den vom System und ALSA erkannten Soundkarten. Hat man nämlich mehrere Soundkarten installiert, so ist die Nummer der Karte für die weitere ALSA-Konfiguration entscheidend.

Diesbezügliche Informationen erhalten wir z.B. YaST. Auf ALSA-Ebene geht dies direkter mit Hilfe des Kommandos “aplay -l“. (Hinweis: Das Paket “alsatools” sollte auf dem System installiert sein). Bei mir sieht das Ergebnis dieses Kommandos im Moment so aus:

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Audigy2 [SB Audigy 2 
Platinum [SB0240P]], Gerät 0: emu10k1 [ADC Capture/Standard PCM Playback]
  Sub-Geräte: 32/32
  Sub-Gerät #0: subdevice #0
  Sub-Gerät #1: subdevice #1
  Sub-Gerät #2: subdevice #2
  Sub-Gerät #3: subdevice #3
  Sub-Gerät #4: subdevice #4
  Sub-Gerät #5: subdevice #5
  Sub-Gerät #6: subdevice #6
  Sub-Gerät #7: subdevice #7
  Sub-Gerät #8: subdevice #8
  Sub-Gerät #9: subdevice #9
  Sub-Gerät #10: subdevice #10
  Sub-Gerät #11: subdevice #11
  Sub-Gerät #12: subdevice #12
  Sub-Gerät #13: subdevice #13
  Sub-Gerät #14: subdevice #14
  Sub-Gerät #15: subdevice #15
  Sub-Gerät #16: subdevice #16
  Sub-Gerät #17: subdevice #17
  Sub-Gerät #18: subdevice #18
  Sub-Gerät #19: subdevice #19
  Sub-Gerät #20: subdevice #20
  Sub-Gerät #21: subdevice #21
  Sub-Gerät #22: subdevice #22
  Sub-Gerät #23: subdevice #23
  Sub-Gerät #24: subdevice #24
  Sub-Gerät #25: subdevice #25
  Sub-Gerät #26: subdevice #26
  Sub-Gerät #27: subdevice #27
  Sub-Gerät #28: subdevice #28
  Sub-Gerät #29: subdevice #29
  Sub-Gerät #30: subdevice #30
  Sub-Gerät #31: subdevice #31
Karte 0: Audigy2 [SB Audigy 2 Platinum [SB0240P]], Gerät 2: emu10k1 efx [Multichannel Capture/PT Playback]
  Sub-Geräte: 8/8
  Sub-Gerät #0: subdevice #0
  Sub-Gerät #1: subdevice #1
  Sub-Gerät #2: subdevice #2
  Sub-Gerät #3: subdevice #3
  Sub-Gerät #4: subdevice #4
  Sub-Gerät #5: subdevice #5
  Sub-Gerät #6: subdevice #6
  Sub-Gerät #7: subdevice #7
Karte 0: Audigy2 [SB Audigy 2 Platinum [SB0240P]], Gerät 3: emu10k1 [Multichannel Playback]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: Audigy2 [SB Audigy 2 Platinum [SB0240P]], Gerät 4: p16v [p16v]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: D2X [Xonar D2X], Gerät 0: Multichannel [Multichannel]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 1: D2X [Xonar D2X], Gerät 1: Digital [Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: NVidia [HDA NVidia], Gerät 9: HDMI 3 [HDMI 3]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Hier sieht man, dass die D2X als Karte 1 erkannt wurde. Weitere Geräte sind eine alte, liebgewonnene Audigy 2 und eine Onboard-Karte. Man erkennt ferner, dass jede Karte (im Besonderen abwer die Audigy-Karte) eine Reihe untergeordneter Geräte mit weiteren “Sub Devices” beherbergen. Die D2X erscheint mit ihren 2 “Geräten” unter Linux eher als eine sehr schlanke Karte.

Auf einem System mit genau nur einer Soundkarte wäre die Soundkarten-Nummer im Gegensatz zum obigen Befund “0” gewesen.

Weitere Kommandos, die die Reihenfolge der Karten unter einem Linux-System und zugehörige Module anzeigen, sind:

cat /proc/asound/cards

mytux:~ # cat /proc/asound/cards
 0 [D2X            ]: AV200 - Xonar D2X
                      Asus Virtuoso 200 at 0x7e00, irq 16
 1 [Audigy2        ]: Audigy2 - SB Audigy 2 Platinum [SB0240P]
                      SB Audigy 2 Platinum [SB0240P] (rev.4, serial:0x10021102) at 0x8f00, irq 16
 2 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xfaffc000 irq 17

cat /proc/asound/modules

mytux:~ # cat /proc/asound/modules
 0 snd_virtuoso
 1 snd_emu10k1
 2 snd_hda_intel

An letzterer Ausgabe erkennt man übrigens auch, dass das für die Asus Xonar D2X geladene Kernelmodul den Namen “snd_virtuoso” trägt. Dieser Befund ist natürlich
konsistent zu der von uns in
Asus Xonar D2X unter Linux / Opensuse 13.1 – II
per YaST vorgenommenen Sound-Karten-Konfiguration.

Bei Bedarf die Reihenfolge der Soundkarten ändern

Dass die eigentlich bevorzugte Xonar D2X-Karte in meinem System nicht als Karte “0” definiert ist, mag dem einen oder anderen Leser suspekt vorkommen. Nicht ganz zu Unrecht:

Bei dem heutigen Mischmasch aus Phonon, einer definierten Reihenfolge aus Phonon-Devices, diversen Phonon-Backends, Resten von Pulse-Audio und ALSA kann die eine oder andere KDE- oder Gnome-Applikation von sich aus schon mal als Default die Karte “0” (oder untergeordnete Geräte) ansprechen; dann müssen da natürlich auch Lautsprecher angeschlossen sein, damit man überhaupt was zu hören bekommt.

Hinzu kommt ein seltsamer Mix aus erkannten reinen ALSA-Devices (mit kleinem ALSA-Logo) und Phonon/KDE-Devices (versehen mit einem kleinen KDE-Logo) in den KDE-weiten “Multimedia (= Phonon)-Einstellungen (s. die Abbildung weiter unten). Auch wenn man die Reihenfolge der bevorzugten Devices dort so definiert, das die ALSA-Devices ganz oben stehen, wird das nicht zwingend von jeder Applikation beachtet. Manche Applikationen erlauben zudem eine spezifische eigene Auswahl des Sound-Gerätes. Wer nicht an jeder Soundkarte Lautsprecher angeschlossen hat und auf Probleme mit Applikationen stößt, der möge die D2X zur Sicherheit also als Karte “0” definieren und die weiter unten folgenden HW-Angaben in der “~/.asoundrc” entsprechend anpassen.

Leicht gesagt – aber wie ändert man eigentlich die Reihenfolge der erkannten Soundkarten im System?

Unter Opensuse kann die Reihenfolge der Karten am einfachsten mit “YaST >> Sound” beeinflusst werden. Unter anderen Systemen ist es u.U. etwas schwieriger. Letztlich läuft die Sache auf Einstellungen in einer sound-spezifischen Datei unter dem Verzeichnis “/etc/modprobe.d/” hinaus. Übersichtliche Hinweise zu Ubuntu findet man hier:
http://wiki.ubuntuusers.de/Soundkarten_konfigurieren
Siehe dort den Abschnitt “Reihenfolge (Priorität) von Soundkarten Ändern”. Die dort beschriebenen Einstellungen gelten vermutlich auch für andere Debian-basierte Systeme; sie verdeutlichen in jedem Fall das Prinzip.

Unter Opensuse 13.1 heißt die zu modifizierende Datei dagegen “/etc/modprobe.d/50-sound.conf”. Sie sieht in meinem Fall so aus:

options snd slots=snd-emu10k1,snd-virtuoso
# Cw4d.j3r564qQSgF:Virtuoso 200 (Xonar D2X)
alias snd-card-1 snd-virtuoso
# cuhJ.vIcU+IM+7DC:SB Audigy2 Platinum
alias snd-card-0 snd-emu10k1

Für eine Reihenfolge, bei der die D2X an erster Stelle kommt, müsste der Inhalt wie folgt abgeändert werden:

options snd slots=snd-virtuoso,snd-emu10k1
# cuhJ.vIcU+IM+7DC:SB Audigy2 Platinum
alias snd-card-1 snd-emu10k1
# Cw4d.j3r564qQSgF:Virtuoso 200 (Xonar D2X)
alias snd-card-0 snd-virtuoso

Nach einem Reboot ist dann die in dieser Datei definierte Reihenfolge gültig. Nebenbei: Die seltsamen Buchstaben-Zahlen-Kombinationen für die Karten stammen aus “udev” und dort hinterlegten Infos.

Beziehung der Soundkarten-Nummer zu ALSA-Definitionen

Wie die Nummer der Karte und ihrer Subdevices in ALSA-Kennungen eingehen, die in einer “.asoundrc” verwendet werden können, erfährt man hier
http://www.alsa-project.org/main/index.php/Asoundrc
In diesem Artikel kann man auch nachlesen, was sog. “Plugin” PCM Devices sind. Derartige PCM Devices (vom Type “plug”) werden wir weiter unten in einer hierarchischen Abfolge definieren und miteinander kombinieren. Vereinfacht gilt:

PCM Devices (bestimmter verschiedener Typen, u.a. “plug”) können sich unter ALSA jeweils ein sogenanntes “Slave Device” zunutze machen und den Sound an dieses Device gemäß vorgegebener Einstellungen weiterleiten. Das Ganze kann über mehrere Ebenen hinweg erfolgen.

Definition eines Full Duplex Devices als Ziel des Upmixes

Wir beginnen nun mit dem Editieren der Datei ~/.asoundrc. In einem ersten Abschnitt legen wir ein Full Duplex Device (Plugin) namens “dmix51” fest, das wir mit unser Hardware verknüpfen. Zu “Full Duplex” siehe z.B.:
http://www.ehow.com/how_7763496_check-sound-card-fullduplex.html.

Der Typ (= “type”), den man bei der Konfiguration eines solchen Full-Duplex-Devices angeben muss, ist “asym”. Siehe http://alsa.opensrc.org/Asym. Plugins vom Typ “asym” bestehen aus zwei Komponenten, die definiert werden müssen – einer “playback”– und einer “capture”-Komponente. Am wichtigsten für unsere Zwecke ist im Moment die “playback”-Komponente. Zu dieser legen wir diverse Eigenschaften fest, während wir bei der “capture”-Komponente lediglich auf die vorhandene Hardware verweisen.

Das “playback”-Plugin ist wiederum vom Typ “dmix”. Siehe hierzu:
http://alsa.opensrc.org/Dmix.
Wichtig ist, dass ALSA für solche definierten Devices mehrere Soundstreams aus unterschiedlichen Quellen direkt miteinander mixen, also störungsfrei überlagern kann. Dafür braucht man Pulseaudio überhaupt nicht. So ist es dann z.B. möglich, parallel Sound von Clementine und von Amarok oder anderen Quellen abspielen zu lassen. Unter Kmix lassen sich diese Quellen dann zudem gegeneinander von der Lautstärke her abmischen.

Sog. “ipc”-Daten regeln die Zugriffsmöglichkeiten. Siehe hierzu: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html und dort den Abschnitt zu “dmix”.

pcm.dmix51 {
	type asym
	
	playback.pcm {
		type dmix

		ipc_key 6789123
		ipc_perm 0660
		ipc_gid audio

		slave {
			# 6 channels entsprechen surround51, 8 surround71
			channels 6
			pcm {
				#format S32_LE
				format S16_LE
				
				#rate 44100
				rate 48000

				type hw
				card 1
				device 0
				subdevice 0
			}

			period_size 1024
			buffer_size 16384
		}
	}
	capture.pcm "hw:1"
}
ctl.dmix51 {
	type hw
	card 1
}

Der Name “dmix51” ist willkürlich gewählt und deutet an, dass wir hier 6 Kanäle voraussetzen und nutzen wollen. Festgelegt wird Letzteres über das “channels”-Statement im inkludierten “slave” :

channels 6

Schließt man eine 7.1-Anlage an die Xonar D2X an, so nutzt man natürlich ein analog definiertes Device “dmix71” mit “channels 8”. Eine Darstellung des länglichen Codes für ein “dmix71” hierfür habe ich mir aus Platz- und Wiederholungsgründen erspart.

Innerhalb der “playback”-Komponente wird ein Slave PCM Device vom Typ “hw” (Hardware) definiert. Bzgl. der angegebenen Alternativen zu den Sampling-Parametern für die gemixten Streams und auch zum Buffering muss man ein wenig experimentieren – u.a. um stockenden Sound oder “Crackling” zu vermeiden. Siehe etwa die Kommentare in einer analogen Definition in

https://dl.dropboxusercontent.com/u/18371907/asoundrc.

Die Definition des Control Devices “ctl.dmix51” am Ende haben wir zur Sicherheit vorgenommen. Programme wie “Jack” benötigen diese Festlegung gegebenenfalls.

Ok,
nun haben wir ein “dmix”-PCM Device, das auf unsere Karte verweist und das in der Lage ist, eingehende Streams aus unterschiedlichen Quellen zu einem Stream zu resamplen.

Kette aus Default und Slave-Devices in der “~/.asoundrc”

Applikationen wie Clementine nutzen ohne weitere detaillierte Konfiguration ein ALSA Default Device. Amarok wertet zudem die KDE-Einstellungen zum Phonon Standard Device aus. Das von uns nun vorgegebene ALSA Default Device sollte nach Abwickeln einer Kette von hierarchischen Slave Device Definitionen letztich zu dem vorgesehenen HW-Device führen. Dies erreichen wir nachfolgend, indem wir die Slave-Kette am Ende zu unserem bereits definierten “dmix51” PCM Device führen.

pcm.!default {
	type softvol
	slave.pcm "simple51"
# 	slave.pcm "simple71"
#	slave.pcm "ctrl51"

	control {
	  name "SW master"
	  card 1
	 }
	 
   hint {
    show on
    description "ALSA_DEFAULT"
  }
}

# speaker-test -D simple51 -c 2 -t wav
pcm.simple51 {
	type plug
	slave.pcm "surround51"
	slave.channels 6
	route_policy duplicate
}
pcm.simple71 {
	type plug
	slave.pcm "surround71"
	slave.channels 8
	route_policy duplicate
}
pcm.!surround20 {
	type plug
	slave.pcm "dmix51"
	# slave.pcm "dmix71"
}

pcm.!surround40 {
	type plug
	slave.pcm "dmix51"
	# slave.pcm "dmix71"
}

pcm.!surround51 {
	type plug
	slave.pcm "dmix51"
	# slave.pcm "dmix71"
}

pcm.!surround71 {
	type plug
	slave.pcm "dmix71"
}

# speaker-test -D ctrl51 -c 2 -t wav
pcm.ctrl51 {
	type plug
	slave.pcm "surround51"
	slave.channels 6
	type route
    ttable.0.0 1
    ttable.1.1 1
    ttable.0.2 1
    ttable.1.3 1
    ttable.0.4 0.5
    ttable.1.4 0.5	
    ttable.0.5 0.5
    ttable.1.5 0.5	
}

pcm.wine {
	type plug
	# Output directly, for performance
	#slave.pcm "hw:0"
	slave.pcm "surround20"
}

Hinweis: “#” leitet einen Kommentar ein.

Was passiert hier ? Zunächst gilt:

“surround51” ist eines der generischen ALSA Devices – siehe http://alsa.opensrc.org/SurroundSound.
Das Ausrufezeichen vor den PCM Plugin-Namen leitet eine neue Device Definition mit (ggf.) Parameterüberschreibung ein. Siehe http://www.volkerschatz.com/noise/alsa.html und dort den Abschnitt über “Advanced configuration file features”.

Mit diesem Wissen ausgestattet, besprechen wir nun einzelne Abschnitte.

Definition des Default Devices als “softvol” Device mit kanalübergreifendem Lautstärkeregler

Wir definieren im ersten Block also das PCM Standard (=Default) Device “pcm.!default” neu und zwar so, dass es offenbar vom Typ “softvol” sein soll. Letzteres bedeutet, dass ein “volume”-Regler (also Lautstärkeregler) auf SW-Basis eingeführt und einer HW-Einheit zugeordnet wird. Siehe hierzu: http://alsa.opensrc.org/Softvol.

Der über “control” für unsere Soundkarte 1 definierte Regler steht dann z.B. in Mixer-GUIs wie “kmix” oder “alsamix” als verwendbarer Regler zur Verfügung. Warum wollen wir einen solchen Regler? Weil die Kanal-Splittung des Standard-Master-Reglers der D2X alle Kanäle auf das gleiche Volumen hebt, sobald er betätigt wird. Wir möchten aber einen (zusätzlichen) Regler, der nach einem Split des Master auf einzelnen Kanäle das relative Lautstärkeverhältnis der Kanäle zueinander aufrecht erhält. Genau dies wird der von uns definierte Regler leisten. Wir haben ihn deshalb als “SW Master” bezeichnet.

Unser “pcm.!default”-
Device bindet aber auch ein Slave Device vom Typ “plug” ein, nämlich “pcm.simple51”, dessen Eigenschaften wir in einem weiteren, entsprechenden Abschnitt definiert haben. Will man eine 7.1-Konfiguration, so ist die Zeile

slave.pcm “simple51”

auszukommentieren und durch die im Moment kommentierte Zeile mit

slave.pcm “simple71”

zu ersetzen.

Upmix über ein zwischengeschobenes Plugin, das Stereo-Eingangskanäle nach Upmix an das generische Device “surround51” bzw. “surround71” weiterleitet

Das PCM Device “simple51” benutzt als Slave das (redefinierte) “Surround51”-Plugin und gibt dafür vor,

dass 6 Kanäle benutzt werden sollen und
dass eine Kanal-Duplikation vorgenommen werden soll.

Letzteres drückt sich in dem “route_policy”-Statement aus:

route_policy duplicate

Hinweise zur Bedeutung des Parameters “route_policy” und den verschiedenen dafür vergebbaren Werten findet man in http://alsa.opensrc.org/Asoundrc (Abschnitt “Plugins”).

Die Einstellung “duplicate” führt zu einer automatischen Generierung von sog. “ttable”-Einstellungen, die den Upmix der ersten beiden Kanäle auf alle folgenden in einer einfachen, vordefinierten Lautstärkebalance vornehmen.

“ttable”-Vorgaben legen fest, welcher vorhandene Kanal durch ALSA in welcher Form (z.B. mit welcher Lautstärke) auf einen anderen Kanal abgebildet werden soll. Wie man die “ttable”-Einstellungen in der “~/.asoundrc” bei Bedarf explizit ändern kann, beschreibe ich kurz weiter unten. Zwingend ist eine eigene “ttable”-Abmischung über die “.asoundrc” aber nicht erforderlich, da wir ja zum relativen Lautstärke-Mix der D2X-Kanäle auch unsere Regler unter Kmix (oder einer anderen Mixer-GUI) zur Verfügung haben.

Im 7.1 Fall hätte unser “pcm.!default” in natürlich analoger Weise auf das angegebene “pcm.simple71” verwiesen und Letzteres wiederum auf das ebenfalls angegebene “pcm.!surround71”.

Redefinition des generischen “surround51”- bzw. “surround71” Devices

Wohin verweist dann das redefinierte “surround51”-Plugin? Natürlich auf unser “dmix51” Device, das an unsere Soundkarte gebunden wurde und 6 Kanäle bereitstellt. (Im 7.1-Fall verweist “pcm.!surround71” natürlich auf ein vorzudefinierendes “dmix71”).

Insgesamt hat unsere “~/.asoundrc” also folgende Device-Kette etabliert:

pcm!default => pcm.simple51 (Upmix) => pcm.!surround51 => pcm.dmix51

Siehe zum hier gewählten Vorgehen für den Default-Upmix auch :
http://forums.bodhilinux.com/index.php?/topic/2493-how-to-51-surround-sound-with-alsa/
http://www.gentoo-wiki.info/HOWTO_Surround_Sound
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture/Example_Configurations

Warum ein zwischengeschobenes Plugin “pcm.simple51” bzw. “pcm.simple71” für den Upmix?

Der aufmerksame Leser wird fragen, warum das Plugin “simple51” (bzw. “simple71”) überhaupt dazwischen geschoben werden muss. Der einfache Grund dafür ist, dass wir unser 6 Kanal-“dmix51”-Gerät (bzw. unser 8 Kanal “dmix71 Gerät) ja auch ohne Upmix von expliziten Mehrkanal-Sound-Quellen unseres PCs nutzen lassen wollen, für die gar kein 2.0=>5.1 Upmix nötig ist und die von Haus aus z.B. das generische “surround51”-Device ansprechen. Beispiel hierfür
wären etwa Video-Player.

Insgesamt fangen die Redefinitionen von “surround20”, “surround40” und eben “surround51” den Upmix ab. Wird eines dieser generischen ALSA-Geräte explizit von einem Player angesprochen, wird es direkt an “dmix51” weitergereicht. (Für 7.1 kommentiert man jeweils die “dmix51”-Zeile und unkommentiert die jeweilige “dmix71”-Zeile).

Nun kommt als Nächstes natürlich die Frage, warum ich die generischen “surround40” und “surround20” nicht auf 5.1 (bzw. 7.1) hochmixe. Gute Frage! Ich lasse das in der Regel bleiben, weil ich dadurch beim Hören direkt erfahre, welche Sound-Applikation die genannten generischen Geräte explizit (also anstelle des ALSA-Default-Devices) anspricht. Ein “40=>51”-Upmix erfordert außerdem spezifischere “ttable”-Einstellungen. “surround40” kommt ferner so gut wie nie vor. Der geneigte Leser kann ja aber bei Lust und Laune zumindest schon mal “surround20” auf “simple51” (bzw. “simple71”) umlenken!

Einstellen des ALSA Default Devices als Phonon Default Device für geeignete Sound-Quellen unter KDE

Bleibt noch ein wichtiger Schritt. Wer hat denn festgelegt, dass KDE oder KDE-Anwendungen – z.B. für Musik – überhaupt das ALSA Default Device nutzen sollen? Bislang niemand ! Deshalb müssen wir das ALSA Default Device explizit an die Spitze der von Phonon erkannten Devices für “Audio=>Musik”-Quellen zu stellen. Dies geschieht über die KDE Systemeinstellungen (aufrufbar über das Kommando “systemsettings”) und dort unter “Hardware=> Multimedia”.

phonon_600

Ergänzung 20.12.2014: Anzeige der ALSA PCM Devices in den Phonon-Einstellungen von KDE

Nachdem ich auf einem meiner Systeme testweise Opensuse 13.2 musste ich feststellen, dass immer weniger erkannte Alsa Devices unter Phonon angezeigt werden. Das bringt uns zu der Frage, wie man eigentlich die in der “~/.asoundrc” definierten PCM Devices in Phonon zur Anzeige bringt. Dies funktioniert für unser redefiniertes Default Device z.B. über die Ergänzung

   
hint {
    show on
    description "ALSA_DEFAULT"
  }

innerhalb des Definitionsbereichs. Siehe oben. Ich habe den Abschnitt für “pcm.!default” ergänzt. Die “hint”-Ergänzung scheint ein allgemeiner Mechanismus zu sein. Er funktioniert nach ersten Tests z.B. auch für “pcm.simple51”. Das kann jeder Leser mal selbst ausprobieren.

Den Hinweis auf “hint” habe ich (gut versteckt) in einem der Abschnitte von
https://intern.radiotux.de/Dmix
gefunden. Siehe auch
http://wiki.ubuntuusers.de/.asoundrc
In beiden Fällen nach “phonon” suchen.

Findet man also aus irgendwelchen Gründen das Alsa Default Device nicht unter den Phonon-Geräten, dei unter den KDE Multimedia-Einstellungen gezeigt werden, so kann man eine Anzeige unseres selbst definierten PCM Devices über “hint” veranlassen, dann in den Phonon-Einstellungen testen und in der Priorität ganz nach oben schieben.

Ähnliche Einstellungen für das von Phonon zu priorisierende Gerät nimmt man für die Punkte “Benachrichtigungen”, “Kommunikation” und “Zugangshilfen” vor.

Für “Audio=>Video”- Quellen wird man dagegen direkt eines der erkannten Multichannel-Geräte auswählen. Da wir u.a. das “surround71” Device nicht umgelenkt haben, können wir (bei entsprechender Anzahl an angeschlossenen Lautsprechern) dann auch vollen 7.1-Kanal-Sound erhalten. Bei Spielen wird man normalerweise auch ein Multichannel-Gerät und nicht das “ALSA-Default Device” verwenden. Für Spiele mit reinem Stereo kann man ja bei Bedarf umschalten.

Bezieht man Phonon mit ein, so sieht unsere
eigentliche Geräte-Kette also wie folgt aus:

KDE => Phonon => Musik => ALSA Default Device => Redefiniertes ALSA Default Device per ~/.asoundrc == pcm!default => pcm.simple51 (Upmix) => pcm.!surround51 => pcm.dmix51 => D2X, genutzt als 6-Kanal-Gerät

Eigentlich gar nicht so komplex. Phonon gibt uns an dieser Stelle einfach weitere Freiheitsgrade.

Damit unsere Einstellungen in der “~/.asoundrc” nun in Gänze wirksam werden müssen wir uns von KDE abmelden und uns danach wieder einloggen. Ein Reboot (oder einfacher ein Neustart des Soundsystems) ist nur nötig, wenn wir die Reihenfolge von Soundkarten vertauscht haben sollten.

Resultierende erweiterte Darstellung unter Kmix

Haben wir alles richtig gemacht, so ergibt sich etwa folgendes Bild unter Kmix :

Der rechte Bereich der Mixer-GUI wurde abgeschnitten. Man erkennt unschwer unseren SW-Lautstärkeregler “SW Master”, der nun kanalübergreifend funktioniert.

Wir testen das Ganze etwa mit Clementine und spielen ein paar Soundtracks ab. Unter “Werkzeuge >> Einstellungen >> Wiedergabe” sollte als Ausgabe-Plugin “Audio sink (ALSA)” festgelegt sein:

Leider erfolgte in meinem Fall die globale Lautstärke-Regelung über den rechten der 2 zu “SW Master” angebotenen Regler, der eigentlich für Aufnahmen gedacht ist. Ich habe noch nicht herausgefunden, wie ich das switchen kann – aber man muss es ja nur wissen.

Man kann nun über “Einstellungen > Hauptkanal auswählen” unseren Regler “SW Master” auswählen. Er wird dann künftig angezeigt, wenn wir auf das “Kmix”-Symbol im Systemsteuerungsabschnitt der KDE-Kontroll-Leiste klicken:

Damit ist (zumindest für das ALSA Default Device eines unserer Ziele für eine bessere Nutzung der Xonar D2X – nämlich die kanalübergreifende Lautstärkeregelung – erreicht.

5.1 Surround Sound und Verkabelung – ein Hinweis

Meine Standard-Lautsprecheranlage am Arbeitsplatz ist von Creative und hat ein 5.1-Anschluss-Kabel für die Soundkarte. Am Anlagenanschluss wird jedoch auch ein Kabel für die Side-Kanäle abgeführt; das System ist intern 7.1-Upmix-fähig. Ein wenig schwachsinnig; aber sehr günstig erstanden 🙂 .

Ich weiss nicht, ob es an dieser seltsamen Kombination liegt, aber die Regelung der 5.1-Kanäle funktioniert nur dann richtig, wenn man die Kabel bei Draufsicht in folgender Reihenfolge in die Analog-Ausgänge der D2X steckt – dabei blicke ich von hinten auf die Karte :

Grün (Creative-Front) – auf grünen Ausgang der Karte (D2X – Front)
Schwarz (Creative-Rear) – auf den orangen Ausgang der Karte (D2X-Side)
Orange (Creative-Center/Subwoofer) – auf den weißen Ausgang der Karte (D2X – Center/Subwoofer)

Das Stecken des schwarzen Kables ist nicht konsistent zur D2X-Beschreibung – funktioniert aber mit den angegebenen Einstellungen in der “~/.asoundrc”. Hier ist die Kanalnummerierung des ALSA-Treibers wohl etwas neben der Intention von Asus. Oder die im Internet verfügbare Beschreibung zur D2X stimmt nicht. Na ja, stört
mich nicht.

Sollte jemand mit einer 5.1-Anlage an der D2X-Probleme mit den Lautsprechern und/oder deren Regelung haben, so sollte er in jedem Fall mal die angegebene Stecker-Reihenfolge ausprobieren.

Übrigens: Bei einem 7.1-Upmix und einem physikalischen 5.1-Abgriff relativiert sich das Ganze dann sowieso.

Ich habe den Befund aber als Hinweis darauf genommen, dass es beim Ansehen von Filmen mit Surround Sound wichtig sein kann, die Lautsprecher-Reihenfolge zu prüfen. Hierzu dann bitte das Progrämmchen “speaker-test” einsetzen. Für 5.1 und unseren einfachen Upmix über “surround51” in der Form:

speaker-test -c 6 -D surround51 -t wav

Natürlich kann man mit

speaker-test -c 6 -D simple51 -t wav

auch unser “simple51” PCM testen.

Ein paar Worte zum Kopfhörer-Anschluss

Es gibt ja bei der D2X keine Möglichkeit, einen Ausgang auf das Frontpanel des PCs zu legen. Kopfhörer muss man also normalerweise (zumindest ohne Elektronik-Bastelei) hinten an der Karte an den Stereo-Ausgang (grün) legen.

Ich habe Gott sei Dank am flexiblen Lautstärkeregler der Lautsprecher-Anlage auch einen Kopfhörerausgang, so dass ich den Kopfhörer nicht hinten in einen der analogen Ausgänge der Karte selbst einstöpseln muss.

Aber auch dem, der das nicht haben sollte, hilft ggf. unser ALSA-Upmix: Bei einem 7.1-Upmix per ALSA und einem physikalischen 5.1-Abgriff wäre auch noch ein Ausgang frei, den man für die Kopfhörer benutzen könnte – auch permanent. Für diesen Ausgang muss man dann aber die Lautstärken-Regelung im Griff haben. Also nach Kopfhörer-Benutzung zur Sicherheit auf 0 stellen.

Direkte Beeinflussung der Signalstärke bei der Kanalzuordnung im Upmix durch ttable-Anweisungen

Der aufmerksame Leser wird sich gewundert haben, dass das oben angegebene PCM Device “pcm.ctrl51” unerwähnt blieb. Ich gehe darauf kurz ein. Um “pcm.ctrl51” zu nutzen, muss man “simple51” als Slave in der “pcm.!default”-Definition auskommentieren und den Kommentar aus der Zeile mit

slave.pcm “ctrl51”

entfernen.

Der Abschnitt zu “pcm.ctrl51” enthält den bekannten Slave “surround51” und explizite “ttable”-Definitionen. Wie z.B.:

#front     
    ttable.0.0 1.0
    ttable.1.1 1.0
#rear left    
    ttable.0.2 1.0
#rear right    
    ttable.1.3 1.0
#center    
    ttable.0.4 0.5
    ttable.1.4 0.5	
#bass    
    ttable.0.5 0.2
    ttable.1.5 0.2

Man erkennt, wie die die Input-Kanäle “0” und “1” (links auf den ersten Punkt in jeder Zeile folgend) auf die 6 Output-Kanäle “0” bis “5” des Slaves verteilt werden. Die Werte ganz rechts in jeder ttable-Zeile geben (lineare elektronische) Signalstärkenverhältnisse an, die der User nun selbst anpassen kann, statt sich auf die “route_policy” von “simple51” zu verlassen. Die weitere Lautstärke-Regelung jedes Kanals auf diesem Grundmix durch die Regler von Kmix bleibt natürlich unbenommen.

Weitere Informationen hierzu findet ihr unter
http://drona.csa.iisc.ernet.in/~uday/alsamch.shtml
Analoge Einstellungen für einen 7.1-Upmix sollten für den Leser kein Problem mehr darstellen.

Viel Spaß nun mit der Nutzung der Xonar D2X, der vereinfachten, kanalübergreifenden Lautstärke-Regelung und dem vorgenommenen 2.0=>5.1 bzw. 2.0=>7.1 “Surround”-Upmix!

Wenn ich Zeit finden sollte, gehe ich einem weiteren Artikel auf weitere Einstellungen zum Upmix und ggf. auch auf die Einbindung von “alsaequ” ein. Wird aber mit Sicherheit ein wenig dauern …

Linux-Blog – Dr. Mönchmeyer / anracon

Notes about Linux, ML and some simple math …

MySQL – SELECT INTO OUTPUT FILE – vermeide zusätzliche UNION Statements!

PHP Code Content Assists und Inline Type Hinting in Eclipse

Münchens LIMUX und ein Editorial des Linux-Magazins

Probleme mit OS 13.2-Upgrade, Backup der OS 13.1 Partition, Grub2, UUIDs

Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1