Category Archives: Opensuse

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

Posted on by

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!

Strato-V-Server – Opensuse 13.1 – get colors for the "ls" shell command

Posted on by

Today, I tried to work with a freshly installed Strato-V-Server. I had chosen Opensuse 13.1 (64 Bit) as the operative system. When I used the “ls” command I missed the standard coloring of directories and special files.

Using the “env” command and a comparison with a normal Opensuse 13.1 installation showed that required settings for the “ls” coloring were missing. SuSE normally adds these settings via a script “ls.bash” located in the directory “/etc/profile.d”. However, this file was missing on the Strato server. [The script in turn uses “/usr/bin/dircolors”, which existed on the system.]

You could compensate the lack of coloring by manually adding a line

ls –color=tty

to a local “.bashrc” file. However, this would only give you parts of the SuSE coloring scheme for your shell.

The missing file “ls.bash” is the result of a really minimum Opensuse 13.1 installation provided by Strato on their V-servers. It took me a while to find the right RPM package which installs the required files. It is the RPM aaa_base-extras.

After the installation of this package and a reopening of your shell “env” will show some additional lines that control the “ls” color settings: 

user@hxxxxxx:~> env | grep LS
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
...
...
LS_OPTIONS=-N --color=tty -T 0
user@hxxxxxx:~>

I hope this information will help others who miss the the usual “ls”-coloring on Strato-V-servers, too.

Asus Xonar D2X unter Linux / Opensuse 13.1 – I

Posted on by

In meinem Linux-PCs habe ich seit ca. einem Jahrzehnt eine Audigy 2 Platinum am Werkeln, die mir schon seit OSS-Zeiten gute Dienste geleistet hat. Leider gibt es die Karte nur noch antiquarisch und auch die PCI-Slots werden auf modernen Mainboards eine Seltenheit. Aus diesem Grunde war ich seit längerem an einer Alternative interessiert.

Ein Bekannter von mir hatte im Frühjahr bei Amazon gute Testberichte zur Xonar D2X PCIe gelesen. Er hat sich schließlich die Karte gekauft und mich gebeten, sie auf seinem PC unter Opensuse 13.1 zum Laufen zubringen. Ich habe mir dann vorab erlaubt, zunächst auf meinem eigenen Systemen Tests durchzuführen. Inzwischen besitze ich die Karte selber.

RM_D2X_600

Daten zu dieser Karte, die 2008 auf den Markt kam und immer noch ca. 120 Euro kostet, findet man z.B. hier:

http://www.guru3d.com/articles_pages/asus_xonar_d2x_sound_card_review,1.html
http://sound-cards-review.toptenreviews.com/asus-xonar-d2x-review.html
http://www.bit-tech.net/hardware/2008/01/13/asus_xonar_d2x_pci-express_soundcard/1
http://www.hardwareluxx.de/index.php/artikel/hardware/multimedia/2255-asus-xonar-d2x.html?start=1
http://www.overclockers.co.uk/showproduct.php?prodid=SC-001-AS&tool=3
http://www.thinkcomputers.org/asus-xonar-dx2-sound-card-review/1/

Die Tatsache, das die Karte schon etwas älter ist, bewerte ich nicht als negativ – insbesondere nicht unter Linux. Es ist dann einfach wahrscheinlicher, dass die Alsa-Integration ausgereift ist.

Bevor ich in einem nachfolgenden Beitrag auf die Grund-Konfiguration unter Opensuse 13.1 eingehe, möchte ich an dieser Stelle zunächst ein paar Worte zur Anschaffung und Einschätzung der Karte verlieren. Vorausschicken will ich, dass ich zur Zeit ein reiner Audio-Endverbraucher bin und beim Arbeiten gelegentlich Musik sowohl über Lautsprecher als auch Kopfhörer höre.

Die Lautsprecher an meinem Arbeitsplatz entstammen einem in die Jahre gekommenen, billigen Inspire T7900 7.1 Speaker Set von Creative Lautsprecher. Eine optische Verbindung zu einer höherwertigen Stereo-Anlage mit Elac 4Pi Lautsprechern wird gelegentlich benutzt. Meistens höre ich allerdings Musik (Klassik, Jazz, Heavy Metal) mit einem Kopfhörer (Sennheiser HD600). Spiele und zugehörige Soundeffekte haben für mich kaum Bedeutung. Zum Spielen bleibt mir schlicht zu wenig Zeit – echter Surround-Sound spielt daher für mich keine entscheidende Rolle. Wohl aber ein UpMix von Stereo auf 7.1 Kanäle.

Alternative zur D2X: 24bit-Karten von Creative

Sowohl meine “Audigy 2 Platinum” wird durch passende Kernelmodule und Alsa unter Linux hervorragend unterstützt. Wie so oft, muss man allerdings Pulseaudio komplett abschalten, um in den Genuss einer vollständig und vernünftig bedienbaren Audio-Karte zu kommen. Zu Pulseaudio und seinen Bugs habe ich sowieso nur einen einzigen Kommentar: Bei Opensuse mit Hilfe von Yast >> Hardware >> Sound >> Andere” komplett deaktivieren und statt dessen mit “Alsa pur” arbeiten. 🙂

Auf einem anderen System PC nutze ich eine Creative X-Fi-
Platinum – allerdings ohne Creatives Frontpanel – und bin damit ähnlich zufrieden wie mit der Audigy 2. Auch hier ist der Einsatz unter Linux inzwischen relativ problemfrei. Angeblich soll ja die Klangqualität der X-Fi Titanium deutlich besser als die der Audigy 2 sein. Na ja, auf den bei uns angeschlossenen Lautsprechern hört man davon nicht so viel. Bei Benutzung von Kopfhörern werden die Unterschiede eher spürbar.

Vorteil der alternativen Creative-Karten

Unter Alsa kommt bei beiden Creative-Karten direkt ein großer Vorteil zum Tragen, der für KDE4 User durchaus von Bedeutung ist:

Höhen und Bass können mit Kmix direkt über den Audio-Prozessor der Creative Karten und damit systemweit geregelt werden.

Zu alten KDE 3.5 Zeiten hätte man darüber nur gelächelt. Die Elimination eines systemweiten Equalizers unter KDE 4.x hat mir das Lachen in der Vergangenheit eher vergehen lassen. Schließlich hat man im Normalfall keine HiFi-Anlage mit allem Schnickschnack an seinen PC angeschlossen. Eher eben irgendwelche Stereo- oder Surround-Speaker in der 100 bis 200 Euro-Klasse. Und dann will man doch gerne die Schwächen der Lautsprecher systemweit kompensieren. Eben durch einen Equalizer des Desktops – oder durch direkte Einstellungen der Soundkarte über Kmix. Dieses Problem ist auf Laptops mit kleinem angeschlossenem Lautsprecher natürlich noch drängender.

Etwas Ähnliches gilt zudem für die Kompensation nachlassender Hörfähigkeiten älterer Mitbürger, zu denen ich mich inzwischen selbst zählen darf (wir haben andere wichtige Qualitäten 🙂 ). Betroffen ist ja meist die Fähigkeit zur Differenzierung im Hochton-Bereich.

Den tragenden KDE-Entwicklern war das Thema eines systemweiten Equalizers aber leider egal oder zu uninteressant – trotz der Einführung der Zwischenschicht Phonon für darunterliegende Audio-Systeme. Gott sei Dank haben wenigstens die Entwickler der verschiedenen Audio-Player diesem KDE-Mangel für ihre eigenen Applikationen abgeholfen – siehe u.a. Clementine und auch Amarok. Ergänzend ist eine systemweite Höhen- und Tiefen-Regelung, wie sie die Audigy2- oder X-Fi-Titanium-Karten von Creative bieten, ein ganz brauchbarer Ersatz für einen fehlenden systemweiten Equalizer.

Zur Xonar D2X und ihrem Klangbild

Den Luxus einer systemweiten Höhen- oder Bass-Regelung wird man bei der Xonar leider nicht bekommen – jedenfalls nicht ohne zusätzliche Einbindung anderer Linux-SW-Module (wie z.B. Ladspa). Warum also doch die Entscheidung für die relativ teure Xonar D2X?

Ganz einfach: Es ist letztlich die für meinen Geschmack und mein Gehör die bessere Karte. Das merkt man aber erst, wenn man mal auf ein und demselben System sowohl die Audigy2, die Titanium als auch die Xonar D2X installiert hat und zwischen den Karten oder deren Ausgängen hin- und herschalten kann. Mit einem höherwertigen Kopfhörer. In meinem Fall durch einfaches Umstecken der Kopfhörer-Stecker und durch Umschalten unter Phonon.

Zu der in diesem Zusammenhang berechtigten Frage, wie man mit Hilfe von Alsa simultan Sound auf den Kanälen zweier installierter Soundkarten abspielen kann, siehe die Links ganz unten. Bei der Hörprobe sollte man natürlich alle Equalizer-Funktionalitäten irgendwelcher Player abschalten. Resultat:

Die Xonar D2X hat meiner Meinung nach ein klareres, konturreicheres Klangbild als die Creative Karten. Ich kann es nicht anders beschreiben. Die Verortung von Instrumenten wirkt präziser, schärfer. In jedem Fall gegenüber der Audigy 2 als auch gegenüber der XFi Titanium. Eine gute Platte zum Testen ist etwa “Grace” von Kjetil Bjørnstad. Tests von Heavy Metal Musik zeigen einen knackigen Bass, der nach meinem Gehör nicht so übertrieben und künstlich wie bei den Creative Karten daherkommt.

Der Rauschabstand ist mit 118 dB
hervorragend. Rauschen ist somit in der Praxis nicht wahrnehmbar.

Für wen ist die Xonar D2X etwas ?

Wer also sollte als die gut 125 Euro in eine Xonar D2X investieren? Aus meiner Sicht Leute, die Musik unverfälscht vom PC über einen hochwertigen Kopfhörer oder eine hochwertige Sound-Anlage hören wollen. Am besten im wav- oder flac-Format.

Die Karte lohnt sich keinesfalls für Spiele; sie lohnt sich definitiv auch nicht bei Einsatz billiger Lautsprecher oder Surround-Sets für PCs.

Was ist an der Xonar D2X störend?

  • Viel weniger Regelmöglichkeiten der Soundverarbeitung als z.B. bei Creative Audigy Karten
    Wir werden im nachfolgenden Artikel feststellen, dass das Spektrum der Regelmöglichkeiten der Karte unter Linux im Vergleich zu Creative-Karten sehr begrenzt ist.
  • Begrenzte Default Upmix-Möglichkeiten:
    Einen Upmix von Stereo auf 5.1, 6.1 bekommt man standardmäßig auch unter Alsa und Kmix nicht frei Haus. Unter Alsa und Kmix wird ein Upmix von 2.0 auf 2.1, 4.0, 7.1 angeboten. Diese Upmix-Varianten funktionieren auch. Will man für andere Situationen einen Upmix, muss entweder die Surround-Anlage dafür einen Schalter bieten – oder man muss etwas tiefer in die Alsa Konfigurationskiste greifen. Hierzu im nächsten Beitrag mehr. Das Thema Upmix lösen die Creative-Karten und ihre Treiber besser – nämlich über ihren internen Prozesssor.
  • Kein Front-Panel-Anschluss
    Es gibt keinen Front-Panel-Anschluss auf der Karte! Das ist völlig nervig! Auch für die Kopfhörer muss man hinten an den PC und ihre analogen Ausgänge! Und auch dort wird kein separater Ausgang angeboten, sondern eben der analoge Ausgang für die Front-Stereo-Kanäle. Da hängt ja aber im Normalfall eine analoge Verbindung zum Verstärker der Soundanlage dran – zumindest dann, wenn man dafür nicht den optischen Ausgang benutzen kann. Sprich: Wenn die Rückseite des PCs schlecht zugänglich ist, muss man sich einen Adapter/Schalter beschaffen oder basteln, der ein Umschalten erlaubt. Aus meiner Sicht ist das ein Design-Fehler!
    Gott sei Dank, hat der Verstärker für das Inspire T7900 7.1 Set einen beweglichen, kabelgebundenen Controller für die manuelle Regelung von Lautstärke und Bass – und an dem Teil befindet sich auch ein Kopfhörerausgang, der die Lautsprecher abschaltet. Damit muss ich die hinteren Anschlüsse der Karte für den Kopfhörer nicht benutzen.
  • Extra Stromanschluss mit veralteten Floppy Steckern erforderlich
    Die Karte erfordert einen zusätzlichen Stromanschluss per Floppy-Strom-Kabel – sonst weigert sie sich zu funktionieren. Ein entsprechendes Kabel wird jedoch nicht mitgeliefert. Ich selbst hatte solche Kabel aber noch vorrätig. Der Anschluss wirkt altertümlich; eine etwas wackelige Angelegenheit.

Sonstige Verarbeitung der Xonar D2X

Ansonsten gibt es an der Verarbeitung der Karte kaum etwas zu meckern. Für eine gute Abschirmung ist durch eine kastenartige EMI-Ummantelung gesorgt. Die kann wegen ihrer Ausdehnung evtl. bei voluminöseren Karten in der Nachbarschaft Probleme bereiten. Schwierigkeiten mit der Wärmeabfuhr konnte ich bislang nicht feststellen, obwohl die Karte direkt über einer Nvidia GTX 460 Grafik-Karte verbaut ist. Die analogen Anschlüsse hinten sind veredelt. Auf den Beleuchtungsschnickschnak – ja, die Anschlüsse leuchten in unterschiedlichen Farben ! – hätte ich allerdings auch gut verzichten können. Ist eher was für Modder.

Im nächsten Beitrag

Asus Xonar D2X unter Linux /
Opensuse 13.1 – II

stelle ich dar, wie die (einfache) Basis-Installation unter Opensuse 13.1 erfolgt und welche Regelmöglichkeiten z.B. Kmix danach für die Karte anbietet. Wir werden dann merken, dass die Einstellmöglichkeiten im Vergleich zu einer Audigy (leider) dramatisch geringer ausfallen. In einem weiteren danach folgenden Artikel
Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1
liefere ich eine einfache “.asoundrc”-Konfiguration für evtl. Upmix-Probleme nach.

Links zum parallelen Einsatz mehrer Soundkarten unter Alsa

http://slack4dummies.blogspot.de/2012/02/alsa-multiple-output-multiple-sound.html
https://www.6by9.net/output-to-multiple-audio-devices-with-alsa/

Opensuse 13.1 – Kernelmodule beim Booten statisch laden

Posted on by

Nach einer kompletten Neuinstallation von Opensuse 13.1 auf einem meiner Systeme gab es keinen Eintrag mehr für das automatische, statische Laden von Kernelmodulen beim Booten in YaST’s Modul “/etc/sysconfig”-editor”. Normalerweise fand sich ein solcher Eintrag unter:

YaST2 >> Editor für /etc/sysconfig >> System >> Kernel >> MODULES_LOADED_ON_BOOT

Unter OS 13.1 fehlt der Punkt MODULES_LOADED_ON_BOOT dagegen einfach. Ich hatte diese Konfigurationsmöglichkeit in der Vergangenheit immer mal wieder benutzt, um bestimmte Module automatisch zur Bootzeit zu laden. Ein Beispiel ist etwa das Module “loop” zur Behandlung von Loop-Devices. Solche Devices brauche ich etwa im Zusammenhang mit Tests von virtuellen Maschinen oder aber um Realcrypt-Container ins Filesystem einzuhängen.

YaST2’s “/etc/sysconfig”-Editor-Modul editiert unter “System >> Kernel” über Schlüsselwörter entsprechende Einträge in der Datei “/etc/sysconfig/kernel“. Natürlich konnte man diese Datei auch manuell editieren. Unter OS 13.1 findet sich in der Datei selbst kein Bereich mehr zum Schlüsselwort MODULES_LOADED_ON_BOOT.

Dass der Punkt zum Laden von Kernelmodulen unter YaST2 nicht mehr automatisch vorhanden ist, war mir bislang nicht aufgefallen, da ich die meisten meiner Systeme von Opensuse 12.3 aus upgegradet hatte. Offenbar wurden auf den upgegradeten Maschinen die ursprünglich unter MODULES_LOADED_ON_BOOT angegebenen Module aber anstandslos geladen.

Anlass genug, den Änderungen auf den Grund zu gehen.

Korrespondierende Einstellungen konnte man früher übrigens unter Red Hat in der Datei “/etc/rc.modules”, unter Arch Linux unter der “/etc/rc.conf” und unter Debian in der “/etc/modules” vornehmen. Wenn sich bewährte sysconfig-Dinge im einstmals überschaubaren, script-getriebenen Boot-Prozess plötzlich verändern oder entfernt werden, liegt der Verdacht nahe, dass das mit Auswirkungen der Einführung von “systemd” zu tun hat.

Tatsächlich ist dem auch in diesem Fall so. Eigentlich logischerweise – ob man systemd nun mag oder nicht …. Immerhin sorgt es nun zwischen den Distributionen, die heute “systemd” einsetzen, für eine gewisse Vereinheitlichung – auch wenn bisherige Einstellmöglichkeiten über bewährte Admin-Tools dadurch wegfallen.

Interessanterweise legte aber der bei einer Internet-Recherche auftauchende Artikel
http://b.agilob.net/opensuse-how-to-install-truecrypt/
nahe, dass das Schlüsselwort MODULES_LOADED_ON_BOOT in der Datei “/etc/sysconfig/kernel” auch von Opensuse 13.1 sehr wohl noch beachtet wird.

Nach einem Blick auf die systemd-bedingten Änderungen diskutiere ich weiter unten daher 3 Wege, um Kernelmodule unter Opensuse 13.1 gezielt zu laden – ohne dies in Grub oder Grub2 zu verankern. Zukunftsträchtig ist wegen “systemd” vermutlich nur der letzte der Wege sein, obwohl gerade das dortige Vorgehen nicht mehr die Möglichkeit bietet, YaST zur Konfiguration heranzuziehen. Ich beschreibe das Vorgehen jeweils am Beispiel des Moduls “loop”. Zunächst gehe ich aber auf das statische Laden von Kernelmodulen unter “systemd”-Bedingungen ein.

systemd und das statische Laden von Kernel-Modulen im Boot-Prozess

systemd liegt u.a. die Vorstellung zugrunde, dass der Boot-Prozess letztlich das Bereitstellen von Service-, Socket, Mount und Device-Units für bestimmte Target-Zustände leistet und dabei bestehende Abhängigkeiten auflöst. Im Rahmen dieser Philosophie erwartet man einen relativ freistehenden elementaren Service, der Kernel-Module lädt. Wie das prinzipiell funktioniert beschreiben folgende Artikel:
http://0pointer.de/blog/projects/the-new-configuration-files
https://wiki.archlinux.org/index.php/systemd
https://wiki.archlinux.de/title/Wechsel_von_Sysvinit_zu_systemd
https://wiki.archlinux.de/title/Kernelmodule#Module_beim_Systemstart_automatisch_laden

Wir zitieren aus dem zweiten wiki-Artikel für Arch-Linux:

Alle Module die bisher in der rc.conf bei MODULES=() eingetragen waren müssen jetzt in eine Datei in /etc/modules-load.d/ eingetragen werden.

Unter Opensuse 13.1 gilt das Analoge für diejenigen Module, die bisher in der “/etc/sysconfig/kernel” unter dem Parameter MODULES_LOADED_ON_BOOT eingetragen wurden.

Und weiter aus dem dritten wiki-Arch-Artikel:

Die meisten benötigten Module werden beim Systemstart vom Init System erkannt und automatisch geladen. Es kann allerdings vorkommen, dass einige Module nicht automatisch erkannt werden. Sollen diese dennoch bei jedem Systemstart geladen werden, müssen sie in eine Datei mit der Endung .conf im Verzeichnis /etc/modules-load.d/ eingetragen werden. Der Name der Datei ist frei wählbar, sie muss nur die Endung .conf haben. Zum Beispiel /etc/modules-load.d/my-modules.conf. Die zu ladenden Module werden zeilenweise in diese Datei eingetragen.

Wie systemd konkret mit einem solchen File unter “/etc/modules-load.d/” umgeht, beschreibt konkret die Antwort auf eine entsprechende Frage in folgendem Forum
http://unix.stackexchange.com/questions/71064/automate-modprobe-command-at-boot-time-on-fedora

Weitere Auskünfte geben folgende man-Seiten:

man systemd-modules-load.service
man modules-load.d

Mit eigenen Worten zusammengefasst:

Unter systemd sorgt ein spezieller Service “systemd-modules-load.service” für das gezielte statische Laden von Kernelmodulen. Die Service-Unit “systemd-modules-load.service” wird spätestens vom systemd-Target “sysinit.target” angefordert. Welche Module durch diese spezielle Unit geladen werden, wird u.a. über Dateien der Form “*.conf” unter dem Verzeichnis “/etc/modules-load.d/” gesteuert. In jeder dieser Dateien kann eine Liste von Modulen angegeben werden. Jedes Modul wird in eine separate Zeile eingetragen.

Hingewiesen sei darauf, dass der Service neben den dateien unter “/etc/modules-load.d/”
auch noch Dateien aus anderen Verzeichnissen aufsammelt! Vorgegeben ist das durch die Datei
“/usr/lib/systemd/system/sysinit.target.wants/systemd-modules-load.service”:

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
 
[Unit]
Description=Load Kernel Modules
Documentation=man:systemd-modules-load.service(8) man:modules-load.d(5)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionCapability=CAP_SYS_MODULE
ConditionPathExists=|/etc/sysconfig/kernel
ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d
ConditionDirectoryNotEmpty=|/etc/modules-load.d
ConditionDirectoryNotEmpty=|/run/modules-load.d
r
ConditionKernelCommandLine=|modules-load
ConditionKernelCommandLine=|rd.modules-load
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-modules-load

Siehe auch:
https://disunitedstates.org/wiki/index.php/Systemd-modules-load.service

Wie man die Module nach Einsatzzwecken in separaten Dateien unter “/etc/modules-load.d/” organisiert, kann man selbst festlegen. Ich habe nicht überprüft, ob eine Nummernvergabe am Anfang des Namens im Stile “nn-name.conf”, wie sie unter Opensuse z.B. im Verzeichnis “/etc/modprobe.d/” vorgenommen wird, auch im Verzeichnis “etc/modules-load.d/” wirksam wirkt, um eine Reihenfolge der Abarbeitung zu erzwingen. Wahrscheinlich nicht. Was wiederum zu Problemen führen kann – siehe
http://archlinux.2023198.n4.nabble.com/systemd-fails-to-set-console-font-td4657110.html

Was ist zu tun, wenn dem Modul auch noch Parameter übergeben werden sollen? Hier hat sich eigentlich nicht viel geändert – im zweiten Artikel findet man eine Beschreibung des klassischen Vorgehens, um den geladenen Modulen Parameter zu übergeben. Dazu sind zusätzliche Dateien unter “/etc/modeprobe.d/” anzulegen.

Unter dem Verzeichnis “/etc/modprobe.d” findet man unter OS 13.1 in der Regel denn auch mit hoher Wahrscheinlichkeit einige Beispiele (u.a. für die jeweilie Soundkarte), die zeigen, wie die Übergabe von Parametern funktioniert. Zur Namensgebung und der Bedeutung der spezifischen Ziffern (seit OS 11.2) siehe
http://forums.opensuse.org/showthread.php/419615-11-2-new-modprobe-d-naming-convention
und dort den letzten Beitrag. Oder auch an einem konkreten Beispiel:
http://en.opensuse.org/SDB:Intel-HDA_sound_problems

Unter Opensuse kann man spezifische lokale Parameterübergaben demnach am besten in einer Datei

/etc/modprobe.d/99-local.conf

abhandeln.

Siehe zur Parameterübergabe an die Module aber auch:
https://bbs.archlinux.org/viewtopic.php?id=176942
http://www.opensuse-forum.de/allgemeines/opensuse-installation/8793-gel%C3%B6st-deprecated-config-file/

Wodurch wurde das früher MODULES_LOADED_ON_BOOT in der Datei “/etc/sysconfig/kernel” unter OS 13.1 ersetzt?

Nach dem erarbeiteten Wissen zum Laden von Kernelmodulen über die systemd-Service-Unit “systemd-modules-load.service” liegt es nahe, dass die unter älteren Opensuse-Versionenen vorgebenen Einträge in “/etc/sysconfig/kernel” beim Upgrade auf OS 13.1 in eine Datei unter “/etc/modules-load.d” verschoben wurden. Tatsächlich findet man dort auf meinen upgegradeten Systemen die Datei

/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf

Die enthält erwartungsgemäß alle ursprünglich mal über YaST vorgebenen statisch zu ladenden Module.

Ich beschreibe nachfolgend nun drei Wege, wie man unter OS 13.1 z.B. das Modul “loop” statisch beim Booten laden kann.

Weg 1 – händischer Eintrag MODULES_LOADED_ON_BOOT in der Datei
“/etc/sysconfig/kernel”

Folgender händischer Eintrag am Ende der Datei “/etc/sysconfig/kernel” führt zum Erfolg :

## Type: string
## Default: “”
#

# Old fashioned way to load kernel modules under OS 13.1
# Added by root, 27.05.2014
MODULES_LOADED_ON_BOOT=”loop”

Für die Dateiänderung sind natürlich root-Rechte erforderlich. Beim nächsten Start von OS 13.1 wird das Kernel-Module “loop” tatsächlich geladen.

Netterweise taucht nun auch in YaST’s “/etc/sysconfig”-Editor wieder die Möglichkeit zum Editieren des Eintages auf. Ich nehme an, dass Weg 1 z.Z. noch durch nicht bereinigte YaST-Überbleibsel aus vergangenen Zeiten ermöglicht wird. Erweitert oder ändert man übrigens den händisch vorgenommenen Datei-Eintrag mittels YaST’s sysconfig-Editor und nicht durch direktes Bearbeiten der Datei, so wird der Eintrag von YaST auch an “mkinitrd” übergeben. Ich weiß nicht, wie man das unterbinden kann. Notwendig ist diese Übergabe nicht; eigentlich sollten über mkinitrd ja nur Module zu beginn des Bootprozesses zum Tragen kommen, die zum Auslesen von Boot-Devices und zum Ansteuern anderer wichtiger Hardware unumgänglich sind.

Weg 2 – Ergänzen der Module unter
YaST2 >> Editor für /etc/sysconfig >> System >> Kernel >> INITRD_MODULES

Bei diesem Weg verankert man das Laden des gewünschten Modules explizit über “mkinitrd” in die initiale Auswertung eines “initramfs” cpio-Archivs des Kernels (im RAM). Ein totaler Overkill – aber möglich. Natürlich könnte man den Abschnitt zu INITRD_MODULES auch direkt in der Datei “/etc/sysconfig/kernel” editieren. Dieser zweite Weg gefällt mir nicht, weil er explizit ein Modul in das “initramfs”-cpio-Archiv des Kernels verlagert, das aus meiner Sicht dort eigentlich wenig zu suchen hat.

Weg 3 – Anlegen einer Datei
“/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf”
mit einer Zeile zu dem gewünschten Modul

Der Inhalt der Datei “/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf” ist in unserem Beispiel für das Modul “loop” denkbar simpel:

mytux:~ # echo loop > /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf
mytux:~ # cat /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf
loop

Weitere benötigte statische Module ergänzt man durch neue Zeilen pro Modul. Natürlich hätte man die Datei auch “loop.conf” nennen können. Ich finde die auch von Opensuse selbst gewählten Namen aber instruktiv.

Nach dem erneuten Starten des Systems kann man den Status des zugehörigen systemd-Services abfragen mit:

mytux:~ # systemctl status systemd-modules-load.service
systemd-modules-load.service – Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
Active: active (exited) since Tue 2014-05-27 17:36:06 CEST; 1min 2s ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 353 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Main PID: 353 (code=exited, status=0/SUCCESS)

May 27 17:36:06 mytux systemd[1]: Starting Load Kernel Modules…
May 27 17:36:06 mytux systemd-modules-load[353]: Inserted module ‘loop’
May 27 17:36:06 rux systemd[1]: Started Load Kernel Modules.
 
 
mytux:~ # lsmod | grep loop
loop 27985 0
mytux:~ #

Obwohl ich systemd nicht mag, empfehle ich, diesen Weg 3 zum statischen Laden von Kernelmodulen ab Opensuse 13.1 zu gehen. Auch wenn man dann auf eine einfache Konfiguration mit YaST verzichten muss.

Munin – nach Opensuse Upgrade wieder herstellen

Posted on by

Ich nutze auf einem Opensuse Server Munin – u.a. auch zur Überwachung von LDAP und MySQL. Nach einem Upgrade des Systems von Opensuse 12.3 auf Opensuse 13.1 funktionierte Munin leider nicht mehr. Im Paketmanager wurde mir angezeigt, dass es keine installierten Pakete mehr gab. Offenbar wurden die beim Upgrade deinstalliert.

Ich musste Munin nachinstallieren und zwingend als nativen “systemd”-Service aktivieren (besser: “enablen”). Im Verzeichnis “/etc/init.d” wird man unter OS 13.1 keine Munin-Startup-Datei mehr finden. Man erhält Munin für OS13.1 über das Repository
http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1

Dann die Pakete “munin” und “munin-node” per Yast2’s Software Management installieren. Der RPM Paket-Manager legt Sicherungskopien der Konfigurationsdateien

/etc/munin/munin.conf
/etc/munin/munin-node.conf
/etc/munin/plugin-conf.d/munin-node

an. Diese kann man nutzen, um die alten Konfigurationseinstellungen in die neuen Dateien zu übernehmen.

Danach

systemctl enable munin-node.service

Und schon läuft die Sache wieder. Die alten Daten bzw. Plots unter “/srv/wwww/htdocs/munin” und dort unter dem konfigurierten Munin-Tree sind nicht verloren, sondern werden weitergeführt. Auf aktualisierte Wochenplots muss man nach der Neuinstallation natürlich aber noch etwas warten ….