Marix.org - openSUSEhttps://marix.org/2024-03-24T00:00:00+01:00Am Linuxrechner Bluetooth per USB nachrüsten2024-03-24T00:00:00+01:002024-03-24T00:00:00+01:00Matthias Bachtag:marix.org,2024-03-24:/am-linuxrechner-bluetooth-per-usb-nachrusten.html<p>Ich brauchte kürzlich an meinem gut abgehangenen Desktop-Rechner dann doch mal die Möglichkeit meine Sony-Kopfhörer per Bluetooth zu verbinden.
Da Bluetooth vor 10 Jahren allerdings für Hauptplatinen von normalen Rechnern noch nicht üblich war, hat mein Rechner kein Bluetooth.
Ich habe deshalb jetzt, ohne große Recherche und nur von der …</p><p>Ich brauchte kürzlich an meinem gut abgehangenen Desktop-Rechner dann doch mal die Möglichkeit meine Sony-Kopfhörer per Bluetooth zu verbinden.
Da Bluetooth vor 10 Jahren allerdings für Hauptplatinen von normalen Rechnern noch nicht üblich war, hat mein Rechner kein Bluetooth.
Ich habe deshalb jetzt, ohne große Recherche und nur von der spontanen Verfügbarkeit getrieben, einen BT-8500 von Edimax gekauft.
In den USB-Port eingesteckt poppte im KDE sofort das Bluetooth-Applet auf und ich könnte die Kopfhörer verbinden.
Die Verbindung zu den Kopfhörer ist auch richtig stabil, mindestens genau so gut wie vom Fairphone.</p>
<p>Wie gut der Adapter für andere Szenarien geeignet ist kann ich nicht sagen.
Aber wer sich fragt ob ein Edimax BT-8500 unter openSUSE Leap 15.5 für Bluetooth-Audio funktioniert: das geht komplett ohne Bastelei.</p>Minecraft auf openSUSE Leap 15.52024-01-06T15:00:00+01:002024-01-06T15:00:00+01:00Matthias Bachtag:marix.org,2024-01-06:/minecraft-auf-opensuse-leap-155.html<p>Während Minecraft auf openSUSE früher auf älteren Version immer einfach so funktioniert hat, endet der Versuch Version 1.20.4 auf openSUSE Leap 15.5 zu starten reproduzierbar mit einem Absturz.</p>
<p><img alt="Bildschirmfoto der Fehlermeldung "Spielabsturz" beim Versuch Minecraft 1.20.4 auf openSUSE Leap 15.5 zu starten" src="https://marix.org/Bilder/Minecraft auf OpenSUSE Leap 15.5/Fehlermeldung.png"></p>
<p>Der in der Fehlermeldung angegebene Exit-Code 6 hiflt leider nicht viel weiter.
Suchen danach führen zu vielen verschiedenen möglichen …</p><p>Während Minecraft auf openSUSE früher auf älteren Version immer einfach so funktioniert hat, endet der Versuch Version 1.20.4 auf openSUSE Leap 15.5 zu starten reproduzierbar mit einem Absturz.</p>
<p><img alt="Bildschirmfoto der Fehlermeldung "Spielabsturz" beim Versuch Minecraft 1.20.4 auf openSUSE Leap 15.5 zu starten" src="https://marix.org/Bilder/Minecraft auf OpenSUSE Leap 15.5/Fehlermeldung.png"></p>
<p>Der in der Fehlermeldung angegebene Exit-Code 6 hiflt leider nicht viel weiter.
Suchen danach führen zu vielen verschiedenen möglichen Problemen.
Einen guten Hinweis liefert aber der über die Fehlermeldung erreichbare Absturzbericht:</p>
<pre><code>#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000000000, pid=22905, tid=22907
#
# JRE version: (17.0.8+7) (build )
# Java VM: OpenJDK 64-Bit Server VM (17.0.8+7-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libjimage.so+0x3ac8] ZipDecompressor::decompress_resource(unsigned char*, unsigned char*, ResourceHeader*, ImageStrings const*)+0x28
#
</code></pre>
<p>Grund für den Absturz ist ein ungültiger Speicherzugriff.
Und dieser scheint nicht im eigentlichen Minecraft-Code sondern in der Java-Laufzeitumgebung (JRE) selbst zu passieren.
Es scheint also eine Inkompatilibität zwischen der von Minecraft verwendeten Java-Laufzeitumgebung und openSUSE Leap 15.5 zu geben.</p>
<p>Glücklicherweise lässt sich die von Minecraft verwendete Java-Laufzeitumgebung konfigurieren.
Diese findet sich im Abschnitt "Mehr Optionen" der Installationseinstellungen.
Tragen wir hier <code>/usr/bin/java</code> ein, so wird das aktuellste auf dem System installierte Java verwendet.</p>
<p><img alt="Bildschirmfoto der Auswahl der Java-Programmdatei in der Konfiguration einer Minecraft-Installation" src="https://marix.org/Bilder/Minecraft auf OpenSUSE Leap 15.5/Konfiguration der Java-Version.png"></p>
<p>Sollten wir später zur mitgelieferten Version zurückkehren wollen, so können wir den Wert über das X neben dem Feld auch wieder löschen.
In diesem Fall benutzt Minecraft dann wieder seine eigene Version.</p>
<p>Die Konfiguration einer Installation von Minecraft finden wir übrigens unter „Bearbeiten“ im erweiterten Menü der Installation im Reiter „Installationen“.</p>
<p><img alt="Bildschirmfoto vom Zugang zur Installationskonfiguration" src="https://marix.org/Bilder/Minecraft auf OpenSUSE Leap 15.5/Zugang zu den Einstellungen einer Installation.png"></p>
<p>Sollte auf unserem System keine aktuelle Laufzeitumgebung für Java installiert sein, so endet der nächste Versuch Minecraft zu starten übrigens wieder mit einer Fehlermeldung.
Die Laufzeitumgebung können wir in diesem Fall schnell per Zypper nachinstallieren.
Da der Absturzbericht uns verraten hat, dass Minecraft normallerwise Version 17 verwendet, installieren wir am besten auch genau diese nach:</p>
<pre><code>sudo zypper in java-17-openjdk
</code></pre>
<p>Danach können wir dann endlich Minecraft auf openSUSE Leap 15.5 genießen.</p>
<p><img alt="Bildschirmfoto eines laufenden Minecraft 1.20.4 auf openSUSE Leap 15.5" src="https://marix.org/Bilder/Minecraft auf OpenSUSE Leap 15.5/Erfolg.png"></p>Pre-commit auf openSUSE Leap 15.42022-02-07T00:00:00+01:002022-02-07T00:00:00+01:00Matthias Bachtag:marix.org,2022-02-07:/pre-commit-auf-opensuse-leap-154.html<p>Beim Upgrade von openSUSE Leap 15.3 auf openSUSE Leap 15.4 ergibt sich bei <a href="https://pre-commit.com/"><code>pre-commit</code></a> ein interessantes Problem.
Auf älteren Versionen von Leap konnte das Paket aus dem <a href="https://build.opensuse.org/project/show/devel:languages:python">Entwicklungsprojekt <code>devel:languages:python</code></a> installiert werden.
Dort findet sich aber keine Version für Leap 15.4.
Eine solche findet sich jetzt …</p><p>Beim Upgrade von openSUSE Leap 15.3 auf openSUSE Leap 15.4 ergibt sich bei <a href="https://pre-commit.com/"><code>pre-commit</code></a> ein interessantes Problem.
Auf älteren Versionen von Leap konnte das Paket aus dem <a href="https://build.opensuse.org/project/show/devel:languages:python">Entwicklungsprojekt <code>devel:languages:python</code></a> installiert werden.
Dort findet sich aber keine Version für Leap 15.4.
Eine solche findet sich jetzt in meinem Projekt <a href="https://build.opensuse.org/package/show/home%3AtheMarix%3Apy36/python-pre-commit"><code>home:theMarix:py36</code></a> und lässt sich von dort einfach installieren:</p>
<pre><code>zypper addrepo https://download.opensuse.org/repositories/home:theMarix:py36/15.4/home:theMarix:py36.repo
zypper refresh
zypper install python3-pre-commit
</code></pre>
<p>Das Problem entsteht, weil <a href="https://pre-commit.com/"><code>pre-commit</code></a> es bisher nicht in die Distribution geschafft hat.
Das ist normalerweise kein Problem, weil die Pakete in den Entwicklungsprojekten auch für alle aktuellen Versionen von Leap gebaut werden.
Speziell bei Leap 15.4 ist hier aber etwas interessantes passiert.
<a href="https://pre-commit.com/"><code>pre-commit</code></a> hat in Version 2.17.0 verständlicherweise die Unterstützung für Python 3.6 fallengelassen.
Allerdings setzt Leap 15.4 aus Kompatibilitätsgründen noch auf diese Version von Python.
Da jetzt aber das Upgrade auf 2.17.0 in <code>devel:languages:python</code> passierte bevor Leap 15.4 angelegt wurde, wurde die letzte mit Python 3.6 lauffähige Version 2.16.0 nie für Leap 15.4 gebaut.
Anders für Leap 15.3, für das genau diese Version bis zuletzt noch installierbar war.</p>
<p>Im Projekt <a href="https://build.opensuse.org/package/show/home%3AtheMarix%3Apy36/python-pre-commit"><code>home:theMarix:py36</code></a> befindet sich jetzt einfach ein Link auf die letzte Revision des Pakets in <code>devel:languages:python</code> die noch mit Python 3.6 kompatibel war.
So gibt es jetzt zwar leider keine aktuelle Version von <a href="https://pre-commit.com/"><code>pre-commit</code></a> für Leap 15.4, aber immerhin eine ohne Verrenkungen nutzbare, die mit dem Update auf 15.5 wird sich dass dann ganz von alleine wieder auf das aktuelle Paket wechseln wird.
Und auch wenn das jetzt wahnsinnig aufwendig klingt, der Zeitaufwand das Paket anzulegen war geringer als der diesen Artikel zu schreiben.</p>KTorrent friert ein2022-01-29T00:00:00+01:002022-01-29T00:00:00+01:00Matthias Bachtag:marix.org,2022-01-29:/ktorrent-friert-ein.html<p>Die Tage musste ich leider Feststellen, dass mein KTorrent beim Download der aktuellen <a href="https://haveibeenpwned.com/Passwords">Pwned-Passwords-List von Have I been Pwned</a> komplett einfror.
<a href="https://www.qwant.com/?q=ktorrent+freezes">Eine Suche nach dem Problem</a> liefert nicht viele Treffer, aber fördert <a href="https://forums.opensuse.org/showthread.php/523076-Ktorrent-freeze-and-Firefox">einen 5 Jahre alten Forenbeitrag zutage, der eine Lösung für das Problem liefert</a>.
Den Firefox einmal kurz zu …</p><p>Die Tage musste ich leider Feststellen, dass mein KTorrent beim Download der aktuellen <a href="https://haveibeenpwned.com/Passwords">Pwned-Passwords-List von Have I been Pwned</a> komplett einfror.
<a href="https://www.qwant.com/?q=ktorrent+freezes">Eine Suche nach dem Problem</a> liefert nicht viele Treffer, aber fördert <a href="https://forums.opensuse.org/showthread.php/523076-Ktorrent-freeze-and-Firefox">einen 5 Jahre alten Forenbeitrag zutage, der eine Lösung für das Problem liefert</a>.
Den Firefox einmal kurz zu schließen taut KTorrent wieder auf.</p>
<p>Das Problem scheint nur aufzutreten, wenn KTorrent aus dem Firefox startet.
Das passiert wenn man Firefox einen Link auf eine Torrent-Datei mit KTorrent öffnen lässt, dieser aber noch nicht lief.
Dadurch gibt zwei einfache Wege das Problem zu umgehen und die obige Lösung dann gar nicht erst zu brauchen:</p>
<ol>
<li>Ist KTorrent bereits gestartet bevor Firefox die Datei übergibt, so scheint das Problem nicht aufzutreten.</li>
<li>Kopiert man die URL der Torrent-Datei in die Zwischenablage, kann man diese auch aus KTorrent direkt mit <em>Datei - Adresse öffnen</em> bzw. <code>Strg+P</code> öffnen und umgeht die Interaktion zwischen Firefox und KTorrent komplett.</li>
</ol>Bootprobleme mit Leap 15.3 und Radeon-Grafik2022-01-28T00:00:00+01:002022-02-07T00:00:00+01:00Matthias Bachtag:marix.org,2022-01-28:/bootprobleme-mit-leap-153-und-radeon-grafik.html<p>Mit dem am Mittwoch durch den Patch <code>openSUSE-SLE-15.3-2022-198</code> gelieferten Kernel mit Version <code>5.3.18-150300.59.43.1</code> startet Leap 15.3 auf vielen Systemen mit Radeon-Grafik nicht mehr.
Gleich nach dem Laden des Kernels friert das System ein und schaltet die Bildschirmausgabe ab.
Glücklicherweise gibt es aber gleich …</p><p>Mit dem am Mittwoch durch den Patch <code>openSUSE-SLE-15.3-2022-198</code> gelieferten Kernel mit Version <code>5.3.18-150300.59.43.1</code> startet Leap 15.3 auf vielen Systemen mit Radeon-Grafik nicht mehr.
Gleich nach dem Laden des Kernels friert das System ein und schaltet die Bildschirmausgabe ab.
Glücklicherweise gibt es aber gleich zwei einfache Wege betroffene Systeme wieder zum laufen zu bekommen.
Die Systeme können entweder mit der vorherigen Kernelversion oder dem Kernelparameter <code>nomodeset</code> gestartet werden.</p>
<p>Die schnellste Variante ist sicher einfach den vorherigen Kernel zu starten.
Dieser lässt sich im Bootmenü von Grub über die erweiterten Optionen einfach auswählen.
Standardmäßig hebt openSUSE übrigens immer den genutzten und die zwei neuesten Kernel auf.
Es sollte also immer ein funktionsfähiger Kernel zur Verfügung stehen.
Mehr zu diesem Feature findet sich in <a href="https://marix.org/alte-kernelversionen-installiert-behalten.html">einem älteren Artikel von mir</a>.</p>
<p>Stört es, wie beispielsweise bei einem sowieso ohne Monitor betriebenen System, nicht, wenn das Modesetting nicht funktioniert, so lässt sich auch der neue Kernel booten.
Der Bug lässt sich durch Nutzung des Kernelparameters <code>nomodeset</code> umgehen.
Am einfachsten lässt sich dieser über das Modul <em>Bootloader</em> im Abschnitt <em>System</em> von YaST konfigurieren.
Dafür muss das System aber erst mal laufen.
Dafür kann entweder, wie oben beschrieben der alte Kernel genutzt werden, oder der Parameter einmal beim Start manuell gesetzt werden.</p>
<p>Um den Bootparameter beim Start manuell zu setzen muss im Bootmenü die Taste <code>E</code> gedrückt werden.
Dies öffnet den gerade ausgewählten Startmenüeintrag in einem einfachen Editor.
Hier ist die mit <code>linux</code> beginnende Zeile zu suchen und an deren Ende der Parameter <code>nomodeset</code> hinzuzufügen.
Durch einen Druck auf <code>F10</code> startet das System dann mit dem modifizierten Eintrag.
Der Eintrag wird allerdings nicht permanent übernommen.
Man muss ihn anschließend noch per YaST persistieren, kann sich dafür aber auch erst mal nichts kaputt machen.</p>
<p>Mehr Informationen zu diesem Problem finden sich <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1195168">im Bugzilla</a>.
Dort gibt es auch schon eine verifizierte richtige Lösung des Problems, welche im nächsten Kernel-Patch dann enthalten sein dürfte.</p>
<p><strong>Aktualisierung vom 7.2.2022</strong>: Mit dem Update <code>openSUSE-SLE-15.3-2022-340</code>, welches den Kernel auf Version <code>5.3.18-150300.59.46</code> hebt, ist das Problem behoben.
Die betroffenen Systeme starten auch ohne den Workaround <code>nomodeset</code> zu nutzen wieder.
Solltet Ihr vorsichtshalber den letzten Kernel, mit dem euer System noch gestartet hat, zur dauerhaften Aufbewahrung markiert haben, so solltet ihr nicht vergessen auch dies wieder rückgängig zu machen.
Sonst liegt der alte Kernel unnötig dauerhaft rum.</p>Die Beta von openSUSE Leap 15.3 ist da2021-03-06T00:00:00+01:002021-03-06T00:00:00+01:00Matthias Bachtag:marix.org,2021-03-06:/die-beta-von-opensuse-leap-153-ist-da.html<p>Diese Woche <a href="https://news.opensuse.org/2021/03/03/opensuse-leap-153-reaches-beta-build-phase/">erschien die Beta von openSUSE Leap 15.3</a>, der nächsten Version von openSUSE Leap.
Ich habe meinen primären privaten Rechner bereits darauf aktualisiert und es war völlig unspektakulär.
Was auf den ersten Blick enttäuschend klingt ist aber etwas wirklich gutes, denn es heißt, dass ich keinerlei Probleme hatte …</p><p>Diese Woche <a href="https://news.opensuse.org/2021/03/03/opensuse-leap-153-reaches-beta-build-phase/">erschien die Beta von openSUSE Leap 15.3</a>, der nächsten Version von openSUSE Leap.
Ich habe meinen primären privaten Rechner bereits darauf aktualisiert und es war völlig unspektakulär.
Was auf den ersten Blick enttäuschend klingt ist aber etwas wirklich gutes, denn es heißt, dass ich keinerlei Probleme hatte und weiterhin alles funktioniert.</p>
<p>Das die Aktualisierung auf die nächste Version so unspektakulär ist war gar nicht so selbstverständlich, denn technisch gab es unter der Haube größere Umwälzungen.
OpenSUSE verwendet für alles, dass es auch in SUSE Linux Enterprise gibt, direkt das Paket von dort.
Eine gute Nachricht, für alle, die auf ein grundsolides System bauen wollen.
Durch die direkte Nutzung der Pakete von SLE gibt es auch nicht nur maximale Kompatibilität, sondern Patches werden auch direkt verfügbar sein, ohne die Zeitverzögerung durch die Portierung von SLE auf openSUSE.</p>
<p>Auch <a href="https://marix.org/opensuse-leap-151-mit-usb-stick-als-schlussel-fur-die-festplattenverschlusselung.html">meine Methode zum Booten mit Keystick</a> funktioniert mit der Beta von Leap 15.3 wunderbar.</p>
<p>Einen kleinen Stolperer gibt es momentan noch beim <a href="https://en.opensuse.org/SDB:System_upgrade#Running_the_Upgrade">Onlineupgrade</a> auf die Beta, zumindest wenn man bereits den Weg mit der Variablen <code>releasever</code> in den Quellen für die Paketpfade nimmt.
Nach dem Update <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1182951">zeigt <code>/etc/products.d/baseproduct</code> ins Leere</a>.
Das hat zur Folge, dass Zypper die Paketquellen nicht mehr findet:</p>
<pre><code>Warnung: Der Symlink /etc/products.d/baseproduct ist defekt oder fehlt!
Der Link muss auf die .prod-Datei Ihrer Kernprodukte in /etc/products.d verweisen.
</code></pre>
<p>Zum Glück lässt sich dies sehr leicht reparieren und bis zum finalen Release von 15.3 wird diese Problem auch gelöst sein.</p>
<pre><code>sudo rm /etc/products.d/baseproduct && sudo ln /etc/products.d/Leap.prod /etc/products.d/baseproduct
</code></pre>
<p>Auch wenn es momentan in 15.3 aus Nutzersicht keine Features gibt für die es dringend ein Update bräuchte, sollte, wer ein in irgendeiner Form ein ungewöhnliches Set-Up hat, der Beta also auf jeden Mal einen Versuch gönnen.
Denn so können Probleme idealerweise noch vor dem Release gefunden und behoben werden.
Dazu bietet sich natürlich eine Zweitinstallation an, auch wenn die Beta sogar schon stabil genug für die tägliche Nutzung erscheint.</p>openSUSE Leap 15.1 mit USB-Stick als Schlüssel für die Festplattenverschlüsselung2021-03-06T00:00:00+01:002023-06-10T00:00:00+02:00Matthias Bachtag:marix.org,2021-03-06:/opensuse-leap-151-mit-usb-stick-als-schlussel-fur-die-festplattenverschlusselung.html<p>Ich nutzte schon seit 2011 einen USB-Stick um bei meinem mit openSUSE laufenden Heimserver beim Start das Passwort für die Festplattenverschlüsselung „eingeben“ zu können ohne eine Tastatur oder einen Monitor am System angeschlossen zu haben.
Den dafür genutzten Mechanismus habe ich auch <a href="https://marix.org/usb-stick-als-schlüssel-für-die-festplattenverschlüsselung.html">schon damals hier im Blog dokumentiert</a>.
Leider funktionierte …</p><p>Ich nutzte schon seit 2011 einen USB-Stick um bei meinem mit openSUSE laufenden Heimserver beim Start das Passwort für die Festplattenverschlüsselung „eingeben“ zu können ohne eine Tastatur oder einen Monitor am System angeschlossen zu haben.
Den dafür genutzten Mechanismus habe ich auch <a href="https://marix.org/usb-stick-als-schlüssel-für-die-festplattenverschlüsselung.html">schon damals hier im Blog dokumentiert</a>.
Leider funktionierte der dort beschriebene Mechanismus aber seit openSUSE Leap 42.2 nicht mehr.
Auf den nachfolgenden Versionen gibt es aber einen neuen Mechanismus, der sogar noch besser funktioniert.
Dieser wird hier beschreiben und wurd auf allen Versionen von openSUSE Leap 42.2 bis 15.5 erfolgreich getestet.</p>
<h2 id="festplattenverschlusselung">Festplattenverschlüsselung</h2>
<p>Für die Festplattenverschlüsselung wird ganz klassisch LUKS genutzt, so wie auch openSUSE ein System mit Festplattenverschlüsselung aufsetzen würde.
Da der Schlüssel vom USB-Stick während des initialen Boots aus der Initrd gelesen wird muss <code>/boot</code> allerdings unverschlüsselt sein.
Moderne Versionen von openSUSE erlauben auch einen Boot mit verschlüsselter Boot-Partition.
In diesem Fall wird der Schlüssel aber bereits von Grub abgefragt.
Diese Variante wird vom hier beschriebenen Mechanismus nicht unterstützt.</p>
<p>Da LUKS die Nutzung mehrerer alternativer Schüssel unterstützt empfiehlt es sich das System zunächst mit einer klassischen Passphrase einzurichten.
Dies erleichtert Offline-Upgrades des Systems und das Einbinden der Festplatten zu Wiederherstellungs- und Wartungszwecken.</p>
<h2 id="usb-stick-als-schlussel">USB-Stick als Schlüssel</h2>
<p>Da der USB-Stick später aus der Initramfs gelesen werden soll, empfiehlt es sich ein dort sowieso eingebundenes Dateisystem zu nutzen.
Ich nutze hierfür immer noch Ext2.
Ist der Stick als <code>/dev/sdb</code> im System zu sehen, kann er wie folgt passend formatiert werden.</p>
<pre><code>mkfs.ext2 -L keystick /dev/sdb
</code></pre>
<p>Das Label <code>keystick</code> ist wichtig um den Schüssel später leicht referenzieren zu können.
Außerdem ist es beim Mount mit Label möglich eine zweite Kopie des Sticks zu erstellen falls das Original mal zerstört wird.</p>
<p>Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit <code>pwgen</code> gemacht werden:</p>
<pre><code>pwgen -s 1024 1 > /media/keystick/keyfile
</code></pre>
<p>Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.</p>
<pre><code>cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile
</code></pre>
<p>In diesem Beispiel befindet sich die verschlüsselte Partition auf <code>/dev/sda2</code>.</p>
<h2 id="usb-stick-beim-booten-nutzen">USB-Stick beim Booten nutzen</h2>
<p>Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter <code>rd.luks.key</code> auf die Schlüsseldatei zeigen.</p>
<pre><code>rd.luks.key=/keyfile:LABEL=keystick
</code></pre>
<p>Hier wird wieder das, bei der Formatierung des Sticks vergebene, Label für das Dateisystem genutzt.
Der Pfad ist relativ zum per Label referenzierten Dateisystem.
Konfigurieren lässt sich der Kernelparameter am einfachsten über die Bootloaderkonfiguration in Yast.</p>
<p>Damit der Parameter <code>rd.luks.key</code> funktioniert benötigt es allerdings noch eine Änderung.
In der Standardkonfiguration nutzt die Initrd bei openSUSE Systemd.
Dann hat der Parameter allerdings keinen Effekt.
Deshalb muss Dracut, welches in openSUSE die Initrd baut, so konfiguriert werden, dass es eine Initrd ohne Systemd baut.
Dazu ist eine neue Datei <code>/etc/dracut.conf.d/50-keystick.conf</code> mit folgendem Inhalt anzulegen:</p>
<pre><code>omit_dracutmodules+=" systemd "
</code></pre>
<p>Die Leerzeichen im Wert sind hier Absicht.
Ohne diese wirft Dracut eine Warnung:</p>
<pre><code>dracut: WARNING: <key>+=" <values> ": <values> should have surrounding white spaces!
dracut: WARNING: This will lead to unwanted side effects! Please fix the configuration file.
</code></pre>
<p>Ein anschließendes <code>mkinitrd</code> erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.</p>
<h2 id="vorteile-gegenuber-der-alten-methode">Vorteile gegenüber der alten Methode</h2>
<p><a href="https://marix.org/usb-stick-als-schlüssel-für-die-festplattenverschlüsselung.html">Bei der alten Methode</a> blieb das System in einer Schleife hängen wenn der USB-Stick beim Boot nicht gesteckt war.
Ohne Stick konnte das System gar nicht mehr gebootet werden.
Bei der hier beschriebenen Methode versucht das System zunächst die Schüsseldatei vom USB-Stick zu lesen.
Kann es diese aber nicht finden, so fällt es auf die klassische Passworteingabe zurück.
Wurde der USB-Stick also nicht als einziges Passwort eingerichtet lässt sich das System im Notfall auch noch so starten.</p>CD-ROMs von Klett unter Linux nutzen2021-01-04T00:00:00+01:002021-01-04T00:00:00+01:00Matthias Bachtag:marix.org,2021-01-04:/cd-roms-von-klett-unter-linux-nutzen.html<p>Der <a href="https://www.klett.de">Klett Verlag</a> bietet zu vielen seiner Lehrwerke auch Begleitmaterialien auf CD ROM an.
Die Anwendung auf diesen CDs öffnet tatsächlich nur HTML-Datei, so dass sich die CDs durch direktes Öffnen der Datei <code>index.html</code> Datei auch wunderbar auf nicht-Windows-Systemen nutzen ließen.
Häufig wird dann aber eine kaputte Seite dargestellt …</p><p>Der <a href="https://www.klett.de">Klett Verlag</a> bietet zu vielen seiner Lehrwerke auch Begleitmaterialien auf CD ROM an.
Die Anwendung auf diesen CDs öffnet tatsächlich nur HTML-Datei, so dass sich die CDs durch direktes Öffnen der Datei <code>index.html</code> Datei auch wunderbar auf nicht-Windows-Systemen nutzen ließen.
Häufig wird dann aber eine kaputte Seite dargestellt, und die Fehlerkonsole des Browsers beschwert sich über fehlende Dateien, z.B. für die Schriftarten.
Des Rätsels Lösung ist, dass diese Dateien auf der Ebene des Joliet-Dateisystems als versteckt markiert sind und für Anwendungen so normalerweise nicht sichtbar sind.
Unter Windows kümmert sich die Klett-Anwendung darum diese vor dem Öffnen der <code>index.hml</code> sichtbar zu schalten.</p>
<p>Mit dem Wissen darum, dass die Dateien auf Dateisystemebene versteckt sind, kann man die CDs auch unter Linux wunderbar nutzen.
Die Lösung findet sich dann beispielsweise <a href="https://askubuntu.com/questions/370906/unable-to-see-files-in-dvd-hidden-using-windows-7">auf askubuntu.com</a>: Die CD muss mit der Option <code>unhide</code> eingebunden werden.</p>
<p>Während normalerweise auch Nutzer CDs mounten können, muss dies in diesem Fall allerdings durch Root gemacht werden, da Nutzer keine Optionen beim Mounten angeben dürfen.
Auf meinem openSUSE-System führe ich also folgende Schritte aus:</p>
<pre><code>mkdir /tmp/klett
sudo mount -o unhide -t iso9660 /dev/sr0 /tmp/klett
</code></pre>
<p>Danach ist die CD mit allen Dateien in <code>/tmp/klett</code> verfügbar und ich kann z.B. mit einem <code>xdg-open /tmp/klett/index.html</code> den Inhalt öffnen.</p>
<p>Zur Erklärung der obigen Kommandozeile:</p>
<ul>
<li>Mit <code>mkdir /tmp/klett</code> lege ich ein temporäres Verzeichnis an. Es in <code>/tmp</code> anzulegen erspart es mir hinterher aufräumen zu müssen.</li>
<li><code>sudo</code> ist Notwendig, da ein normaler Nutzer keine Optionen angeben kann.</li>
<li><code>-o unhide</code> macht die normalerweise versteckten Dateien sichtbar.</li>
<li><code>-t iso9660</code> gibt explizit an welches Dateisystem verwendet wird. <code>mount</code> kann dies normalerweise auch automatisch erkennen.</li>
<li><code>/dev/sr0</code> ist mein optisches Laufwerk.</li>
</ul>Den Aktualisierungsstand von openSUSE mit Prometheus überwachen2020-06-21T00:00:00+02:002020-06-21T00:00:00+02:00Matthias Bachtag:marix.org,2020-06-21:/den-aktualisierungsstand-von-opensuse-mit-prometheus-uberwachen.html<p>Letzte Woche habe ich Version 0.2.1 des <a href="https://gitlab.com/Marix/zypper-patch-status-collector">Zypper-Patch-Status-Collectors</a> veröffentlicht.
Mit diesem kleinen, in Python geschriebenen, Helfer lässt sich der Aktualisierungsstand eines openSUSE-Systems durch Prometheus überwachen.
Prometheus kann so nicht nur Alarme generieren wenn Sicherheitsaktualisierungen noch nicht angewandt sind, sondern auch wenn einzelne Dienste nach Aktualisierungen noch nicht neu …</p><p>Letzte Woche habe ich Version 0.2.1 des <a href="https://gitlab.com/Marix/zypper-patch-status-collector">Zypper-Patch-Status-Collectors</a> veröffentlicht.
Mit diesem kleinen, in Python geschriebenen, Helfer lässt sich der Aktualisierungsstand eines openSUSE-Systems durch Prometheus überwachen.
Prometheus kann so nicht nur Alarme generieren wenn Sicherheitsaktualisierungen noch nicht angewandt sind, sondern auch wenn einzelne Dienste nach Aktualisierungen noch nicht neu gestartet wurden oder das System neu gestartet werden müsste.</p>
<p>Der Collector nutzt Zypper um nach ausstehen Patches und Service- oder Systemneustartbedarf zu schauen und gibt diese Information im Format von Prometheus-Metriken aus.
Dies sieht dann so aus wie in der README beschrieben:</p>
<pre><code># HELP zypper_applicable_patches The current count of applicable patches
# TYPE zypper_applicable_patches gauge
zypper_applicable_patches{category="security",severity="critical"} 0
zypper_applicable_patches{category="security",severity="important"} 2
zypper_applicable_patches{category="security",severity="moderate"} 0
zypper_applicable_patches{category="security",severity="low"} 0
zypper_applicable_patches{category="security",severity="unspecified"} 0
zypper_applicable_patches{category="recommended",severity="critical"} 0
zypper_applicable_patches{category="recommended",severity="important"} 0
zypper_applicable_patches{category="recommended",severity="moderate"} 0
zypper_applicable_patches{category="recommended",severity="low"} 0
zypper_applicable_patches{category="recommended",severity="unspecified"} 0
zypper_applicable_patches{category="optional",severity="critical"} 0
zypper_applicable_patches{category="optional",severity="important"} 0
zypper_applicable_patches{category="optional",severity="moderate"} 0
zypper_applicable_patches{category="optional",severity="low"} 0
zypper_applicable_patches{category="optional",severity="unspecified"} 0
zypper_applicable_patches{category="feature",severity="critical"} 0
zypper_applicable_patches{category="feature",severity="important"} 0
zypper_applicable_patches{category="feature",severity="moderate"} 0
zypper_applicable_patches{category="feature",severity="low"} 0
zypper_applicable_patches{category="feature",severity="unspecified"} 0
zypper_applicable_patches{category="document",severity="critical"} 0
zypper_applicable_patches{category="document",severity="important"} 0
zypper_applicable_patches{category="document",severity="moderate"} 0
zypper_applicable_patches{category="document",severity="low"} 0
zypper_applicable_patches{category="document",severity="unspecified"} 0
zypper_applicable_patches{category="yast",severity="critical"} 0
zypper_applicable_patches{category="yast",severity="important"} 0
zypper_applicable_patches{category="yast",severity="moderate"} 0
zypper_applicable_patches{category="yast",severity="low"} 0
zypper_applicable_patches{category="yast",severity="unspecified"} 0
# HELP zypper_service_needs_restart Set to 1 if service requires a restart due to using no-longer-existing libraries.
# TYPE zypper_service_needs_restart gauge
zypper_service_needs_restart{service="nscd"} 1
zypper_service_needs_restart{service="dbus"} 1
zypper_service_needs_restart{service="cups"} 1
zypper_service_needs_restart{service="sshd"} 1
zypper_service_needs_restart{service="cron"} 1
# HELP zypper_product_end_of_life Unix timestamp on when support for the product will end.
# TYPE zypper_product_end_of_life gauge
zypper_product_end_of_life{product="openSUSE"} 1606694400
zypper_product_end_of_life{product="openSUSE_Addon_NonOss"} 1000000000000001
# HELP zypper_needs_rebooting Whether the system requires a reboot as core libraries or services have been updated.
# TYPE zypper_needs_rebooting gauge
zypper_needs_rebooting 0
# HELP zypper_scrape_success Whether the last scrape for zypper data was successful.
# TYPE zypper_scrape_success gauge
zypper_scrape_success 1
</code></pre>
<p>In diesem Beispiel stehen zwei Sicherheitspatches aus und mehrere Services, unter anderem der SSH Daemon, bräuchten einen Neustart weil sie noch mit bereits gelöschten, also durch ein Update ersetzten, Bibliotheken arbeiten.</p>
<p>Durch Umleiten der Ausgabe in eine <code>prom</code> Datei ins Textfile-Collector-Verzeichnis des Node-Exporters von Prometheus kommen die Metriken dann ins Monitoring.
Wurde der Node-Exporter wie folgt aufgerufen:</p>
<pre><code>node_exporter --collector.textfile.directory /var/lib/node_exporter/collector
</code></pre>
<p>Dann lassen sie die Metriken wie folgt in Prometheus abladen:</p>
<pre><code>zypper-patch-status-collector > /var/lib/node_exporter/collector/zypper.prom
</code></pre>
<p>Stündlich per Systemd Timer aufgerufen hat Prometheus dann eine gute Übersicht über den Aktualisierungszustand der beobachteten openSUSE-Systeme.</p>
<p>Sind alle Metriken in Prometheus lassen sich dann auch verschiedene nützliche Alarme definieren.
Das folgende ist die Liste der auf dem Collector basierenden Alarme die ich momentan in meinem Alertmanager definiert habe:</p>
<pre><code>- alert: 'ZypperPatchesPending'
expr: 'sum(zypper_applicable_patches) by (instance) > 0'
for: '5m'
labels:
alert_severity: 'warning'
annotations:
summary: 'There are new patches available for {{ $labels.instance }}.'
description: 'Run `zypper patch --with-update` on {{ $labels.instance }}.'
- alert: 'ZypperCriticalPatchesPending'
expr: 'sum(zypper_applicable_patches{category="security"}) by (instance) + sum(zypper_applicable_patches{severity="critical"}) by (instance) > 0'
for: '5m'
labels:
alert_severity: 'page'
annotations:
summary: 'There are security patches pending on {{ $labels.instance }}.'
description: 'Run `zypper patch --with-update` on {{ $labels.instance }}.'
- alert: 'ZypperSuggestsServiceRestart'
expr: 'zypper_service_needs_restart'
for: '5m'
labels:
alert_severity: 'warning'
annotations:
summary: 'Zypper suggest to restart {{ $labels.service }} on {{ $labels.instance }}.'
description: 'Run `systemctl restart {{ $labels.service }}` on {{ $labels.instance }}.'
- alert: 'ZypperSuggestsReboot'
expr: 'zypper_needs_rebooting != 0'
for: '5m'
labels:
alert_severity: 'warning'
annotations:
summary: 'Zypper suggest to reboot {{ $labels.instance }}.'
description: 'Run `systemctl reboot` on {{ $labels.instance }}.'
- alert: 'ProductEndOfLifeNear'
expr: 'zypper_product_end_of_life < time() + 4 * 7 * 24 * 3600'
for: '5m'
labels:
alert_severity: 'warning'
annotations:
summary: '{{ $labels.product }} on {{ $labels.instance }} reaches end of life within four weeks.'
description: 'Upgrade {{ $labels.product }} on {{ $labels.instance }} to the next version.'
- alert: 'ProductEndOfLifeReached'
expr: 'zypper_product_end_of_life < time()'
for: '5m'
labels:
alert_severity: 'page'
annotations:
summary: '{{ $labels.product }} on {{ $labels.instance }} reached end of life.'
description: 'Upgrade {{ $labels.product }} on {{ $labels.instance }} to the next version.'
- alert: 'ZypperPatchDataOutdated'
expr: 'time() - node_textfile_mtime{file="zypper.prom"} > 24 * 3600'
for: '5m'
labels:
alert_severity: 'page'
annotations:
summary: 'Patch status has not been updated for 24 hours.'
description: |
The patch status of {{ $labels.instance }} has not been updated for 24 hours. Check the status of the timer and the service:
systemctl status zypper-patch-status-collector.timer
systemctl status zypper-patch-status-collector.service
- alert: 'ZypperScrapeFailed'
expr: 'zypper_scrape_success == 0'
for: '24h'
labels:
alert_severity: 'page'
annotations:
summary: 'Failed to successfully query patch status for 24 hours now.'
description: |
Querying zypper for the current patch status has not been successful for 24 hours. Check the status of the service:
systemctl status zypper-patch-status-collector.service
</code></pre>
<p>Die Installation des Collectors erfolgt am einfachsten über <a href="https://software.opensuse.org/package/python3-zypper-patch-status-collector">mein Community-Paket auf software.opensuse.org</a>.
Ich veröffentliche das Paket zwar auch <a href="https://pypi.org/project/zypper-patch-status-collector/">auf pypi.org</a>, aber ein Werkzeug mit Bezug zu Zypper am System vorbei zu installieren wäre dann doch etwas sehr verquer.</p>Der schusselige WLAN-Client2020-05-11T00:00:00+02:002020-05-11T00:00:00+02:00Matthias Bachtag:marix.org,2020-05-11:/der-schusselige-wlan-client.html<p>Das Lenovo Thinkpad E470 ist ein wunderbarer Laptop und openSUSE Leap funktioniert darauf hervorragend, wäre da nicht ein kleines Problem mit dem WLAN:
Der Laptop ist etwas schusselig was das Passwort für das WLAN angeht.
Immer wieder scheint er es zu vergessen und fragt per Dialog nach.
Scheinbar scheint er …</p><p>Das Lenovo Thinkpad E470 ist ein wunderbarer Laptop und openSUSE Leap funktioniert darauf hervorragend, wäre da nicht ein kleines Problem mit dem WLAN:
Der Laptop ist etwas schusselig was das Passwort für das WLAN angeht.
Immer wieder scheint er es zu vergessen und fragt per Dialog nach.
Scheinbar scheint er einen dann aber nicht zu verstehen, und fragt immer wieder.
Gibt man aber erst einmal auf, bricht den Verbindungsversuch ab und bittet ihn kurz darauf nochmal die Verbindung aufzubauen, so erinnert er sich plötzlich und verbindet sich ohne weitere Nachfragen.</p>
<p><img alt="KDE fragt per Dialog nach einem Passwort fürs WLAN" src="https://marix.org/Bilder/WLAN-Passwortabfrage.png"></p>
<p>Beim Versuch dem Problem auf den Grund zu gehen stellte ich schnell fest, dass es offensichtlich nicht am seit vielen Jahren immer wieder migrierten Nutzer liegt, denn das Problem tritt auch für einen neuen Nutzer auf.
Es ist aber auch nie zu hundert Prozent zuverlässig reproduzierbar, was die Fehlersuche zusätzlich erschwert.
So dachte ich zunächst, dass es eventuell mit der Initialisierung der Hardware zu hat, da es sehr häufig nach einem Neustart des Rechners auftauchte.
Auch trat das Problem eigentlich immer nur bei einem automatischen Verbindungsaufbau auf, also z.B. wenn das Netzwerk komplett deaktiviert wurde.
War die WLAN-Hardware hingegen ohne aufgebaute Verbindung aktiv und ich wählte das Netzwerk über das Netzwerkapplet von KDE aus, so verband sich der Rechner zuverlässig.
Allerdings habe ich das Problem aber nie nach einem Suspend beobachtet, was diese Theorie zumindest unwahrscheinlicher machte.</p>
<p><a href="https://lists.opensuse.org/opensuse/2020-04/msg00581.html">Eine Nachfrage auf der Mailingliste von openSUSE</a> brachte mich dann mit einem Verweis auf <a href="https://lists.opensuse.org/opensuse-de/2019-10/msg00099.html">eine Diskussion auf der deutschsprachigen Liste</a> auf die Lösung des Problems:
Anscheinend verursacht die <em>MAC address randomization</em> das Problem.
Seit jene abgeschaltet ist trat das Problem nicht mehr auf.</p>
<p>Ein einfacher weg die <em>MAC address randomization</em> abzuschalten findet sich auf <a href="https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314">https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314</a>.
Es ist lediglich die Datei <code>/etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf</code> mit folgendem Inhalt anzulegen:</p>
<pre><code>[connection]
wifi.mac-address-randomization=1
[device]
wifi.scan-rand-mac-address=no
</code></pre>
<p>Wieso dieses Vorgehen in einem Netzwerk ohne MAC-Adressen-Filter notwendig sein sollte ist mir zwar schleierhaft, aber solange es hilft…</p>
<p>Die randomisierten MAC-Adressen zu deaktivieren hat natürlich eine Auswirkung auf die Privatsphäre.
Da dieser Rechner aber ausschließlich zuhause oder bei öffentlichen Auftritten genutzt wird ist dies in diesem Fall verschmerzbar.</p>Alte Kernelversionen installiert behalten2019-08-16T00:00:00+02:002019-08-16T00:00:00+02:00Matthias Bachtag:marix.org,2019-08-16:/alte-kernelversionen-installiert-behalten.html<p>OpenSUSE behält in seiner Standardkonfiguration bei einer Aktualisierung des Kernels stets die letzte zuvor installierte Version.
Diese kann beim Systemstart über die erweiterten Startmodi ausgewählt werden.
Das hat den großen Vorteil, dass sollte der neue Kernel einen Fehler haben, man noch zu einem funktionierenden System zurückkehren kann.
Man kann also …</p><p>OpenSUSE behält in seiner Standardkonfiguration bei einer Aktualisierung des Kernels stets die letzte zuvor installierte Version.
Diese kann beim Systemstart über die erweiterten Startmodi ausgewählt werden.
Das hat den großen Vorteil, dass sollte der neue Kernel einen Fehler haben, man noch zu einem funktionierenden System zurückkehren kann.
Man kann also einfach mit dem alten Kernel weiterarbeiten und auf eine Behebung des Fehlers warten.</p>
<p>Doch was passiert bei der nächsten Aktualisierung?
Hier gibt es mehrere Optionen.
Löst die nächste Aktualisierung das Problem, kann man wieder auf den aktuellen Kernel wechseln und die alten Versionen können einem egal sein.
Ist das Problem mit der nächsten Aktualisierung nicht behoben gibt es zwei mögliche Fälle.
Im einfachen Fall startet das System mit dem neuen Kernel gar nicht.
In diesem Fall kann man weiterhin mit dem alten Kernel weiterarbeiten, denn das System behält stets den aktuell laufenden Kernel installiert
Solange neuere Kernel gar nicht starten können die alten Versionen somit auch nicht entfernt werden.
Spannender wird es, wenn der neue Kernel zwar startet, aber trotzdem nicht korrekt funktioniert.
So läuft womöglich der proprietäre Treiber von NVIDIA nicht oder ein Fehler im Kernel tritt nur in bestimmten Situationen auf.
In diesem Fall würde das System in der Standardkonfiguration nach dem, aus seiner Sicht erfolgreichen, Start den alten Kernel entfernen und nur die zwei defekten Kernel behalten.</p>
<p>Zum Glück lässt sich die Menge der aufbewahrten Kernel sehr flexibel Konfigurieren.
Die Konfiguration findet sich in der Datei <code>/etc/zypp/zypp.conf</code>
Entscheiden ist der Wert der Option <code>multiversion.kernels</code>.
Diese wird standardmäßig wie folgt gesetzt:</p>
<pre><code>multiversion.kernels = latest,latest-1,running
</code></pre>
<p>Damit werden die neuesten beiden und der aktuell laufende Kernel behalten.
Hier lassen sich aber auch explizite Versionen eintragen.
Damit sieht die Zeile dann wie folgt aus:</p>
<pre><code>multiversion.kernels = latest,latest-1,running,4.12.14-lp151.28.10.1
</code></pre>
<p>Wichtig ist, dass hier die Paketversion benötigt wird, nicht die vom Kernel bei einem <code>uname -a</code> ausgegebene Version.
Letzteres würde lautet für den im Beispiel benutzen Kernel folgendes ausgeben.</p>
<pre><code>Linux test 4.12.14-lp151.28.10-default #1 SMP Sat Jul 13 17:59:31 UTC 2019 (0ab03b7) x86_64 x86_64 x86_64 GNU/Linux
</code></pre>
<p>Die dazugehörige Paketversion lässt sich per <code>rpm</code> oder <code>zypper</code> abfragen:</p>
<pre><code>> rpm -qa kernel-default
kernel-default-4.12.14-lp151.28.10.1.x86_64
kernel-default-4.12.14-lp151.28.13.1.x86_64
> zypper search -s kernel-default
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository
---+----------------------+------------+-----------------------+--------+--------------------------------
i+ | kernel-default | Paket | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default | Paket | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default | Paket | 4.12.14-lp151.28.7.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default | Paket | 4.12.14-lp151.28.4.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default | Paket | 4.12.14-lp151.27.3 | x86_64 | Haupt-Repository (OSS)
| kernel-default | Quellpaket | 4.12.14-lp151.28.13.1 | noarch | Hauptaktualisierungs-Repository
| kernel-default | Quellpaket | 4.12.14-lp151.28.10.1 | noarch | Hauptaktualisierungs-Repository
| kernel-default | Quellpaket | 4.12.14-lp151.28.7.1 | noarch | Hauptaktualisierungs-Repository
| kernel-default | Quellpaket | 4.12.14-lp151.28.4.1 | noarch | Hauptaktualisierungs-Repository
| kernel-default-base | Paket | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
| kernel-default-base | Paket | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
| kernel-default-base | Paket | 4.12.14-lp151.28.7.1 | x86_64 | Hauptaktualisierungs-Repository
| kernel-default-base | Paket | 4.12.14-lp151.28.4.1 | x86_64 | Hauptaktualisierungs-Repository
| kernel-default-base | Paket | 4.12.14-lp151.27.3 | x86_64 | Haupt-Repository (OSS)
i+ | kernel-default-devel | Paket | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default-devel | Paket | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default-devel | Paket | 4.12.14-lp151.28.7.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default-devel | Paket | 4.12.14-lp151.28.4.1 | x86_64 | Hauptaktualisierungs-Repository
v | kernel-default-devel | Paket | 4.12.14-lp151.27.3 | x86_64 | Haupt-Repository (OSS)
</code></pre>
<p>Wie im Beispiel zu sehen ist, liefert <code>zypper</code> die einfacher zu lesende Ausgabe, <code>rpm</code> aber eine deutlich kompaktere.</p>
<p>Hat man so den funktionierenden Kernel vor dem automatischen Aufräumen geschützt, lässt es sich ganz entspannt auf eine reparierte Version warten.
Wurde der Fehler behoben, und spätestens nach dem nächsten Distributionsupgrade, sollte man allerdings die Konfiguration wieder zurücksetzen um nicht unnötig alte Kernel mit sich herumzuschleppen.
Denn diese benötigen nicht nur Platz, sie verlängern auch die Installationszeit mancher Updates.</p>
<p>Weitere Informationen zur Installation mehrerer Kernelversionen finden sich <a href="https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.tuning.multikernel.html#sec.tuning.multikernel.enable.keep">in der englischen Referenzdokumentation von openSUSE Leap</a>.</p>Automatisiertes Tippen von Passwörtern auf openSUSE2019-08-11T00:00:00+02:002019-08-11T00:00:00+02:00Matthias Bachtag:marix.org,2019-08-11:/automatisiertes-tippen-von-passwortern-auf-opensuse.html<p>Die Passwortverwaltung <a href="https://keepass.info/">KeePass</a> hat das äußerst praktische Feature <em>Auto-Type</em> um Anmeldeformulare in jeglicher Software, also nicht nur im Browser, per Knopfdruck ausfüllen zu können.
Damit spart man sich das manuelle Kopieren und Einfügen, was nicht nur komfortabler ist, sondern auch verhindert, dass das Passwort auf diesem Weg doch an einer …</p><p>Die Passwortverwaltung <a href="https://keepass.info/">KeePass</a> hat das äußerst praktische Feature <em>Auto-Type</em> um Anmeldeformulare in jeglicher Software, also nicht nur im Browser, per Knopfdruck ausfüllen zu können.
Damit spart man sich das manuelle Kopieren und Einfügen, was nicht nur komfortabler ist, sondern auch verhindert, dass das Passwort auf diesem Weg doch an einer falschen Stelle landet.
Leider funktionierte dies in openSUSE bisher nur, wenn man manuell das Paket <code>xdotool</code> nachinstalliert.
Ansonsten begrüßt folgende Fehlermeldung:</p>
<p><img alt="The 'xdotool' utility package is required for auto-type. Install this package and try again." src="https://marix.org/Bilder/KeePass-braucht-xdotool.png"></p>
<p>Die Fehlermeldung sagt dem Nutzer zwar bereits wie das Problem zu beheben ist, aber ich als Nutzer bevorzuge es eigentlich, wenn Dinge einfach funktionieren.
Von daher sollte die Installation des Paketes <code>keepass</code> eigentlich dafür sorgen, dass auch <code>xdotool</code> installiert wird.</p>
<p>Zum Glück hat openSUSE <a href="https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory">einen gut Dokumentierten Prozess um Korrekturen zu Paketen beizutragen</a>.
Das Paket zu reparieren ist also fast genau so schnell erledigt wie die fehlende Abhängigkeit zu installieren. Und als Bonus muss ich es auf dem nächsten System dann nicht wiederholen.</p>
<p><a href="https://build.opensuse.org/request/show/690171">Wie man an meinem Request sehen kann</a> habe ich <code>xdotool</code> übrigens nicht einfach als Abhängigkeit zu <code>keepass</code> hinzugefügt, denn KeePass funktioniert ja auch ohne <code>xdotool</code> fehlerfrei.
Stattdessen nutze ich den <a href="https://en.opensuse.org/openSUSE:Package_dependencies#Recommends">Vorschlagsmechanismus</a>, also <code>Recommends</code> statt <code>Depends</code>.
So bekommt ein normaler Nutzer das empfohlene Paket automatisch mitinstalliert.
Wer aber <code>--no-recommends</code> nutzt, um beispielsweise aus Sicherheitsgründen oder wegen beschränktem Platz auf der Systemfestplatte, nur die absolut notwendigen Pakete installieren möchte, bekommt weiterhin die gleiche minimale Installation wie bisher.</p>
<p>Leider habe ich meine Korrektur minimal zu spät beigetragen, als dass sie es noch in openSUSE Leap 15.1 geschafft hätte.
Von daher profitiert man bisher in in Tumbleweed davon.
Mit der nächsten Leap-Version können dann aber auch Leap-Nutzer ohne manuelle Nacharbeit <em>Auto-Type</em> nutzen.</p>openSUSE-Pakete für den Client und das Dateisystem von Keybase2018-11-12T00:00:00+01:002018-11-12T00:00:00+01:00Matthias Bachtag:marix.org,2018-11-12:/opensuse-pakete-fur-den-client-und-das-dateisystem-von-keybase.html<p><a href="https://keybase.io/">Keybase</a> gehört zu den Diensten, die zwar irgendwie wahnsinnig nützlich sind, denen der breite Erfolg bisher aber leider verwehrt wurde.
Das Kernfeature besteht darin, dass es einen Weg bietet eine verschlüsselte Kommunikation mit Personen aufzubauen von denen man nur einen Social-Media-Account kennt.
Durch das Verfahren, einen Beweis über die Eigentümerschaft …</p><p><a href="https://keybase.io/">Keybase</a> gehört zu den Diensten, die zwar irgendwie wahnsinnig nützlich sind, denen der breite Erfolg bisher aber leider verwehrt wurde.
Das Kernfeature besteht darin, dass es einen Weg bietet eine verschlüsselte Kommunikation mit Personen aufzubauen von denen man nur einen Social-Media-Account kennt.
Durch das Verfahren, einen Beweis über die Eigentümerschaft des Schlüssels im Social-Media-Account zu hinterlegen, kann man diesen, anders als Schlüsseln welche man von einem PGP-Keyserver erhalten hat, recht gut Vertrauen.
Leider bietet allerdings Keybase kein Installationspaket seiner Software für openSUSE an, so dass ich nun selber Pakete erstellt habe.</p>
<p>Die grundlegenden Funktionen von Keybase sind über <a href="https://keybase.io/docs/command_line">das Kommandozeilenwerkzeug <code>keybase</code></a> verfügbar.
Dieses wird vom Paket <code>keybase-client</code> bereitgestellt und lässt sich in Tumbleweed durch ein einfaches <code>sudo zypper install keybase-client</code> installieren.
Für Leap 15.0 ist das Paket leider nur als Versuchspaket verfügbar, welches sich am besten <a href="https://software.opensuse.org/package/keybase-client">per 1-Klick-Installation von software.opensuse.org installieren</a> lässt.</p>
<p>Außerdem bietet Keybase noch zwei weitere nützliche Funktionen.
Mit <a href="https://keybase.io/docs/kbfs">dem dazugehörigen Dateisystem</a> lassen sich Daten verschlüsselt und signiert mit anderen Nutzer tauschen.
Auch öffentlich lassen sich darüber Dateien anbieten.
Diese erscheinen dann unter <code>https://<nutzername>.keybase.pub</code>, und sind natürlich nicht verschlüsselt sondern nur signiert.
Hierfür wird das Paket <code>kbfs</code> benötigt.
Ist diese installiert, kann man per <code>systemctl --user start kbfs</code> das Dateisystem starten, welches dann unter <code>${XDG_RUNTIME_DIR}/keybase/kbfs</code> erscheint.</p>
<p>Die zweite nützliche Funktion ist es <a href="https://keybase.io/blog/encrypted-git-for-everyone">Git-Repositories verschlüsselt in Keybase abzulegen</a>.
Hierzu wird das Paket <code>kbfs-git</code> benötigt.
Sobald diese installiert ist, und das Dateisystem aktiv, kann Git auf Repositories welche das Protokoll <code>keybase</code> nutzen zugreifen.
Die Verwaltung erfolgt hierbei über das Kommando <code>keybase git</code>.</p>Dieser Rattenfänger befreit Mäuse2018-10-31T00:00:00+01:002018-10-31T00:00:00+01:00Matthias Bachtag:marix.org,2018-10-31:/dieser-rattenfanger-befreit-mause.html<p>Seit letzter Woche ist <a href="https://github.com/libratbag/piper">Piper</a> in <a href="https://www.opensuse.org/#Tumbleweed">openSUSE Tumbleweed</a> als Paket enthalten.
<a href="https://github.com/libratbag/piper">Piper</a> erlaubt es für eine ganze Reihe Spielermäuse diese auch unter Linux ganz genau so zu konfigurieren, wie es sonst die nur unter Windows verfügbaren Programme der Hersteller tun.</p>
<p><img alt="Ein Screenshot von Piper" src="https://marix.org/Bilder/Piper.png"></p>
<p>Bei meiner Logitech G502 kann ich mit Piper nicht nur …</p><p>Seit letzter Woche ist <a href="https://github.com/libratbag/piper">Piper</a> in <a href="https://www.opensuse.org/#Tumbleweed">openSUSE Tumbleweed</a> als Paket enthalten.
<a href="https://github.com/libratbag/piper">Piper</a> erlaubt es für eine ganze Reihe Spielermäuse diese auch unter Linux ganz genau so zu konfigurieren, wie es sonst die nur unter Windows verfügbaren Programme der Hersteller tun.</p>
<p><img alt="Ein Screenshot von Piper" src="https://marix.org/Bilder/Piper.png"></p>
<p>Bei meiner Logitech G502 kann ich mit Piper nicht nur grafisch zwischen den einzelnen Profilen wechseln, sonder ich kann auch für jedes Profil die Auflösungsstufen, die Tastenbelegung und die LEDs konfigurieren.</p>
<p>Zur Installation muss das Paket <code>piper</code> ausgewählt werden, entweder in der grafischen Paketverwaltung, per <a href="https://software.opensuse.org/package/piper">1-Klick-Installation auf software.opensuse.org</a> oder auf der Kommandozeile:</p>
<pre><code>sudo zypper install piper
</code></pre>
<p>In openSUSE Leap ist Piper aktuell leider nicht nutzbar.
Der darunterliegende Service Ratbagd hatte seine Sicherheitsbegutachtung beim Release von Leap 15.0 leider noch nicht abgeschlossen.
Mit der kommenden Version 15.1 sollte der Nutzung von Piper auf Leap dann aber auch nichts mehr im Wege stehen.</p>HTTP/2 im Apache auf openSUSE2018-10-23T00:00:00+02:002018-10-23T00:00:00+02:00Matthias Bachtag:marix.org,2018-10-23:/http2-im-apache-auf-opensuse.html<p>Nachdem es inzwischen keine Version von openSUSE mehr gibt in welcher der Apache zu alt ist um HTTP/2 zu unterstützen, gibt es eigentlich keine Ausrede mehr um dieses nicht einzusetzen.
Tatsächlich ist die Installation auf openSUSE auch schon hervorragend vorbereitet, man muss lediglich berücksichtigen, dass HTTP/2 nicht mit …</p><p>Nachdem es inzwischen keine Version von openSUSE mehr gibt in welcher der Apache zu alt ist um HTTP/2 zu unterstützen, gibt es eigentlich keine Ausrede mehr um dieses nicht einzusetzen.
Tatsächlich ist die Installation auf openSUSE auch schon hervorragend vorbereitet, man muss lediglich berücksichtigen, dass HTTP/2 nicht mit dem Multi-Processing-Module (MPM) <em>Worker</em> kompatibel ist, welches immer noch der Standard ist.</p>
<p>Um HTTP/2 zu aktivieren ist zunächst ein kompatibles MPM zu installieren.
Eine gute Wahl ist hierbei das MPM <em>Event</em>, welches unter openSUSE durch das Paket <code>apache2-event</code> bereitgestellt wird.</p>
<pre><code>sudo zypper install apache2-event
</code></pre>
<p>Alle notwendige Konfiguration kann anschließend in der Datei <code>/etc/sysconfig/apache2</code> vorgenommen werden:</p>
<ol>
<li>Das korrekte MPM auswählen: <code>APACHE_MPM=event</code>.</li>
<li>Das HTTP2-Module durch hinzufügen von <code>http2</code> zum Wert von <code>APACHE_MODULES</code> aktivieren.</li>
<li>Den Wert <code>HTTP2</code> zu <code>APACHE_SERVER_FLAGS</code> um die von openSUSE mitgelieferte Konfiguration für HTTP/2 zu aktivieren.</li>
</ol>
<p>Ab dem nächsten, per <code>systemctl restart apache2</code> durchführbaren, Neustart ist der Server dann per HTTP/2 zu erreichen.</p>
<p>Um für Browser per HTTP/2 nutzbar zu sein muss der Server übrigens TLS reden, da Firefox und Chrome HTTP/2 nur für sichere Verbindungen unterstützen.
Das sollte heutzutage aber sowieso der Standard sein.</p>GameMode2018-06-22T00:00:00+02:002018-10-14T00:00:00+02:00Matthias Bachtag:marix.org,2018-06-22:/gamemode.html<p>Beim Spielen möchte man am liebsten ungestört sein.
Deshalb bietet es sich häufig an so manches Program beim Starten eines Spieles zu schließen.
Auch weisen viele Spiele von Feral Interactive, z.B. F1 2017, weisen einen beim Start recht deutlich darauf hin, dass sie für die CPU eigentlich gerne den …</p><p>Beim Spielen möchte man am liebsten ungestört sein.
Deshalb bietet es sich häufig an so manches Program beim Starten eines Spieles zu schließen.
Auch weisen viele Spiele von Feral Interactive, z.B. F1 2017, weisen einen beim Start recht deutlich darauf hin, dass sie für die CPU eigentlich gerne den Performance-Modus aktiviert hätten.
Programme zu beenden und den Energiesparmodus zu wechseln, vor allem aber dies nach Ende der Spielesitzung alles wieder rückgängig zu machen, ist mühselig und steht dem spontanen Spielegenuß im Weg.
Hier hilft der von <a href="https://www.feralinteractive.com/de/">Feral Interactive</a> entwickelte <a href="https://github.com/FeralInteractive/gamemode">GameMode</a>.</p>
<p><a href="https://github.com/FeralInteractive/gamemode">GameMode</a> läuft als Prozess im Hintergrund und bietet eine einfache Funktion:
Über die dazugehörige Bibliothek können Spiele den Rechner in einen Spielemodus schalten.
Im Spielemodus wird die CPU in den Performance-Modus geschaltet.
Außerdem lassen sich beliebige weitere beim Start des Spielemodus auszuführende Aktionen definieren um beispielsweiße den Mail-Client für die dauer der Spielesitzung zu beenden.
Am Ende der Spielesitzung schaltet GameMode die CPU dann von alleine wieder in den balancierten Modus, so dass nicht weiter unnötig viel Energie verbraucht wird.</p>
<p>Da selbst Spiele von Feral Interactive noch nicht durchgängig GameMode unterstützen gibt es außerdem <em>libgamemodeauto</em>.
<em>Libgamemodeauto</em> kann per <code>LD_PRELOAD</code> mit einer Anwendung mitgeladen werden und sorgt dann automatisch für den Wechsel in den Spielemodus.
Installiert man <em>libgamemodeauto</em> über das openSUSE-Paket <code>libgamemodeauto0</code>, so findet es sich in <code>/usr/lib64/libgamemodeauto.so.0</code>.
Um es im Spiel <code>game</code> zu nutzen ist diese dann wie folgt zu starten:</p>
<pre><code>LD_PRELOAD=/usr/lib64/libgamemodeauto.so.0 game
</code></pre>
<p>Um Spiele per Steam mit <em>libgamemodeauto</em> zu starten ist in den Startoptionen des Spieles folgendes einzutragen:</p>
<pre><code>LD_PRELOAD=$LD_PRELOAD:/usr/lib64/libgamemodeauto.so.0 %command%
</code></pre>
<p>Diese Kommandozeilen finden sich auch in der Paketbeschreibung von <code>libgamemodeauto0</code>, welche sich per <code>zypper info libgamemodeauto0</code> anzeigen lässt.</p>
<p>Der einfachste Weg GameMode zu installieren ist <a href="https://software.opensuse.org/download.html?project=games%3Atools&package=libgamemodeauto">den Download oder die Anleitung von software.opensuse.org</a> zu nutzen.
In Tumbleweed reicht ein einfaches <code>zypper install ligbamemodeauto0</code>.
In Leap ist <em>libgameodeauto</em> leider noch nicht eingezogen, so dass zuvor das Repository <em>games:tools</em> hinzugefügt werden muss.</p>
<p>Zusätzliche Aktionen für den Start und das Ende des Spielemodus lassen sich in der Datei <code>~/.config/gamemode.ini</code> definieren.
Bei mir sieht diese so aus:</p>
<pre><code>[custom]
start=
cd && boinccmd --set_run_mode never
akonadictl stop
balooctl suspend
notify-send "GameMode started"
end=
notify-send "GameMode ended"
akonadictl start
balooctl resume
cd && boinccmd --set_run_mode auto
</code></pre>
<p>Mit <code>boinccmd</code> wird Boinc für die dauer der Spielesitzung angehalten.
Mit <code>akonadictl</code> halte ich effektiv mein Emailprogram an und mit <code>balooctl</code> schalte ich für die Dauer der Spielesitzung die Indizierung der Desktopsuche aus.
Nach Änderungen an der Konfigurationsdatei muss GameMode einmal beendet werden, am einfachsten über <code>killall gamemoded</code>.
Durch die nächste Anwendung, welche den GameMode nutzen möchte, wird der Prozess automatisch wieder gestartet, dann mit der neuen Konfiguration.</p>
<p>Für einfache Tests gibt es außerdem noch die Möglichkeit den Spielemodus mittels <code>gamemode -r</code> explizit zu aktivieren.
Beenden des Programmes per <code>Strg+C</code> deaktiviert den Spielemodus dann wieder.</p>Ein paar Tipps zum Aktualisieren von openSUSE2018-06-10T00:00:00+02:002018-06-10T00:00:00+02:00Matthias Bachtag:marix.org,2018-06-10:/ein-paar-tipps-zum-aktualisieren-von-opensuse.html<p>Seit dem 25. Mai 2018 ist <a href="https://en.opensuse.org/Portal:15.0" title="openSUSE Leap 15.0">openSUSE Leap 15.0</a> verfügbar.
Ein guter Grund mal ein paar Tipps zur Aktualiserung von openSUSE auf eine neue Version zu geben.
Da ich für gewöhnlich mithilfe des Installationsmediums aktualisiere beziehen sich meine Tipps primär auf diese Methode.
Aber gerade der Hinweis wie man …</p><p>Seit dem 25. Mai 2018 ist <a href="https://en.opensuse.org/Portal:15.0" title="openSUSE Leap 15.0">openSUSE Leap 15.0</a> verfügbar.
Ein guter Grund mal ein paar Tipps zur Aktualiserung von openSUSE auf eine neue Version zu geben.
Da ich für gewöhnlich mithilfe des Installationsmediums aktualisiere beziehen sich meine Tipps primär auf diese Methode.
Aber gerade der Hinweis wie man verwaiste Pakete findet ist natürlich auch nach einem sogenannten Live-Upgrade hilfreich.</p>
<p><a href="https://en.opensuse.org/Portal:15.0" title="openSUSE Leap 15.0"><img alt="openSUSE Leap 15.0 ist jetzt verfügbar" src="https://marix.org/Bilder/openSUSE-Leap-15.0-verfügbar.png"></a></p>
<h2 id="der-nvidia-treiber">Der NVIDIA-Treiber</h2>
<p>Meiner Erfahrung nach empfiehlt es sich den NVIDIA-Treiber vor dem Update zu deinstallieren.
Bei früheren Versionen von openSUSE habe ich es ansonsten schon erlebt, dass auch nach hinzufügen des NVIDIA-Repositories für die neue Version noch der alte Treiber installiert bleibt.
Dieser funktioniert dann allerdings nicht.
Linux, bzw. X.org, ist an dieser Stelle zwar hart im Nehmen und nutzt dann automatisch Nouveau, aber dieser kann dem proprietären Treiber von NVIDIA leider nicht annähernd das Wasser reichen.</p>
<p>Sollte das System bereits aktualisiert und Nouveau aktiv sein, so empfiehlt es sich den alten NVIDIA-Treiber mittels <code>zypper remove nvidia*</code> komplett zu deinstallieren und anschließen neu zu installieren.
Eine Neuinstallation mittels <code>zypper install --force</code> hat bei mir in der Vergangenheit meißtens nicht den gewünschten Erfolg gebracht.</p>
<h2 id="uefi">UEFI</h2>
<p>Bei einem System welches sowohl im EFI-Modus als auch im Bios-Kompatibilitätsmodus starten kann ist es wichtig das Upgrade im selben Modus zu starten welchen das alte System nutzt.
Bei openSUSE 42.2 endete ich dadurch, dass ich dies nicht getan habe, mit einem nicht bootfähigen System.
Allerdings gibt es im Zweifelsfall einen einfachen Ausweg.
Einfach auf dem bereits aktualisieren System das Update nochmal im richtigen Modus ausführen.
Da alle Pakete schon aktualisiert sind und nur noch der Bootcode korrekt installiert werden muss, geht dies dann auch recht schnell.</p>
<h2 id="repositories">Repositories</h2>
<p>Bei einem Update mithilfe des Installationsmediums werden alle zusätzlichen Repositories aus dem System entfernt.
Dies führt zu einem sauberen Update, kann aber zur Folge haben, dass man anschließend mühsam zusammensuchen muss woher man eine bestimmte Anwendung hatte.
Hierzu empfiehlt es sich vor der Aktualisierung einen Überblick zu verschaffen welche Pakete man aus dritten Quellen installiert hat.</p>
<h3 id="die-konfigurierten-repositories">Die konfigurierten Repositories</h3>
<p>Zypper kann einem mit <code>repos -u</code> die Liste der aktuell konfigurierten Repositories mit ihren URLs ausgeben.
So ist es, falls das Repository auch nach dem Update noch benötigt wird, möglich, durch einfaches Ersetzen der Versionsnummer in der URL, an das passende Repository der neuen Version zu kommen.
Auf meinem großen Rechner sieht dies dann zum Beispiel so aus:</p>
<pre><code>> zypper repos -u
Die Repository-Prioritäten sind ohne Effekt. Alle aktivierten Repositorys teilen sich die gleiche Priorität.
# | Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisierung | URI
---+---------------------------------+---------------------------------------------------------+-----------+-----------------+----------------+-------------------------------------------------------------------------------------
1 | code | Visual Studio Code | Ja | (r ) Ja | Ja | https://packages.microsoft.com/yumrepos/vscode
2 | download.nvidia.com-leap | nVidia Graphics Drivers | Ja | (r ) Ja | Ja | http://download.nvidia.com/opensuse/leap/42.3
3 | download.opensuse.org-non-oss | Haupt-Repository (NON-OSS) | Ja | (r ) Ja | Ja | http://download.opensuse.org/distribution/leap/42.3/repo/non-oss/
4 | download.opensuse.org-non-oss_1 | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/42.3/non-oss/
5 | download.opensuse.org-oss | Haupt-Repository (OSS) | Ja | (r ) Ja | Ja | http://download.opensuse.org/distribution/leap/42.3/repo/oss/
6 | download.opensuse.org-oss_1 | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/42.3/oss
7 | isv_ownCloud_desktop | The ownCloud Desktop Client (openSUSE_Leap_42.3) | Ja | (r ) Ja | Ja | http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/openSUSE_Leap_42.3/
8 | opensuse-guide.org-repo | Libdvdcss Repository | Ja | (r ) Ja | Ja | http://opensuse-guide.org/repo/openSUSE_Leap_42.3/
9 | packman.inode.at-suse | Packman Repository | Ja | (r ) Ja | Ja | http://packman.inode.at/suse/openSUSE_Leap_42.3/
10 | repo-debug | openSUSE-Leap-42.3-Debug | Nein | ---- | ---- | http://download.opensuse.org/debug/distribution/leap/42.3/repo/oss/
11 | repo-debug-non-oss | openSUSE-Leap-42.3-Debug-Non-Oss | Nein | ---- | ---- | http://download.opensuse.org/debug/distribution/leap/42.3/repo/non-oss/
12 | repo-debug-update | openSUSE-Leap-42.3-Update-Debug | Nein | ---- | ---- | http://download.opensuse.org/debug/update/leap/42.3/oss/
13 | repo-debug-update-non-oss | openSUSE-Leap-42.3-Update-Debug-Non-Oss | Nein | ---- | ---- | http://download.opensuse.org/debug/update/leap/42.3/non-oss/
14 | repo-source | openSUSE-Leap-42.3-Source | Nein | ---- | ---- | http://download.opensuse.org/source/distribution/leap/42.3/repo/oss/
15 | repo-source-non-oss | openSUSE-Leap-42.3-Source-Non-Oss | Nein | ---- | ---- | http://download.opensuse.org/source/distribution/leap/42.3/repo/non-oss/
</code></pre>
<h3 id="installierte-pakete-eines-repositories-anzeigen">Installierte Pakete eines Repositories anzeigen</h3>
<p>Fragt man sich wozu ein bestimmtes Repository im System ist kann man sich mit <code>zypper search --repo <repository-id> --installed-only</code> die aus einem bestimmten Repository installierten Pakete anzeigen lassen.
Am Beispiel des NVIDIA-Repositories sieht das bei mir dann so aus:</p>
<pre><code>> zypper search -r download.nvidia.com-leap -i
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Zusammenfassung | Typ
---+---------------------------+-----------------------------------------------------------------------+------
i+ | nvidia-computeG04 | NVIDIA driver for computing with GPGPU | Paket
i+ | nvidia-gfxG04-kmp-default | NVIDIA graphics driver kernel module for GeForce 400 series and newer | Paket
i+ | nvidia-glG04 | NVIDIA OpenGL libraries for OpenGL acceleration | Paket
i+ | x11-video-nvidiaG04 | NVIDIA graphics driver for GeForce 400 series and newer | Paket
</code></pre>
<h2 id="verwaiste-pakete-aufraumen">Verwaiste Pakete aufräumen</h2>
<p>Nach dem Update lohnt es sich häufig verwaiste Pakete zu entfernen.
Solche kann man mit einer Kombination von <code>zypper search</code> und <code>grep</code> leicht auffinden:</p>
<pre><code>> zypper search --details --installed-only --type package | grep Systempakete
i+ | Desurium | Paket | 0.8.0_rc10-3.1 | x86_64 | (Systempakete)
</code></pre>
<p>Möchte man ein Paket gerne behalten lohnt es sich mit <code>zypper search --details <Paketname></code> zu schauen ob es eine andere Version des Paketes in einem der konfigurierten Repsitories gibt.
Findet sich dort keine Version, so lohnt meißtens ein Besuch auf <a href="https://software.opensuse.org">https://software.opensuse.org</a>.</p>Grid Autosport auf openSUSE 42.32018-05-10T00:00:00+02:002018-05-10T00:00:00+02:00Matthias Bachtag:marix.org,2018-05-10:/grid-autosport-auf-opensuse-423.html<p><a href="http://www.gridgame.com">Grid Autosport</a> ist ein zwar älteres, aber immer noch exzellentes Rennspiel das zwar kein definitiv Arcaderacer ist, einen aber auch nicht mit einem Hardcoresimulationsanspruch erschlägt.
Ähnlich wie <a href="https://www.gran-turismo.com">Gran Tourismo</a> findet es einen exzellenten Mittelweg und ist, im Gegensatz zu diesem, auch auf Linux spielbar.
Es eignet sich somit also auch …</p><p><a href="http://www.gridgame.com">Grid Autosport</a> ist ein zwar älteres, aber immer noch exzellentes Rennspiel das zwar kein definitiv Arcaderacer ist, einen aber auch nicht mit einem Hardcoresimulationsanspruch erschlägt.
Ähnlich wie <a href="https://www.gran-turismo.com">Gran Tourismo</a> findet es einen exzellenten Mittelweg und ist, im Gegensatz zu diesem, auch auf Linux spielbar.
Es eignet sich somit also auch für ein kurzes Rennen in der Mittagspause, was nicht heißt, dass man keine Stunden darin versenken kann.
Leider lässt es sich unter openSUSE 42.3 aber nachdem man es per Steam heruntergeladen hat nicht direkt starten.</p>
<p><img alt="Der Startbildschirm von Grid Autosport auf openSUSE" src="https://marix.org/Bilder/Grid-Autosport-auf-openSUSE.png"></p>
<h2 id="das-problem">Das Problem</h2>
<p>Nach dem Start rödelt der rechner kurz, es kommt aber kein Spielfenster hoch.
Startet man Steam aus einer Konsole, so erscheint dort beim Versuch das Spiel zu starten folgendes:</p>
<pre><code>>>> Adding process 17089 for game ID 255220
>>> Adding process 17089 for game ID 255220Installing breakpad exception handler for appid(steam)/version(1506500000)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
>>> Adding process 17090 for game ID 255220
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: relocation error: /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4: symbol ENGINE_load_builtin_engines, version OPENSSL_1.0.0 not defined in file libcrypto.so.1.0.0 with link time reference
Game removed: AppID 255220 "GRID Autosport", ProcID 17086
</code></pre>
<p>Hier liegt also eine Inkompatibilität zwischen der vom Spiel mitgebrachten Curl-Bibliothek und den von Steam mitgebrachten Bibliotheken SSL und Crypto vor.</p>
<h2 id="die-losung-aus-dem-netz">Die Lösung aus dem Netz</h2>
<p>Beim Googeln findet sich schnell <a href="https://forums.opensuse.org/showthread.php/520922-Steam-libcrypto-error">eine Lösung welche vorschlägt <code>libcrypto.so.1.0.0</code> aus der Steam-Runtime entfernen</a>.
Dies löst auch das Problem mit Grid Autosport.
Allerdings hat diese Lösung auch Nachteile.
Da die Steam-Runtime modifiziert wird ist damit zu rechnen, dass das nächste Steam-Update die Dateien wiederherstellt und man die Datei erneut entfernen muss.
Außerdem kann es damit zu Problemen in anderen Spielen kommen welche sich auf die von Steam mitgelieferte Version verlasen.</p>
<h2 id="die-bessere-losung">Die bessere Lösung</h2>
<p>Die obige Lösung weißt aber bereits den Weg zu einer besseren Lösung, denn sie funktioniert deshalb, weil openSUSE bereits kompatible Versionen der beiden Bibliotheken enthält.
Tatsächlich betrifft dieses Problem einige Spiele welche von <a href="https://www.feralinteractive.com">Feral Interactive</a> portiert wurden.
So ist auch <a href="https://www.dirtgame.com">Dirt Rally</a> von diesem Problem betroffen.
Für dieses Spiel findet sich <a href="https://forums.opensuse.org/showthread.php/524557-Can-t-run-Dirt-Rally-on-Steam">eine Lösung</a> welche sich Analog auch auf Grid Autosport anwenden lässt:</p>
<ol>
<li>Ins Spielverzeichnis wechseln: <code>cd <steam library>/steamapps/common/Grid\ Autosport/lib/x86_64</code>.</li>
<li>Dort auf die libcrypto des Systems linken:<pre><code>> ln -s /lib64/libcrypto.so.1.0.0
> ln -s /lib64/libssl.so.1.0.0
</code></pre>
</li>
</ol>
<p>Diese Lösung ist besser, weil sie nur das einzelne Spiel betrifft und nicht global die Steam-Runtime beschädigt.
Sie hat allerdings den Nachteil, dass sie kaputt gehen kann falls Steam mal die Dateien anfasst, z.B. bei einem Update.
Updates von Grid Autosport sind aber deutlich seltener als solche von Steam selbst, und auf meinem System hat der Fix auch schon einige Patches überlebt.</p>Zwei neue Pakete für openSUSE2018-04-25T00:00:00+02:002018-04-25T00:00:00+02:00Matthias Bachtag:marix.org,2018-04-25:/zwei-neue-pakete-fur-opensuse.html<p><a href="https://www.opensuse.org/#Tumbleweed">openSUSE Tumbleweed</a> enthält jetzt zwei neue Pakete welche ich erstellt habe: <a href="https://software.opensuse.org/package/python-emoji" title="Emojis für Python">python-emoji</a> und <a href="https://software.opensuse.org/package/python-ntfy" title="Pushnachrichten für die Konsole">python-ntfy</a>.
Ersteres hat es sogar noch in <a href="https://www.opensuse.org/#Leap">openSUSE Leap 15.0</a> geschafft.</p>
<p>Die Funktionalität von <a href="https://software.opensuse.org/package/python-emoji" title="Emojis für Python">python-emoji</a> ist schnell erklärt und trotzdem unglaublich nützlich, wie diese leichte Abwandlung des Beispiels aus <a href="https://pypi.org/project/emoji/">der Paketbeschreibung auf PyPI</a> zeigt:</p>
<pre><code>>> import emoji …</code></pre><p><a href="https://www.opensuse.org/#Tumbleweed">openSUSE Tumbleweed</a> enthält jetzt zwei neue Pakete welche ich erstellt habe: <a href="https://software.opensuse.org/package/python-emoji" title="Emojis für Python">python-emoji</a> und <a href="https://software.opensuse.org/package/python-ntfy" title="Pushnachrichten für die Konsole">python-ntfy</a>.
Ersteres hat es sogar noch in <a href="https://www.opensuse.org/#Leap">openSUSE Leap 15.0</a> geschafft.</p>
<p>Die Funktionalität von <a href="https://software.opensuse.org/package/python-emoji" title="Emojis für Python">python-emoji</a> ist schnell erklärt und trotzdem unglaublich nützlich, wie diese leichte Abwandlung des Beispiels aus <a href="https://pypi.org/project/emoji/">der Paketbeschreibung auf PyPI</a> zeigt:</p>
<pre><code>>> import emoji
>> print(emoji.emojize('Python ist :thumbs_up:'))
Python ist 👍
</code></pre>
<p>Natürlich funktioniert dies sowohl in <a href="https://docs.python.org/3/">modernem Python</a> als auch in <a href="https://docs.python.org/2/">klassischem Python</a>.</p>
<p>Eines der Pakete welche von <a href="https://software.opensuse.org/package/python-emoji" title="Emojis für Python">python-emoji</a> profitieren ist <a href="https://software.opensuse.org/package/python-ntfy" title="Pushnachrichten für die Konsole">python-ntfy</a>.
<a href="https://software.opensuse.org/package/python-ntfy" title="Pushnachrichten für die Konsole">python-ntfy</a> ermöglichte es aus der Konsole Benachritigungen zu verschicken.
Diese können entweder auf der Arbeitsfläche angezeigt werden, oder über verschiedene Backends an ein Smartphone weitergeleitet werden.
Allerdings sind momentan noch nicht Backends auch für openSUSE paketiert.
Besonders praktisch ist der Befehl <code>ntfy done</code>.
Nutzt man diesen um einen lange laufenden Prozess zu starten, so bekommt man, sobald dieser fertig ist, eine Nachricht welche auch über Erfolg oder Misserfolg und die Laufzeit des Prozesses informiert.
Man kann sich also ganz gemütlich in die Hängematte legen während der Rechner ackert. 😉</p>openSUSE Leap 42.3 auf dem Raspberry Pi 2 ohne Monitor nutzen2018-01-02T00:00:00+01:002018-01-02T00:00:00+01:00Matthias Bachtag:marix.org,2018-01-02:/opensuse-leap-423-ohne-monitor-auf-dem-raspberry-pi-2.html<p>Der Raspberry Pi 2 ist ein praktischer kleiner Rechner, und das dafür vorgesehene Raspbian auch eine gut gemachte Linux-Distribution.
Hat man allerdings schon auf mehreren Rechner openSUSE im Einsatz ist es viel attraktiver dieses auch dort zu verwenden, zumal dies völlig problemlos möglich ist.
Der Einsatz von Tumbleweed auf dem …</p><p>Der Raspberry Pi 2 ist ein praktischer kleiner Rechner, und das dafür vorgesehene Raspbian auch eine gut gemachte Linux-Distribution.
Hat man allerdings schon auf mehreren Rechner openSUSE im Einsatz ist es viel attraktiver dieses auch dort zu verwenden, zumal dies völlig problemlos möglich ist.
Der Einsatz von Tumbleweed auf dem Raspberry Pi 2 ist <a href="https://en.opensuse.org/HCL:Raspberry_Pi2" title="Raspbarry PI2 documentation on the openSUSE Wiki">im Wiki von openSUSE</a> detailliert dokumentiert.
Mit wenigen kleinen Änderungen lässt sich so auch <a href="https://www.opensuse.org/#Leap">openSUSE Leap</a> auf dem Raspberry Pi 2 nutzen, und zwar ohne an diesen Monitor oder Maus anschließen zu müssen.</p>
<p>Die Installation eines Betriebssystem auf dem Raspberry PI erfolgt stets dadurch den passenden Installer auf seine SD-Karte zu kopieren.
Beim ersten Start wird diese dann passend eingerichtet.
Die passende Datei für openSUSE Leap 42.3 findet sich auf <a href="http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/">http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/</a>.
Für den Betrieb ohne Tastatur und Monitor bietet sich die Variante <em>Just enough OS (JeOS)</em> an.
Damit findet man die passende Datei indem man <a href="http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/">die Downloadseite</a> nach <code>JeOS-raspberrypi2</code> durchsucht.
Aktuell ist dies <a href="http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz">http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz</a>.
Es empfiehlt sich auch <a href="http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz.sha256">die Prüfsumme</a> zu checken.</p>
<pre><code>> sha256sum -c openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz: OK
sha256sum: WARNUNG: 14 Zeilen sind nicht korrekt formatiert
</code></pre>
<p>Die Warnung zu den nicht formatierten Zeilen liegt daran, dass der Inhalt mit PGP signiert ist.
Die Signatur lässt sich mit <a href="https://gnupg.org/">GPG</a> prüfen.</p>
<pre><code>> gpg --verify openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
gpg: Signatur vom Mi 26 Jul 2017 19:39:17 CEST mittels RSA-Schlüssel ID 3DBDC284
gpg: Korrekte Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [vollständig]
note: random_seed file not updated
</code></pre>
<p>Jetzt wo klar ist, dass das Image nicht beschädigt ist, kann man <a href="https://en.opensuse.org/HCL:Raspberry_Pi2" title="Raspbarry PI2 documentation on the openSUSE Wiki">der Anleitung für Tumbleweed im openSUSE-Wiki</a> folgen.</p>
<p>Achtung! Das Schreiben auf die SD-Karte kann, wenn man den falschen Gerätebezeichner erwischt, Daten auf einer anderen Platte zerstören.
Wenn man sich nicht 100% sicher ist welchen Gerätebezeichner die SD-Karte hat, dann kann man direkt nach dem Einstecken in <code>dmesg</code> nachsehen, welchen Bezeichner die Karte bekommen hat.
In meinem Beispiel hat der Kartenleser mehrere Einschübe, so dass gleich mehrere Geräte auftauchen, aber nur für das Gerät mit der SD-Karte wird die Kapazität (<code>sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)</code>) und die Partitionsliste (<code>sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3</code>) ausgegeben.</p>
<pre><code>> dmesg | tail -n 30
[13801.698740] EXT4-fs error (device sdi6): htree_dirblock_to_tree:986: inode #2: block 8582: comm dolphin: bad entry in directory: directory entry across range - offset=0(0), inode=4489218, rec_len=32780, name_len=129
[13814.445903] sdi: detected capacity change from 8026849280 to 0
[13897.279227] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[13897.285959] sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[14939.444590] usb 2-6: USB disconnect, device number 2
[37767.485975] usb 2-6: new SuperSpeed USB device number 3 using xhci_hcd
[37767.532474] usb 2-6: New USB device found, idVendor=8564, idProduct=4000
[37767.532478] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37767.532479] usb 2-6: Product: USB3.0 Card Reader
[37767.532479] usb 2-6: Manufacturer: Realtek
[37767.532480] usb 2-6: SerialNumber: 201412031053
[37767.539943] usb-storage 2-6:1.0: USB Mass Storage device detected
[37767.546235] scsi host8: usb-storage 2-6:1.0
[37768.558079] scsi 8:0:0:0: Direct-Access Generic- USB3.0 CRW -0 1.00 PQ: 0 ANSI: 6
[37768.558355] sd 8:0:0:0: Attached scsi generic sg6 type 0
[37768.569622] scsi 8:0:0:1: Direct-Access Generic- USB3.0 CRW -1 1.00 PQ: 0 ANSI: 6
[37768.569862] sd 8:0:0:1: Attached scsi generic sg7 type 0
[37768.582535] scsi 8:0:0:2: Direct-Access Generic- USB3.0 CRW -2 1.00 PQ: 0 ANSI: 6
[37768.582758] sd 8:0:0:2: Attached scsi generic sg8 type 0
[37768.601427] scsi 8:0:0:3: Direct-Access Generic- USB3.0 CRW -3 1.00 PQ: 0 ANSI: 6
[37768.601678] sd 8:0:0:3: Attached scsi generic sg9 type 0
[37769.473299] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[37769.473958] sd 8:0:0:0: [sdf] Attached SCSI removable disk
[37769.475113] sd 8:0:0:3: [sdi] Write Protect is off
[37769.475116] sd 8:0:0:3: [sdi] Mode Sense: 2f 00 00 00
[37769.475608] sd 8:0:0:1: [sdg] Attached SCSI removable disk
[37769.477768] sd 8:0:0:3: [sdi] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[37769.478227] sd 8:0:0:2: [sdh] Attached SCSI removable disk
[37769.484922] sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[37769.488248] sd 8:0:0:3: [sdi] Attached SCSI removable disk
</code></pre>
<p>Um das Image auf die Karte zu schreiben benötigt man Root-Rechte.
Das Gerät muss von <code>/dev/sdX</code> auf den korrekten Bezeichner angepasst werden.
Für obiges Beispiel <code>/dev/sdi</code>.</p>
<pre><code>> sudo -s
# xzcat openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct
328+1 records in
328+1 records out
1377828864 bytes (1.4 GB, 1.3 GiB) copied, 147.571 s, 9.3 MB/s
# sync
</code></pre>
<p>Hierbei passiert folgendes:</p>
<ol>
<li><code>xzcat</code> entpackt das Image auf die Standardausgabe.</li>
<li><code>dd</code> übernimmt über die Standardeingabe das entpackte Image und schreibt es 1:1 auf das angegebene Gerät, und zwar ohne zu Puffern.</li>
<li><code>sync</code> stellt sicher, dass alle Daten auch wirklich geschrieben wurden und die Karte sicher entnommen werden kann.</li>
</ol>
<p>Anschließend kann man den Raspberry Pi 2 mit den üblichen Schritten in Betrieb nehmen:</p>
<ol>
<li>Karte herausnehmen und in den Pi stecken,</li>
<li>Netzwerk an den Raspberry Pi 2 anschließen,</li>
<li>und dann Strom auf Pi geben.</li>
</ol>
<p>Der initiale Start kann einige Zeit dauern.
Bei mir waren dies gut anderthalb Stunden, mit einer schnelleren SD-Karte kann man hier aber Zeit sparen.</p>
<p>Hat man keinen Monitor am Raspberry Pi 2, so steht man nun vor der Herausforderung dessen Netzwerkadresse herauszufinden um sich mit dem zu verbinden.
Prinzipiell kann man diese herausfinden indem man nach dem letzten Gerät schaut, dass sich am Router angemeldet hat.
Löst der Router auch die von den Rechnern selbst gewählten Namen auf, so ist es sogar noch einfacher, da sich ein frisches openSUSE immer mit dem Rechnernamen <code>linux</code> meldet.
An einer Fritz!Box ist er deshalb als <code>linux.fritz.box</code> erreichbar.</p>
<p>Nun kann man sich also das erste mal anmelden. Der Nutzer ist <code>root</code> und das Passwort <code>linux</code>.
Hat man eine Fritz!Box also: <code>ssh root@linux.fritz.box</code>.
Beim ersten Anmelden sollte man gleich noch die Inbetriebnahme das Basissystems abschließen:</p>
<ul>
<li>Das Passwort ändern,</li>
<li>dem eigenen SSH-Key per <code>ssh-copy-id</code> auf dem Raspberry Pi Berechtigung zum Anmelden geben,</li>
<li>Updates einspielen,</li>
<li>und den Hostnamen ändern.</li>
</ul>
<p>Letzterer Schritt ist wichtig, da es sonst bei Inbetriebnahme eines weiteren Raspberry Pi zu kollisionen kommen kann und man sich unnötig die Auflösung der Netzwerkadresse des neuen Systems erschwert.</p>
<p>Das <em>Just enough</em> in <em>JeOS</em> ist übrigens durchaus ernst gemeint.
Wer sein System anschließend mit Ansible weiter einrichten möchte sollte dort noch Python komplett installieren: <code>zypper in python3</code>.
Ohne diesen Schritt kann es zu kuriosen Fehlermeldungen kommen, da Teile der Standardbibliothek in der minimalen Installation von Python fehlen.</p>Wenn das System zu gut aufräumt2017-09-04T22:30:00+02:002017-09-06T21:00:00+02:00Matthias Bachtag:marix.org,2017-09-04:/wenn-das-system-zu-gut-aufraumt.html<p>Eigentlich ist es ja gewünscht wenn das System einem regelmäßig die temporären Dateien wegräumt. Löscht es einem dabei aber auch Dateien welche man gerade erst dort abgelegt hatte, dann steht wohl irgendwas in der Konfiguration schief.</p><p>Eigentlich ist es ja gewünscht wenn das System einem regelmäßig die temporären Dateien wegräumt.
Löscht es einem dabei aber auch Dateien welche man gerade erst dort abgelegt hatte, dann steht wohl irgendwas in der Konfiguration schief.</p>
<p>Ich nutze tatsächlich häufig das Verzeichnis <code>/tmp</code>.
Gerade beim Schreiben kleiner Skripte ist es ganz angenehm sich im Fehlerfall einfach darauf zu verlassen, dass übrig gebliebene temporäre Dateien schon wieder verschwinden werden.
Auch meine <a href="https://docs.python.org/3/library/venv.html">virtuellen Python-Umgebungen</a> lege ich, seit mich <a href="https://www.holger-peters.de/">Holger Peters</a> mal auf diese Idee gebracht hat, stets dort ab.
Seit einiger Zeit löschte mir meine <a href="https://www.opensuse.org/">openSUSE</a> meine gerade angelegten Dateien aber immer kurz nach dem Systemstart unter der Nase weg.</p>
<p>Da das Problem immer kurz nach dem Systemstart auftrat war schnell klar, dass da wohl der Aufräumcronjob schuld sein muss.
Auch wenn dies natürlich inzwischen gar kein Cronjob mehr ist sondern ein <a href="https://www.freedesktop.org/software/systemd/man/systemd.timer.html">Systemd-Timer</a>.</p>
<pre><code>marix@eddie:~> systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Di 2017-09-05 21:10:12 CEST 22h left Mo 2017-09-04 21:10:12 CEST 1h 9min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv
Mo 2017-09-11 00:00:00 CEST 6 days left Mo 2017-09-04 20:55:51 CEST 1h 23min ago fstrim.timer fstrim.service
</code></pre>
<p>Der alte Cronjob hatte eine Konfigurationsdatei in <code>/etc/sysconfig</code> in der man die Schonzeit für Dateien in <code>/tmp</code> und <code>/var/tmp</code> konfigurieren konnte.
Beim Systemd-Job übernehmen die Konfigurationsdateien von <code>systemd-tmpfiles</code> diesen Job.
Die dazugehörige Manpage ist <a href="https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html"><code>tmpfiles.d (5)</code></a>.</p>
<p>Die Standardatei <code>/usr/lib/tmpfiles.d/tmp.conf</code> erklärt auch ganz brav diese Verzeichnisse in Ruhe zu lassen.
Das ist zwar nicht ganz was ich möchte, aber auch nicht Grund meines Problemes.</p>
<pre><code># Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
q /tmp 1777 root root -
q /var/tmp 1777 root root -
</code></pre>
<p>Die schuldige Konfiguration fand sich in <code>/etc/tmpfiles.d/tmp.conf</code>.
Hier muss, bei einem der vielen Versionsupgrades welche mein System hinter sich hat, ein kleiner Übertragungsfehler passiert sein.</p>
<pre><code>d /tmp 1777 root root 0d
d /var/tmp 1777 root root -
x /tmp/* - - - - root
</code></pre>
<p>Mit dem Alter Null Tage wird <code>systemd-tmpfiles</code> angewiesen alle Dateien zu löschen, egal wann sie zuletzt modifiziert wurden.
Auch wenn dies die meißten Anwendungen in meinem System klaglos hinnahmen sorgte es natürlich für einiges WTF was meine eigenen Skripte und die die virtuellen Python-Umgebungen anging.
Die korrektur des Wertes auf einen Tag hat mein Problem erfolgreich gelöst.</p>
<pre><code>d /tmp 1777 root root 1d
d /var/tmp 1777 root root -
x /tmp/* - - - - root
</code></pre>
<p>Und das schöne an Systemd ist, dass man so eine Änderung dann auch gleich sehr leicht testen kann.</p>
<pre><code>sudo systemctl start systemd-tmpfiles-clean.service
</code></pre>
<p>Eine Anwendung welche mit dem agressiven Aufräumen der temporären Dateien gar nicht klar kommt ist übrigens meine früher so geliebter Browser <a href="https://www.opera.com/de">Opera</a>.
Nachdem die temporären Dateien weggräumt wurden findet dieser seine bereits laufende Instanz nicht mehr und fliegt dann beim Versuch ein zweites mal das gleiche Profil zu öffnen ordendlich auf die Fresse.
Dies hat mich hinreichend genervt, so dass ich kürzlich zum <a href="https://www.mozilla.org/de/firefox/new/">Firefox</a> gewechselt bin.
Seit ich kurz darauf die hier beschriebene Fehlkonfiguration behoben habe funktioniert aber auch der, inzwischen von mir nicht mehr wirklich genutzte, Opera wieder tadellos.</p>openSUSE Leap 42.2 auf antiker Hardware2016-12-19T21:24:15+01:002016-12-19T21:24:15+01:00Matthias Bachtag:marix.org,2016-12-19:/opensuse-leap-422-auf-antiker-hardware.html
<p>Bei uns ist immer noch ein, inzwischen vermutlich als antik geltender, ASUS-Laptop mit einem Core2 Duo und 3 GiB RAM im Einsatz, bisher mit openSUSE 13.1. Angesichts <a href="https://en.opensuse.org/Lifetime">dessen Supportendes,</a> war aber ein update nötig. Und da auch das damals vorinstallierte Windows Vista sein Lebensende erreicht hatte, und seit mehreren …</p>
<p>Bei uns ist immer noch ein, inzwischen vermutlich als antik geltender, ASUS-Laptop mit einem Core2 Duo und 3 GiB RAM im Einsatz, bisher mit openSUSE 13.1. Angesichts <a href="https://en.opensuse.org/Lifetime">dessen Supportendes,</a> war aber ein update nötig. Und da auch das damals vorinstallierte Windows Vista sein Lebensende erreicht hatte, und seit mehreren Jahren nicht mehr genutzt war, führte ich eine Neuinstallation mit <a href="https://en.opensuse.org/Portal:42.2">openSUSE Leap 42.2</a> durch. Wie bei jeder Rechnerneuinstallation stolperte ich dabei über ein paar Eigenarten, aber insgesamt läuft das System wunderbar.</p>
<p>Insgesamt fühlt sich das System flotter an als vorher. Der Hauptgrund dafür ist wohl, dass das System recht sparsam mit dem Hauptspeicher umgeht. So nutzt es wenn man die üblichen Anwendungen, wie KMail und ownCloud, im Hintegrund hat und dann noch DM Fotowelt, ein mittelgroßes Open-Office-Dokument mit Fotos und Firefox mit einer zweistelligen Anzahl Tabs offen hat nur run 2 GiB seines Hauptspeichers. So kommt das System dann trotz vollverschüsselter Festplatte und ohne SSD auf nutzbare Geschwindigkeit.</p>
<p>Ein Wermutstropfen ist, dass ich die in KDE eingebaute Volltextsuche abschalten musste. Obwohl das System bei Installation und während des Zurückkopierens aller Dateien auch über Nacht stabil lief, war damit Schluss sobald die Volltextsuche anfing die Dateien zu indizieren. Nach fünf bis zehn Minuten war der Rechner komplett eingefroren. Auch ein SSH auf den Rechner war nicht mehr möglich.</p>
<p>Ein weiterer interessanter Bug ist, dass die Plugins von Parley nicht funktionieren. Diese haben in der Shebang kf5kross als Interpreter angegeben, allerdings wird dieses nicht installiert.</p>
Kein CUDA nach dem Update auf openSUSE Leap 42.12016-04-15T22:41:40+02:002017-08-05T21:31:00+02:00Matthias Bachtag:marix.org,2016-04-15:/kein-cuda-nach-dem-update-auf-opensuse-leap-421.html
<p>Nachdem ich meine Workstation <a href="https://marix.org/Blog/opensuse-131-mit-uefi-und-vollverschlüsselung-auf-opensuse-leap-421-migrieren.html">von openSUSE 13.1 auf openSUSE Leap 42.1 migriert</a> hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem.</p>
<p><h2>Das Problem</h2></p>
<p>Nach dem Update fanden CUDA nutzende …</p>
<p>Nachdem ich meine Workstation <a href="https://marix.org/Blog/opensuse-131-mit-uefi-und-vollverschlüsselung-auf-opensuse-leap-421-migrieren.html">von openSUSE 13.1 auf openSUSE Leap 42.1 migriert</a> hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem.</p>
<p><h2>Das Problem</h2></p>
<p>Nach dem Update fanden CUDA nutzende Anwendungen keine Grafikkarte. So meldete <a href="https://boinc.berkeley.edu">Boinc</a> <code>No usable GPUs found</code>. Prinzipiell funktionierte die Grafikkarte aber. So hatte ich volle 3D-Beschleunigung, und auch <a href="https://developer.nvidia.com/nvidia-system-management-interface"><code>nvidia-smi</code></a> meldete die erwarteten Daten:</p>
<p><pre><code>+------------------------------------------------------+
| NVIDIA-SMI 340.93 Driver Version: 340.93 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 580 Off | 0000:01:00.0 N/A | N/A |
| 43% 49C P12 N/A / N/A | 494MiB / 1535MiB | N/A Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Compute processes: GPU Memory |
| GPU PID Process name Usage |
|=============================================================================|
| 0 Not Supported |
+-----------------------------------------------------------------------------+
</code></pre></p>
<p><h2>Die Analyse</h2></p>
<p><a href="https://developer.nvidia.com/cuda-downloads">NVIDIA bietet CUDA zwar für einige SUSE-Varianten zum Download</a>, aber leider nicht für Leap 42.1. Es gibt zwar Pakete für das unterliegende SLE 12, aber diese verlangen einen Grafikttreiber welcher nicht zum Kernel von Leap 42.1 passt. Deshalb habe ich mich für die Analyse auf OpenCL-Beispiel-Code zurückgezogen. Denn für <a href="https://www.khronos.org/opencl/">OpenCL</a> benötigt man nur die <a href="https://github.com/KhronosGroup/OpenCL-Headers/">Header</a>, welche man einfach direkt zum Code legen kann, und einen C-Compiler.</p>
<p>Schon der erste Versuch mit einem Beispielprogramm welches nur die OpenCL-Runtime initialisiert zeigt das Problem:</p>
<p><pre><code>> sudo ./platform
modprobe: FATAL: Module nvidia-uvm not found.
Failed to get platforms: -1001
</code></pre></p>
<p>Das <code>sudo</code> ist hier übrigens nur vorangestellt um es zu ermöglichen Kernel-Module nachzuladen. Ohne <code>sudo</code> erhält man den gleichen Fehler, aber ohne die essentielle Information zum Kernelmodul.</p>
<p>Schnell konnte ich herausfinden, dass eigentlich alle Kernelmodule installiert sind:</p>
<p><pre><code>> rpm -ql nvidia-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia.ko
> rpm -ql nvidia-uvm-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia-uvm.ko
> ls /lib/modules/4.1.12-1-default/updates/
nvidia.ko nvidia-uvm.ko
</code></pre></p>
<p>Allerdings war das nicht das Modulverzeichnis des aktuell laufenden Kernels:</p>
<p><pre><code>> uname -a
Linux eddie 4.1.13-5-default #1 SMP PREEMPT Thu Nov 26 16:35:17 UTC 2015 (49475c3) x86_64 x86_64 x86_64 GNU/Linux
</code></pre></p>
<p>Wo liegen also dessen Module? <code>/lib/modules/4.1.13-5-default/updates</code> existiert nicht. Das NVIDIA-Modul ist aber schnell gefunden:</p>
<p><pre><code>> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko
</code></pre></p>
<p>Nur fehlt in diesem Verzeichnis das <code>nvidia-uvm.ko</code>.</p>
<p><h2>Die Lösung</h2></p>
<p>Eine Neuinstallation des dazugehörigen Paketes lässt dann endlich auch OpenCL wieder richtig initialisieren:</p>
<p><pre><code>> zypper in in -f nvidia-uvm-gfxG03-kmp-default
> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko nvidia-uvm.ko
> modprobe nvidia-uvm
> ./platform
Failed to get platforms: -1001
> sudo ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE
> ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE
</code></pre></p>
<p>Um die Grafikkarte tatsächlich zu verwenden war dann allerdings noch ein Neustart notwendig.</p>
openSUSE 13.1 mit UEFI und Vollverschlüsselung auf openSUSE Leap 42.1 migrieren2016-01-03T22:38:05+01:002016-03-12T21:41:53+01:00Matthias Bachtag:marix.org,2016-01-03:/opensuse-131-mit-uefi-und-vollverschlüsselung-auf-opensuse-leap-421-migrieren.html
<p>Da <a href="http://lists.opensuse.org/opensuse-announce/2015-11/msg00003.html">der offizielle Support für openSUSE 13.1 am 5.1.2015 endet</a> war es höchste Zeit meine Workstation mal auf <a href="https://en.opensuse.org/Portal:42.1">openSUSE Leap 42.1</a> zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.</p>
<p>Meine Workstation nutzt …</p>
<p>Da <a href="http://lists.opensuse.org/opensuse-announce/2015-11/msg00003.html">der offizielle Support für openSUSE 13.1 am 5.1.2015 endet</a> war es höchste Zeit meine Workstation mal auf <a href="https://en.opensuse.org/Portal:42.1">openSUSE Leap 42.1</a> zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.</p>
<p>Meine Workstation nutzt ein vermutlich nicht ganz gewöhnliches Set-Up. OpenSUSE ist parallel zu Windows 10 installiert, und beides wird per <a href="https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/chap-UEFI_Secure_Boot_Guide-What_is_Secure_Boot.html">UEFI Secure Boot</a> gestartet. Den UEFI-Boot habe ich dann auch gleich mal genutzt um mir mit Anlauf selbst in den Fuß zu schießen: OpenSUSE unterstützt es zwar schon seit Ewigkeiten eine Upgrade aus dem laufenden System durchzuführen, da es mir aber immer als der sauberere Ansatz vorkam – und sicher auch aus Nostalgie – mache ich solche Updates immer noch ganz altmodisch per DVD. Allerdings bietet mein ASUS-EFI in der Bootmedienauswahl das Blu-Ray-Laufwerk immer zwei mal an. Einmal ganz oben in der Liste als <a href="https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting">BIOS-Boot</a>, und einmal ganz unten als echten UEFI-Boot. Natürlich habe ich – wollte ja nur schnell mal das Update starten – den oberen Eintrag genommen und mein EFI-System dann mal schön im BIOS-Modus aktualisiert. Leider fängt openSUSE diesen <a href="https://en.wikipedia.org/w/index.php?title=PEBKAC">PEBKAC</a> aktuell nicht ab und hat mir dann mal schön die Bootloaderkonfiguration kaputtgeschrieben. Zum Glück ist der Fehler – wenn man erst mal verstanden hat, was man falsch gemacht hat – trivial zu korrigieren. Einfach nochmal das Upgrade im UEFI-Modus starten, von Leap 42.1 auf Leap 42.1 aktualisieren (ja, das geht). Danach ist der Bootloader korrekt geschrieben.</p>
<p>Leider tritt einem beim Versuch die DVD mit openSUSE Leap 42.1 per UEFI zu booten <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=950569">Bug 950569</a> in den Weg. Der Bootcode auf der DVD ist nicht korrekt signiert, was auf meinem System zufolge hat, dass der Bildschirm einfach schwarz bleibt. <a href="https://nwrickert2.wordpress.com/2015/11/02/preparing-for-a-leap-42-1-install/">Das Problem lässt sich lösen, indem man Secure Boot im BIOS temporär deaktiviert</a>. Zum Glück installiert openSUSE Leap 42.1 bei der Installation bzw. dem Upgrade bereits die aktuellsten Version aller Pakete. So bleibt Nachzüglern wie mir nicht nur die Updateorgie nach der Installation erspart, sondern es landet auch korrekt signierter Code auf der Platte, so dass Secure Boot nach dem Update gleich wieder aktiviert werden kann.</p>
<p>Ein weiteres <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=904987">Problem bei openSUSE Leap 42.1 ist, dass es zumindest bei Upgrades nicht korrekt mit verschlüsselten Root-Partitionen umgehen kann</a>. Beim Boot „vergisst“ das System nach der Passphrase zu fragen. Wechselt man durch die Konsolen findet zeigt sich folgende Fehlermeldung: <code>Failed to start systemd-cryptsetup@luks<codierte ID>.service:</code>. Ich habe die ID in der Fehlermeldung mal gekürzt ;). Wie in <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=904987">Bug 904987</a> lässt sich das Problem lösen, indem man dem Kernel explizit sagt, dass er die entsprechende Partition entschlüsseln soll, indem man ihm die ID des LUKS-Containers per Kernelparameter <code>rd.luks.uuid</code> mitgibt.</p>
<p>Die ID des LUKS-Containers lässt sich mit <a href="https://gitlab.com/cryptsetup/cryptsetup">Cryptsetup</a> herausfinden. Liegt die Root-Partition z.B. auf <code>/dev/sda2</code>, so lässt sich die ID wie folgt herausfinden.
<pre><code>> cryptsetup luksUUID /dev/sda2
07246af2-915a-bd54-6a5s-6a5c35d15f45
</code></pre>
Der Bootparameter muss dann in <code>/etc/sysconfig/bootloader</code> zum Wert <code>DEFAULT_APPEND</code> hinzugefügt werden. Dieser sollte dann z.B. wie folgt aussehen:
<pre><code>DEFAULT_APPEND="splash=silent quiet showopts rd.luks.uuid=07246af2-915a-bd54-6a5s-6a5c35d15f45"
</code></pre>
Anschließend einmal den Bootloader neu schreiben lassen und das System fragt wieder nach dem Passwort. Idealerweise wird dieser Workaround schon <i>vor</i> dem Update implementiert. Nicht, weil dann der Bootloader sowieso neu geschrieben wird, sondern weil man sich dann das Herumgewurschtel mit einem Recovery-System spart.
</p>
„Indie Game: The Movie“ auf openSUSE2014-11-23T21:56:37+01:002014-11-23T22:02:16+01:00Matthias Bachtag:marix.org,2014-11-23:/„indie-game-movie“-auf-opensuse.html
<p>Startet man unter openSUSE, bzw. mit einem KDE-Desktop, von <a href="http://store.steampowered.com/">Steam</a> aus <a href="http://www.indiegamethemovie.com/">„Indie Game: The Movie“</a>, so kommt zwar ein archaisch wirkendes Xterm hoch, welches behauptet einem <a href="http://www.adobe.com/products/air.html">Adobe AIR</a> zu installieren, allerdings passiert danach nichts mehr. Hat man Adobe AIR bereits installiert startet „Indie Game: The Movie“ ohne Probleme.</p>
<p>Hier kommen …</p>
<p>Startet man unter openSUSE, bzw. mit einem KDE-Desktop, von <a href="http://store.steampowered.com/">Steam</a> aus <a href="http://www.indiegamethemovie.com/">„Indie Game: The Movie“</a>, so kommt zwar ein archaisch wirkendes Xterm hoch, welches behauptet einem <a href="http://www.adobe.com/products/air.html">Adobe AIR</a> zu installieren, allerdings passiert danach nichts mehr. Hat man Adobe AIR bereits installiert startet „Indie Game: The Movie“ ohne Probleme.</p>
<p>Hier kommen gleich mehrere Probleme zusammen:
<ul><li>Adobe AIR unterstützt schon seit mehreren Jahren Linux offiziell nicht mehr. Es muss also eine alte Version installiert werden, welche dann natürlich nicht die modernsten Annahmen macht was die Linuxumgebung angeht</li>
<li>Die Standardinstallation von Adobe AIR benötigt root-Rechte. Steam führt man allerdings normalerweise nicht als root aus, und das Skript welches die Installation durchführt fordert auch offensichtlich keine an.</li>
<li>Adobe AIR will bei der Installation auf KWallet, oder alternativ den Gnome Keyring zugreifen. Auf openSUSE 13.1 mit KDE findet es aber, obwohl natürlich KWallet installiert ist, keinen von beiden.</li>
</ul>
Woran genau die Installation scheitert habe ich nicht herausgefunden.</p>
<p>Zur manuellen Installation ist zunächst Adobe AIR von der Archivseite http://helpx.adobe.com/air/kb/archived-air-sdk-version.html herunterzuladen. Es empfiehlt sich die letzte Version mit Linuxunterstützung, also die 2.6 Runtime, zun nutzen. Diese muss mit root-Rechten und Zugriff auf X ausgeführt werden. Hierbei ergibt sich dann das Problem, dass KWallet nicht gefunden wird. Adobe AIR ist eine 32-bit Anwendung, auf den inzwischen üblichen 64-bit-Systemen prüft es offensichtlich im falschen Verzeichnis auf die Existenz der Bibliothek. <a href="http://askubuntu.com/questions/87447/how-can-i-install-adobe-air">Legt man, an sich redundant, das korrekte Verzeichnis in die Umgebungsvariable <code>LD_LIBRARY_PATH</code>, so läuft der Installer erfolgreich durch.</a> Nach dem Download ist also folgendes in einer Konsole auszuführen.</p>
<p><pre><code>chmod +x AdobeAIRInstaller.bin
su # sudo gibt per default keinen Zugriff auf den laufenden X-Server
LD_LIBRARY_PATH=/usr/lib64 ./AdobeAIRInstaller.bin
</code></pre></p>
Steam einfach auf openSUSE installieren2013-02-02T15:56:08+01:002013-02-02T16:00:29+01:00Matthias Bachtag:marix.org,2013-02-02:/create-blogeintrag-0.html
<p>Es ist jetzt wieder möglich <a href="http://steampowered.com">Steam</a> per <a href="http://de.opensuse.org/1-Klick-Installation">1-Klick-Installation</a> auf <a href="http://www.opensuse.org">openSUSE</a> zu installieren. Die passenden Links findet man über <a href="http://software.opensuse.org/package/steam">die SUSE Software Suche</a>.</p>
<p>Steam war bereits kurz nach Start der offenen Beta im OpenSUSE Build Service verfügbar, dort aber <a href="http://lists.opensuse.org/opensuse-buildservice/2013-01/msg00023.html">im Januar aufgrund rechtlicher Problem wieder herausgeflogen.</a> Im Endeffekt lief es darauf …</p>
<p>Es ist jetzt wieder möglich <a href="http://steampowered.com">Steam</a> per <a href="http://de.opensuse.org/1-Klick-Installation">1-Klick-Installation</a> auf <a href="http://www.opensuse.org">openSUSE</a> zu installieren. Die passenden Links findet man über <a href="http://software.opensuse.org/package/steam">die SUSE Software Suche</a>.</p>
<p>Steam war bereits kurz nach Start der offenen Beta im OpenSUSE Build Service verfügbar, dort aber <a href="http://lists.opensuse.org/opensuse-buildservice/2013-01/msg00023.html">im Januar aufgrund rechtlicher Problem wieder herausgeflogen.</a> Im Endeffekt lief es darauf hinaus, dass es von Valve keine offizielle Genehmigung für das openSUSE-Projekt gab Steam zu verbreiten. <a href="http://lists.opensuse.org/opensuse-buildservice/2013-02/msg00001.html">Jetzt hat Steam seine Lizens so geändert, dass jeder Steam-Pakete weiterverbreiten darf</a>, und prompt ist Steam auch wieder für openSUSE verfügbar. Es ist sind zwar mit SUSE wohl noch nicht alle Formalitäten für die Verbreitung von kommerzieller Software über die SUSE-Infrastruktur geklärt, aber da jetzt klar ist, dass Valve die Verbreitung in dieser Form erlaubt gehe ich davon aus, dass Steam weiterhin offiziell für SUSE verfügbar sein wird. Wer weiß, vielleicht ist es dann ja bei openSUSE 12.3 von Anfang an ganz offiziell dabei.</p>
<p></p>
MIDI-Eingabe in openSUSE 12.12012-03-10T14:13:15+01:002013-01-27T18:48:09+01:00Matthias Bachtag:marix.org,2012-03-10:/midi-eingabe-opensuse-121.html
<p>Da kommt man nach langer Zeit endlich mal wieder dazu seine <a href="http://www.hercules.com/de/DJ-Musik/bdd/p/12/dj-console-mk2-virtualdj-djc-ed/">Hercules DJ Console MK2</a> anzuschließen, und dann findet <href="http: mixxx.org ">Mixxx</a> kein MIDI-Gerät. Die Lösung ist einfach. In aktuellen Versionen von openSUSE sind die Geräte unter <code>/dev/snd</code> nur noch für den Nutzer <code>root</code> und die Gruppe <code>audio</code> verfügbar. Die Lösung …</href="http:></p>
<p>Da kommt man nach langer Zeit endlich mal wieder dazu seine <a href="http://www.hercules.com/de/DJ-Musik/bdd/p/12/dj-console-mk2-virtualdj-djc-ed/">Hercules DJ Console MK2</a> anzuschließen, und dann findet <href="http: mixxx.org ">Mixxx</a> kein MIDI-Gerät. Die Lösung ist einfach. In aktuellen Versionen von openSUSE sind die Geräte unter <code>/dev/snd</code> nur noch für den Nutzer <code>root</code> und die Gruppe <code>audio</code> verfügbar. Die Lösung: Den eigenen Nutzer der Gruppe <code>audio</code> hinzufügen, neu anmelden und schon geht es wieder. :)</p>
Philosophisches von zypper2012-01-15T11:39:26+01:002013-01-27T18:57:39+01:00Matthias Bachtag:marix.org,2012-01-15:/philosophisches-von-zypper.html
<p>Beim Versuch den <a href="http://www.simfy.de/downloads/player">Simfy Desktop Player</a> zu installieren überraschte <a href="http://en.opensuse.org/Zypper">zypper</a> gerade mit folgender Meldung:</p>
<p><pre><code>2 neue Pakete zu installieren.
Gesamtgröße des Downloads: 22,4 MiB. Nach der Operation werden zusätzlich 47,5 MiB belegt.
Fortfahren? [j/n/?] (j): j
Ungültige Antwort 'j'. [j/n/?] (j): j</code></pre></p>
<p>Bleibt die Frage, was …</p>
<p>Beim Versuch den <a href="http://www.simfy.de/downloads/player">Simfy Desktop Player</a> zu installieren überraschte <a href="http://en.opensuse.org/Zypper">zypper</a> gerade mit folgender Meldung:</p>
<p><pre><code>2 neue Pakete zu installieren.
Gesamtgröße des Downloads: 22,4 MiB. Nach der Operation werden zusätzlich 47,5 MiB belegt.
Fortfahren? [j/n/?] (j): j
Ungültige Antwort 'j'. [j/n/?] (j): j</code></pre></p>
<p>Bleibt die Frage, was er damit sagen wollte:
<ul>
<li>Diese Software willst du eigentlich gar nicht verwenden?</li>
<li>Heißt ja, wirklich immer ja?</li>
<li>…</li>
</ul></p>
Zwei Hinweise zum IPv6-Routing mit openSUSE2011-04-02T11:09:57+02:002013-01-28T12:50:13+01:00Matthias Bachtag:marix.org,2011-04-02:/zwei-hinweise-zum-ipv6-routing-mit-opensuse.html
<p>Den Artikel <a href="http://www.heise.de/ct/inhalt/2011/08/190/"><quote>Doppelmoppel – IPv6-Zugang fürs LAN nachrüsten</quote></a> in der aktuellen c't möchte ich nutzen um auf zwei Punkte hinzuweisen welche in den meisten Dokumentationen zum Thema leider fehlen, ohne die es unter openSUSE aber nicht funktioniert.</p>
<p><!--break--></p>
<p><ul>
<li>Das mit dem LAN verbundene Netzwerkinterface benötigt eine gültige IPv6-Adresse aus dem LAN-Subnetz. Diese …</li></ul></p>
<p>Den Artikel <a href="http://www.heise.de/ct/inhalt/2011/08/190/"><quote>Doppelmoppel – IPv6-Zugang fürs LAN nachrüsten</quote></a> in der aktuellen c't möchte ich nutzen um auf zwei Punkte hinzuweisen welche in den meisten Dokumentationen zum Thema leider fehlen, ohne die es unter openSUSE aber nicht funktioniert.</p>
<p><!--break--></p>
<p><ul>
<li>Das mit dem LAN verbundene Netzwerkinterface benötigt eine gültige IPv6-Adresse aus dem LAN-Subnetz. Diese muss von Hand vergeben werden, da die Zuweisung per <a href="http://www.litech.org/radvd/">radvd</a> am lokalen Interface nicht funktioniert.</p>
<p>Diese Adresse kann man via <code>ifconfig add <in radvd eingetragenes prefix>:<mac addresse>/64</code> vergeben. Ist die Link-lokale Addresse z.B. fe80::442b:39ff:f231:95cd/64 und das Prefix 2a01:498:4c8::/64 so wäre die Addresse 2a01:498:4c8:0:4a5b:39ff:feed:95cd/64.</p>
<p>Hat das lokale Interface keine gültige IPv6 im LAN-Subnetz werden die aus dem LAN kommenden Pakete vom Router verworfen.</li></p>
<p><li>Nutzt man die SuSEfirewall2 muss man diese so konfigurieren, dass sie Verbindungen vom LAN ins IPv6 zulässt. Per Default blockt die SuSEfirewall2 nämlich alle durchzuleitenden IPv6-Pakete.</p>
<p>Hierzu editiert man die Datei <code>/etc/sysconfig/SuSEfirewall2</code> und ändert den Wert <code>FW_FORWARD</code> auf <code>"<lokales IPv6-Netz>,2000::/3"</code>. 2000::/3 bezeichnet alle gültigen IPv6-Adressen. Im obigen Beispiel wäre der Eintrag dann <code>FW_FORWARD="2a01:498:4c8::/64,2000::/3"</code>. Wichtig bei diesem Eintrag ist die Reihenfolge, denn Verbindungen sind immer vom ersten zum zweiten möglich. Wer die Einträge vertauscht erlaubt also dem ganzen Internet Zugriff aufs LAN, kommt aber nicht raus.</li>
</ul></p>
<p>Zum Abschluss möchte ich noch auf ein allgemeines Problem bei IPv6 hinweisen. Ein Teil der eigenen IPv6-Adresse wird aus der MAC-Adresse des eigenen Rechners abgeleitet. Dadurch ist man natürlich dauerhaft im Netz identifizierbar. Um das dadurch entstehende Datenschutzproblem zu entschärfen gibt es die IPv6 Privacy Extension, deren Aktivierung ich jedem ans Herz legen möchte. Wie das geht beschreibt ein <a href="http://www.heise.de/netze/artikel/IPv6-Privacy-Extensions-einschalten-1204783.html">ausführlicher Artikel bei Heise-Netze</a> für alle Betriebssysteme. Ob die Aktivierung der Privacy Extensions erfolgreich war kann man z.B. durch den Aufruf von <a href="http://www.sixxs.net/">sixxs.net</a> prüfen, welches oben rechts die aufrufende IPv6-Adresse anzeigt.</p>
USB-Stick als Schlüssel für die Festplattenverschlüsselung2011-03-05T01:57:05+01:002017-01-08T14:50:33+01:00Matthias Bachtag:marix.org,2011-03-05:/usb-stick-als-schlüssel-für-die-festplattenverschlüsselung.html
<p><a href="http://www.opensuse.org">OpenSUSE</a> bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die …</p>
<p><a href="http://www.opensuse.org">OpenSUSE</a> bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners. Glücklicherweise bietet LUKS aber die Möglichkeit diese auf einem USB-Stick zu speichern, womit auch bei solchen Maschinen ein komfortabler Start möglich ist. </p>
<p><blockquote><strong>Achtung:</strong> Diese für openSUSE 11.3 erstellte Anleitung funktioniert bis einschließlich openSUSE 13.1. Auf openSUSE 13.2 und openSUSE Leap 42.1 habe ich sie nicht getestet. Auf openSUSE Leap 42.2 funktioniert sie <em>nicht</em> mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.</blockquote></p>
<p><h3>Ist ein USB-Stick als Schlüssel sicher?</h3></p>
<p>Sicherheit ist immer relativ zur Bedrohung zu sehen. Auch beim USB-Stick stellt sich also die Frage wovor er schützen soll. Beim stationär zuhause stehenden Rechner hat die Verschlüsselung vor allem eine Funktion, sie schützt die Daten wenn die betroffen Festplatten mal das eigene Haus verlassen. Hierbei gibt es im Prinzip nur zwei Fälle. Stellt sich eine Platte während der Garantiezeit als defekt heraus so erspart einem die Verschlüsselung das heutzutage sehr zeitaufwendige Löschen der Platte. Wird die Festplatte entwendet, so ist sie ohne den USB-Stick, der natürlich in diesem Fall nicht im Rechner gesteckt haben darf, auch nicht auszulesen.</p>
<p>Ein großer Vorteil des USB-Sticks besteht hier darin, dass er sehr lange Passwörter ermöglicht. Möchte man lange Passwörten auf klassischem Weg verwenden kommt man um ein Aufschreiben des Passworts oft auch nicht herum. Außerdem gewinnt man eine Möglichkeit die Herausgabe des Passworts zu verweigern, sollte man je dazu aufgefordert werden. Bei einem langen Passwort welches man nie getippt hat ist die Chance sich zu erinnern nicht existieren. Auch hier gilt natürlich, der USB-Stick darf dann nicht trivial dem Rechner zuzuordnen sein. </p>
<p><h3>Die Anleitung</h3></p>
<p><h4>Backup</h4>
Wie bei allen Operationen an der Basis eines Systems ist auch hier das Backup zu beginn wichtig. In diesem Fall ist es wichtig den Kernel und die Initramdisk zu sichern, da es sonst, sollte man sich bei der Konfiguration der Entsperrung via USB-Stick vertun, schwer ist wieder in das verschlüsselte System zu booten.</p>
<p>Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl <code>mkinitrd</code> sonst dennoch aktualisiert werden.
<pre><code>cp /boot/initrd-2.6.34-12 /boot/safe-initrd-2.6.34-12
cp /boot/vmlinuz-2.6.34-12 /boot/safe-enable-vmlinuz-2.6.34-12</code></pre>
Außerdem sollte man sich der Einfachheit halber gleich einen passenden Eintrag im Grub anlegen, wozu man in der Datei <code>/boot/grub/menu.lst</code> die passenden Zeilen einfügt:
<pre><code>title SafetyNet -- openSUSE 11.3 - 2.6.34-12
root (hd0,0)
kernel /safe-vmlinuz-2.6.34-12 root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x317
initrd /safe-enable-initrd-2.6.34-12</code></pre>
Dadurch kann man anschließend jederzeit auch noch mit dem bei der Installation vergebenen Passwort das System starten.</p>
<p><h4>Anlegen des Schlüssels</h4>
Als nächstes muss ein Schlüssel erzeugt werden. Um nicht zu viele zusätzliche Module in die Initramdisk packen zu müssen empfiehlt es sich einen Ext2-formatierten Stick zu verwenden. Dieser kann mit
<pre><code>mkfs.ext2 -L keystick /dev/sdb</code></pre>
erzeugt werden. <code>keystick</code> gibt hierbei das Label des erzeugten Dateisystems an, <code>/dev/sdb</code> muss an den tatsächlichen Gerätenamen des USB-Sticks angepasst werden. Sollte der Stick bereits mit ext2 formatiert sein sollte dennoch ein Label gesetzt werden.
<pre><code>tune2fs -L keystick /dev/sdb</code></pre></p>
<p>Das Label kann natürlich frei gewählt werden. Es dient später zur Identifizierung des Sticks. Dies hat zwei Vorteile:
<ul>
<li>Der USB-Stick unabhängig von hinzugekommenen oder entfernten Datenträgern gefunden</li>
<li>Anders als bei der Identifizierung über die ID des Sticks kann man einen zweiten Stick mit gleichem Label als Backup verwenden. Ich recycle gerne nutzlose Werbegeschenke für diese Aufgabe. Sollte mal eines kaputt gehen spare ich mir das Zeitaufwendige zurückspielen des Backups der ganzen platte, da ich den Schlüssel ja noch von einem zweiten USB-Stick laden kann.</li>
</ul></p>
<p>Anschließend sollte ein Passwort generieren und auf dem USB-Stick hinterlegen. Meine bevorzugte Methode ist diese:
<pre><code>pwgen -s 1024 1 > /media/keystick/keyfile</code></pre></p>
<p>Nun kann man den erzeugten Schlüssel der verschlüsselten Partition hinzufügen. Leider verhält sich LUKS leicht unterschiedlich was interaktiv eingegebene Schlüssel und Schlüsseldateien angeht. Deshalb müssen wir unseren Schlüssel "interaktiv" eingeben. Hierzu erzeugt man zunächst eine Datei welche eine Zeile mit dem bei der Installation gewählten Schlüssel und eine mit dem neuen enthält.
<pre><code>cat oldkey /media/keystick/keyfile > tmp</code></pre>
Damit kann man nun die passenden Tastatureingaben simulieren:
<pre><code>cryptsetup luksAddKey /dev/sda2 < tmp</code></pre>
Anschließend wird die temporäre Datei nicht mehr benötigt:
<pre><code>rm tmp</code></pre></p>
<p>Um zu testen ob der Schlüssel korrekt hinzugefügt wurde kann man probehalber einen leeren Schlüssel hinzufügen. LUKS ist schlau genug diesen Schlüssel nicht wirklich aufzunehmen:
<pre><code>cryptsetup luksAddKey /dev/sda2 < /media/keystick/keyfile</code></pre></p>
<p><h4>Erstellen der neuen Initramdisk</h4>
Damit der Kernel bevor das Root-Verzeichnis eingebunden ist auf den USB-Stick zugreifen kann muss man sicherstellen, dass die USB-Module in der Initrandisk ist. Hierzu sollte man in openSUSE sicherstellen, dass die Variable <code>INITRD_MODULES</code> in <code>/etc/sysconfig/kernel</code> folgende Werte enthält:
<pre><code>usb_storage scsi_mod</code></pre></p>
<p>Um LUKS den Schlüssel zu übergeben benötigt man ein Skript welches ihn vom USB-Stick liest. Dies kann an einer beliebigen Stelle im Dateisystem liegen, es wird beim erstellen der Initramdisk in diese gepackt:
<pre><code>#!/bin/sh
STICK=/dev/disk/by-label/keystick
FSTYPE=ext2
slumber=150
modprobe usb-storage 1>&2
modprobe scsi_mod 1>&2
mkdir /keystick 1>2&
sleep 5 1>2&
while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
sleep 1
slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /keystick ; then
$( echo 'FAILED!!!' ) 1>2&
echo ''
exit 1
fi
cat /keystick/keyfile</p>
umount /keystick 1>2&</code></pre></p>
<p>Damit LUKS weiß, dass es den Wert von einem Skript erhält muss die Datei <code>/etc/crypttab</code> angepasst werden:
<pre><code>cr_sda2 /dev/sda2 none initrd,luks,keyscript=/root/keyscript.sh</code></pre>
Hierbei sind zwei Dinge zu beachten:
<ul>
<li>Ist <code>keyscript</code> gesetzt ist <strong>keine</strong> interaktive Eingabe mehr möglich. Deshalb sollte man die alte Initramdisk (welche die alte Konfiguration enthält) vorher sichern.</li>
<li>Der Wert <code>initrd</code> ist notwendig, da openSUSE bei der Generierung der Initramdisk sonst nicht merkt, dass es das Keyscript mit einpacken muss.</li>
</ul></p>
<p>Zu guter letzt kann durch den Aufruf von <code>mkinitrd</code> die neue Initramdisk erstellt werden. Ein Neustart sollte den Schlüssel dann vom USB-Stick lesen anstatt diesen interaktiv zu erwarten.</p>
<p>Hat man die neue Konfiguration hinreichen getestet kann man den bei der Installation vergebenen Schlüssel aus LUKS entfernen und die gesicherte Initramdisk löschen.</p>
<p><h3>Eine Anmerkung zur Distributionsaktualisierung</h3></p>
<p>Diese Anleitung habe ich ursprünglich anhand von openSUSE 11.3 erstellt. Sie gilt aber auch für aktuellere Versionen bis 13.1. Auf openSUSE Leap 42.2 funktionierte diese methode aber <em>nicht</em>! Auf neuere Versionen kann man über das normale DVD-Update aktualisieren. Hierbei muss man allerdings die verschlüsselte Partition über einen eingetippten Schlüssel öffnen. Hierzu hilft es den bei der initialien Installation verwendeten Schlüssel nicht deaktiviert zu haben, oder aber temporär per <code>cryptsetup luksAddKey</code> einen kürzeren Schlüssel hinzuzufügen. Getestet habe ich auf diese Weise das Update von 11.3 auf 11.4 und von 11.4 auf 12.1. Der Installer warnt einen zwar, dass es Probleme geben kann, wenn man Partitionen per Kernel Device Name mountet, dies hat sich aber bisher nicht als Problem herausgestellt.</p>
<p><h3>Quellen</h3></p>
<p>Da die Literatur — was openSUSE angeht — zu diesem Thema leider noch sehr dürftig ist habe ich mich vieler Quellen bedient, von denen ich hier nur die wichtigsten nennen möchte:</p>
<p><ul>
<li><a href="http://forum.ubuntuusers.de/topic/luks-root-partition-mit-schluessel-auf-usb-st/#post-1928847">http://forum.ubuntuusers.de/topic/luks-root-partition-mit-schluessel-auf-usb-st/#post-1928847</a> lieferte die Vorlage für mein Keyscript.</li>
<li><a href="http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions">http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions</a> hilft enorm beim Verständnis.</li>
<li><a href="http://forums.fedoraforum.org/showthread.php?t=241942">http://forums.fedoraforum.org/showthread.php?t=241942</a> zeigt im Prinzip den ganzen Vorgang, funktioniert leider nicht 1:1 für openSUSE.</li>
<li><a href="http://wejn.org/how-to-make-passwordless-cryptsetup.html">http://wejn.org/how-to-make-passwordless-cryptsetup.html</a> zeigt mehrere Variationen des Themas, aber passt auch nicht direkt auf openSUSE.</li>
<li><a href="http://raftaman.net/?p=300">http://raftaman.net/?p=300</a> ist inspirierend, löst aber nicht ganz das gleiche Problem (der verwendete USB-Stick ist cool).</li>
<li><a href="https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Remote_unlocking_of_the_root_.28or_other.29_partition">https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Remote_unlocking_of_the_root_.28or_other.29_partition</a> liefert Grundlagen, wenn man dies möchte.</li>
</p>
Patch für die Hercules DJ Console-Treiber für Linux 2.6.30 und neuer2010-02-06T16:48:20+01:002013-01-28T12:53:09+01:00Matthias Bachtag:marix.org,2010-02-06:/patch-für-die-hercules-dj-console-treiber-für-linux-2630-und-neuer.html<p>Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein <a href=
<p>Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein <a href="https://marix.org/Anhänge/hdjmod_kernel_2.6.30.patch">kleiner Patch</a> behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert.</p>
<p>Hat man den Treiber nach der <a href="http://ts.hercules.com/eng/index.php?pg=view_files&gid=2&fid=28&pid=177&cid=1">Anleitung auf der Webseite</a> installiert, so kann man mit <code>dkms status</code> prüfen ob dieser im System erfolgreich installiert wurde. Auf System mit Kernel 2.6.30 aufwärt bekommt man hier nur die enttäuschende Meldung: <code>hdjmod, 1.28: added</code>. Wäre die installation erfolgreich gewesen müsste hier <code>installed</code> stehen.</p>
<p>Der nächste Schritt nach dem add ist der build. Ein Blick in das Logdatei <code>/var/lib/dkms/hdjmod/1.28/build/make.log</code> zeigt das Problem: <pre><code>/var/lib/dkms/hdjmod/1.28/build/device.c:1663: error: implicit declaration of function ‘snd_card_new’</code></pre></p>
<p> <a href="https://marix.org/Anhänge/hdjmod_kernel_2.6.30.patch">Der Patch</a> behebt das Problem indem er für neuere Kernel den Funktionsaufruf durch auf die neue Funktion snd_card_create ändert. Um ihn anzuwenden wechselt man in das Verzeichnis <code>/usr/src/hdjmod-1.28</code> und ruft dort <code>sudo patch -p1 < /path/to/hdjmod_kernel_2.6.30.patch</code> auf. Anschließen baut man mit <code>sudo dkms build -m hdjmod -v 1.28</code> das Modul und installiert es mit <code>sudo dkms install -m hdjmod -v 1.28</code>.</p>
<p>Anschließend kann man im DJ Control Panel sehen, dass der Treiber beim Anschließen der Konsole erfolgreich geladen wird. Insgesamt ein gutes Beispiel dafür, wieso man Treiber Open Source halten sollte, aber leider auch ein gute Beispiel, wieso man Treiber nicht außerhalb des Kernels pflegen sollte.</p>
<p><a href="https://marix.org/Anhänge/hdjmod_kernel_2.6.30.patch">>Hier kann man den Patch herunterladen<<a /></p>
Mystic Mine unter openSUSE 11.22009-12-04T19:58:49+01:002013-01-28T12:54:12+01:00Matthias Bachtag:marix.org,2009-12-04:/mystic-mine-unter-opensuse-112.html
<p><a href="http://www.koonsolo.com/mysticmine/">Mystic Mine</a> ist ein lustiges Independent-Spiel das man ähnlich wie Frozen Bubble mal schnell zwischendurch spielen kann. Und das beste daran, es gibt eine native Linuxversion.</p>
<p><!--break--></p>
<p>Leider scheiterte mein Versuch diese Linuxversion zu nutzen mit folgender Meldung:
<pre><code>Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/cx_Freeze/initscripts …</code></pre></p>
<p><a href="http://www.koonsolo.com/mysticmine/">Mystic Mine</a> ist ein lustiges Independent-Spiel das man ähnlich wie Frozen Bubble mal schnell zwischendurch spielen kann. Und das beste daran, es gibt eine native Linuxversion.</p>
<p><!--break--></p>
<p>Leider scheiterte mein Versuch diese Linuxversion zu nutzen mit folgender Meldung:
<pre><code>Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/cx_Freeze/initscripts/Console.py", line 29, in <module>
File "monorail.py", line 34, in <module>
File "koon/app.py", line 10, in <module>
File "koon/snd.py", line 4, in <module>
File "ExtensionLoader_pygame_mixer.py", line 12, in <module>
ImportError: libSDL_mixer-1.2.so.0: cannot open shared object file: No such file or directory</code></pre></p>
<p>Das ist mal ein schönes Beispiel für eine zielführende Fehlermeldung. SDL_mixer ist nicht installiert, die Installation der passenden Bibliothek hilft.
<code>sudo zypper in SDL_mixer</code>
</p>
Ein paar Hinweise zur Migration eine openSUSE auf ein RAID52009-01-17T20:17:44+01:002009-01-17T20:17:44+01:00Matthias Bachtag:marix.org,2009-01-17:/ein-paar-hinweise-zur-migration-eine-opensuse-auf-ein-raid5.htmlMöchte man ein System auf ein RAID5 migrieren reichen dafür die drei Festplatten. Für Ubuntu ist dies auf <a href=http://blog.netzpiraten.ch/ubuntu-migration-auf-ein-software-raid-5/>Netzpiraten.ch</a> schön beschreiben. Hier findet ihr die entsprechende Anleitung für openSUSE.
<p>
Möchte man ein System auf ein RAID5 migrieren reichen dafür die drei Festplatten. Für Ubuntu ist dies auf <a href="http://blog.netzpiraten.ch/ubuntu-migration-auf-ein-software-raid-5/">Netzpiraten.ch</a> schön beschreiben.
</p>
<p>
Ist der Grund für die Migration ein Hardwarefehler, so dass man die Ausgangsfestplatte anschließend tauschen möchte, kann man, statt wie auf <a href="http://blog.netzpiraten.ch/ubuntu-migration-auf-ein-software-raid-5/">Netzpiraten.ch</a> beschreiben, auch erst einmal ein RAID5 mit nur zwei Platten anlegen. Dies entspricht zwar eigentlich einem RAID1 mit unnötig umständlicher Paritätsberechnung, lässt sich aber später problemlos zu einem echten RAID5 erweitern und bietet bereits während der Wartezeit auf den Austausch die gewünschte Fehlertoleranz.
</p>
<p>
Ein solches, einem RAID1 entsprechendes RAID5, weigert sich YaST allerdings anzulegen. Nutzt man allerdings die auf <a href="http://blog.netzpiraten.ch/ubuntu-migration-auf-ein-software-raid-5/">Netzpiraten.ch</a> oder im <a href="http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO.html">The Software-RAID HOWTO</a> beschreibenen Befehle gelingt dies problemlos.
</p>
<p>
<pre><code>mdadm --create /dev/md0 -n2 -l5 /dev/sdb3 /dev/sdc3</code></pre>
</p>
<p>
Die hierfür zuvor notwendige Partitionierung lässt sich am besten aus dem laufenden openSUSE-System mit YaST machen. Um die Dateien zu kopieren lässt sich das <a href="/node/99">RAID unter Knoppix einbinden</a>. Dort kann man die Dateien mit <code>cp --archive</code> kopieren.
</p>
<p>
Möchte man das RAID5 später um eine Festplatte, zum Beispiel die zuvor eingesparte Dritte, erweitern, hilft die <a href="http://isomerica.net/archives/2007/07/12/growing-a-linux-software-raid-5-completely-online/">Beschreibung auf isomerica.net</a>. Wer ext3 verwendet muss nur statt <code>xfs_growfs</code> <code>resize2fs</code> verwenden. Der komplette Vergrößerungsvorgang kann komplett aus dem laufenden System erfolgen. Hierbei hilft <code>watch</code> den Fortschritt zu beobachten.
</p>
<p>
Da man bei diesen Aktionen auch durchaus mal die falsche Partition zerstören kann empfiehlt sich generell ein vorheriges Backup. Auch etwas Training in VirtualBox kann nicht schaden bevor man sich auf sein Live-System stürzt, dort können viele Unklarheiten beseitigt werden solange man noch ein komplett laufendes System hat.
</p>
Import von Amarok 1.4-MySQL-Datenbank in Amarok 22008-12-23T20:04:17+01:002013-01-28T12:54:57+01:00Matthias Bachtag:marix.org,2008-12-23:/import-von-amarok-14-mysql-datenbank-amarok-2.html
<p>Der Import meiner in MySQL abgelegten Amarok 1.4-Datenbank in Amarok 2 wollte zunächst nicht klappen. Ich scheiterte immer mit <code>QMYSQL: Verbindungsaufbau nicht möglich</code>. Zum Glück war vorher schon jemand über den Fehler gestolpert und hat eine Lösung gefunden, nämlich anstatt des Hostnamens die IP des Servers anzugeben. Nachlesen kann …</p>
<p>Der Import meiner in MySQL abgelegten Amarok 1.4-Datenbank in Amarok 2 wollte zunächst nicht klappen. Ich scheiterte immer mit <code>QMYSQL: Verbindungsaufbau nicht möglich</code>. Zum Glück war vorher schon jemand über den Fehler gestolpert und hat eine Lösung gefunden, nämlich anstatt des Hostnamens die IP des Servers anzugeben. Nachlesen kann man dies alles unter <a href="http://bugs.kde.org/show_bug.cgi?id=174269">KDE Bug 174269</a>. Kaum war die Voreinstellung <code>localhost</code> in <code>127.0.0.1</code> geändert schon rödelte die Kiste los.</p>
Zu welchem Paket gehörte die Datei nochmal2008-10-31T14:59:05+01:002013-01-28T12:56:35+01:00Matthias Bachtag:marix.org,2008-10-31:/zu-welchem-paket-gehörte-die-datei-nochmal.html<p>Will man unter openSUSE wissen zu welchem Paket eine Datei gehört lässt sich dies ganz leicht herausfinden. Leider gibt es in RPM oder Zypper keine expliziete Funktion um dies Abzufragen, aber sie lässt sich ganz leicht bauen aus vorhandenen Komponenten zusammenbauen.</p>
<p>Will man unter openSUSE wissen zu welchem Paket eine Datei gehört lässt sich dies ganz leicht herausfinden. Leider gibt es in RPM oder Zypper keine expliziete Funktion um dies Abzufragen, aber sie lässt sich ganz leicht bauen aus vorhandenen Komponenten zusammenbauen.</p>
<p>RPM zeigt im Abfrage-Modus (-q) mit -l alle Dateien einem Pakets an. Mit -a arbeitet der Abfrage-Modus auf allen Paketen. Es liegt also nahe alle Dateien aller Pakete anzuzeigen und alle unbenötigten Informationen mit grep auszufiltern. In meinem Beispiel suche ich das Paket glibc-devel welches die Datei /usr/include/gnu/stubs.h enthält.</p>
<p><pre><code>marix@eddie:~> rpm -qal | grep "/usr/include/gnu/stubs.h"
/usr/include/gnu/stubs.h</code></pre></p>
<p>Leider funktioniert dies wie im Beispiel zu sehen ist nicht so richtig. Zwar wird die Datei gefunden, das Paket aber noch nicht mit angezeigt. RPM zeigt mit -l ja nur die Dateien an, aber nicht die Paketnamen. Zum Glück lässt sich RPM aber über die Option --queryformat genau sagen, welche Informationen es zu einem Paket wie anzeigen soll. Unter http://rpm.org/max-rpm-snapshot/s1-rpm-query-parts.html#S3-RPM-QUERY-QUERYFORMAT-OPTION ist auch der passende Formatierungstext zu finden.</p>
<p><pre><code>marix@eddie:~> rpm -qa --queryformat '[%{=NAME}: %{FILENAMES}\n]' | grep /usr/include/gnu/stubs.h
glibc-devel: /usr/include/gnu/stubs.h</code>
</p>
Installation von KDE 4.1 unter openSUSE 11.02008-09-23T12:06:56+02:002017-07-10T17:26:00+02:00Matthias Bachtag:marix.org,2008-09-23:/installation-von-kde-41-unter-opensuse-110.html
<p>Momentan erfordert die Installation von KDE 4.1 unter openSUSE 11.0 etwas Handarbeit. Dennoch ist sie schnell und leicht erledigt. Für x86-Systeme gibt es unter <a href="http://de.opensuse.org/KDE/KDE4">http://de.opensuse.org/KDE/KDE4</a> auch Links zur Installation mit einem Klick. Wer ein x64-System hat oder es sowieso lieber per Hand macht …</p>
<p>Momentan erfordert die Installation von KDE 4.1 unter openSUSE 11.0 etwas Handarbeit. Dennoch ist sie schnell und leicht erledigt. Für x86-Systeme gibt es unter <a href="http://de.opensuse.org/KDE/KDE4">http://de.opensuse.org/KDE/KDE4</a> auch Links zur Installation mit einem Klick. Wer ein x64-System hat oder es sowieso lieber per Hand macht findet hier eine kurze Anleitung.</p>
<p><!--break--></p>
<p>Zunächst sind in Yast über den Punkt Software-Repositories folgende Repositories hinzuzufügen:
<ul>
<li><code>http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0/</code></li>
<li><code>http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0/</code></li>
<li><code>http://download.opensuse.org/repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop/</code></li>
</ul>
Die letzten beiden sind optional, erhöhen aber die Anzahl der zur Verfügung stehenden Anwendungen.</p>
<p>Wie unter <a href="http://de.opensuse.org/KDE/KDE4">http://de.opensuse.org/KDE/KDE4</a> erwähnt, benötigt man außerdem auch noch das Qt-Repository, da KDE 4.1 eine neueres Qt benötigt als bei 11.0 mitgeliefert wird. Fehlt dieses erscheint bei der Auswahl von KDE 4.1-Paketen die Fehlermeldung <code>nichts bietet libqt-x11 >= 4.4.2 benötigt von kdebase4-runtime-4.1.1-48.2.i586</code>.
<ul>
<li><code>http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/</code>
</ul>
</p>
<p>Sind alle Repositories hinzugefügt kann man in in Yast unter "Software installieren oder löschen" das Schema "KDE 4 Desktop-Umgebung" auswählen. Möchte man alle zum Schema gehörende Software installieren kann man, nachdem man das Schema ausgewählt hat, bei einem Rechtsklick in die Paketliste "Alle in dieser Liste"->"Installieren" auswählen. Hatte man schon KDE 4.0 installiert kann man auch einfach in der Menüleiste "Paket"->"Alle Pakete"->"Aktualisieren falls neuere Version verfügbar" auswählen. Dies aktualisiert dann KDE 4.0 auf 4.1.</p>
Doppelt angezeigte Aktualisierungen im openSUSE-Updater2008-08-24T17:15:50+02:002013-01-28T12:58:04+01:00Matthias Bachtag:marix.org,2008-08-24:/doppelt-angezeigte-aktualisierungen-im-opensuse-updater.html
<p>Seit meinem Update auf openSUSE 11.0 zeigte das openSUSE-Updater-Applet (<code>opensuseupdater-kde</code>) mir alle Aktualisierungen doppelt an. Grund war, dass ich versehentlich zwei Update-Repositories eingebunden hatte. Das Entfernen eines der beiden Repositories löste das Problem.
<!--break-->
<img src="https://marix.org/Anhänge/doppelteUpdatesImOpensuseUpdaterApplet.png" />
Im Bild ist zu sehen, dass die Updates für Java 5 und Java 6 doppelt vorhanden …</p>
<p>Seit meinem Update auf openSUSE 11.0 zeigte das openSUSE-Updater-Applet (<code>opensuseupdater-kde</code>) mir alle Aktualisierungen doppelt an. Grund war, dass ich versehentlich zwei Update-Repositories eingebunden hatte. Das Entfernen eines der beiden Repositories löste das Problem.
<!--break-->
<img src="https://marix.org/Anhänge/doppelteUpdatesImOpensuseUpdaterApplet.png" />
Im Bild ist zu sehen, dass die Updates für Java 5 und Java 6 doppelt vorhanden sind. Da das Applet nur eine graphische Schnittstelle für zypper ist lag es nahe zu schauen, ob dieses das gleiche Verhalten aufweist.</p>
<p><pre><code>marix@eddie:~> zypper lu
Die Daten des Repositorys 'Lokale RPMs' sind veraltet. Sie können 'zypper refresh' als Root ausführen, um die Daten zu aktualisieren.
Lese installierte Pakete...
Patches</p>
<p>Repository | Name | Version | Kategorie | Status
------------------------------+----------------+---------+-----------+---------
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_5_0-sun | 96 | security | Benötigt
openSUSE-11.0-Updates | java-1_5_0-sun | 96 | security | Benötigt
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_6_0-sun | 97 | security | Benötigt
openSUSE-11.0-Updates | java-1_6_0-sun | 97 | security | Benötigt</code></pre></p>
<p>Auch zypper zeigt jedes Update doppelt. Doch auch die Ursache des Problems ist zu sehen. Jede Aktualisierung ist aus zwei verschiedenen Repositories zu beziehen. Das erklärt sowohl wieso es die Updates doppelt gibt, als auch, wieso trotzdem immer korrekt aktualisiert wurde. Denn zypper hat immer nur das Update aus der ersten Quelle wirklich installiert, ähnlich wie bei Paketen die aus mehreren Quellen zu holen sind.</p>
<p><pre><code>marix@eddie:~> zypper lr
# | Alias | Name | Aktiviert | Auffrischen
---+-------------------------------+-----------------------------------+-----------+------------
1 | Lokale_RPMs | Lokale RPMs | Ja | Ja
2 | suse_1 | openSUSE-11.0-FTP-SRC-NonOSS 11.0 | Ja | Ja
3 | Marix'_Home_Repository_1 | Marix' Home Repository | Ja | Ja
4 | NVIDIA_Repository | NVIDIA Repository | Ja | Ja
5 | KDE:KDE4:Factory:Desktop | KDE:KDE4:Factory:Desktop | Ja | Ja
6 | openSUSE-11.0-FTP_11.0 | openSUSE-11.0-FTP 11.0 | Ja | Ja
7 | home:thindil_1 | home:thindil | Ja | Ja
8 | VideoLan_Repository | VideoLan Repository | Ja | Ja
9 | 11.0 | openSUSE-11.0-FTP-UPDATE 11.0 | Ja | Ja
10 | openSUSE-11.0-FTP-DEBUG_11.0 | openSUSE-11.0-FTP-DEBUG 11.0 | Ja | Ja
11 | Marix'_Sane_Repository | Marix' Sane Repository | Nein | Ja
12 | openSUSE-11.0-Updates | openSUSE-11.0-Updates | Ja | Ja
13 | Security_and_Privacy_1 | Security and Privacy | Ja | Ja
14 | home:dstoecker | home:dstoecker | Nein | Ja
15 | Packman_Repository | Packman Repository | Ja | Ja
16 | openSUSE-11.0-FTP-NonOSS_11.0 | openSUSE-11.0-FTP-NonOSS 11.0 | Ja | Ja
17 | openSUSE-DVD 11.0 | openSUSE-DVD 11.0 | Nein | Nein
18 | suse | openSUSE-11.0-FTP-SRC 11.0 | Ja | Ja</code></pre></p>
<p>In der Auflistung aller Quellen sieht man an Position 9 und 12 die beiden Update-Repositories. Zum Glück kann man mit zypper die Repositories auch über ihre Nummer identifizieren, so ist das entfernen nur wenig Tipparbeit.</p>
<p><pre><code>marix@eddie:~> sudo zypper rr 9
Entferne Repository 'openSUSE-11.0-FTP-UPDATE 11.0' [fertig]
Repository 'openSUSE-11.0-FTP-UPDATE 11.0' wurde entfernt.</code></pre></p>
<p>Eine anschließende Überprüfung der verfügbaren Updates zeigt, dass das Problem erfolgreich behoben wurde.</p>
<p><pre><code>marix@eddie:~> sudo zypper refresh
Lade Metadaten von Repository 'Lokale RPMs' herunter [fertig]
Repository 'openSUSE-11.0-FTP-SRC-NonOSS 11.0' ist aktuell.
Repository 'Marix' Home Repository' ist aktuell.
Repository 'NVIDIA Repository' ist aktuell.
Repository 'KDE:KDE4:Factory:Desktop' ist aktuell.
Repository 'openSUSE-11.0-FTP 11.0' ist aktuell.
Repository 'home:thindil' ist aktuell.
Repository 'VideoLan Repository' ist aktuell.
Repository 'openSUSE-11.0-FTP-DEBUG 11.0' ist aktuell.
Repository 'openSUSE-11.0-Updates' ist aktuell.
Repository 'Security and Privacy' ist aktuell.
Repository 'Packman Repository' ist aktuell.
Repository 'openSUSE-11.0-FTP-NonOSS 11.0' ist aktuell.
Repository 'openSUSE-11.0-FTP-SRC 11.0' ist aktuell.
Alle Repositories wurden aufgefrischt.
marix@eddie:~> zypper lu
Lese installierte Pakete...
Patches</p>
<p>Repository | Name | Version | Kategorie | Status
----------------------+----------------+---------+-----------+---------
openSUSE-11.0-Updates | java-1_5_0-sun | 96 | security | Benötigt
openSUSE-11.0-Updates | java-1_6_0-sun | 97 | security | Benötigt</code></pre></p>
<p>Ist man sowieso schon auf der Konsole unterwegs kann man die Updates auch gleich von dort einspielen.</p>
<p><pre><code>marix@eddie:~> sudo zypper up
Lese installierte Pakete...</p>
<p>Die folgenden Pakete werden aktualisiert:
java-1_6_0-sun java-1_6_0-sun-devel java-1_6_0-sun-alsa java-1_6_0-sun-jdbc
java-1_5_0-sun-plugin java-1_5_0-sun</p>
<p>Die folgenden NEUEN Patches werden installiert:
java-1_6_0-sun java-1_5_0-sun</p>
<p>Gesamtgröße des Herunterladens: 55,5 M. Nach der Operation werden zusätzlich 21,1 M genutzt.
Fortfahren? [JA/nein]:
Herunterladen von Paket java-1_6_0-sun-1.6.0.u7-1.1.x86_64 (1/8), 21,9 M (79,6 M installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 437,3 K
Lade herunter: java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (127,1 K/s)]
Wende Delta an: ./java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_5_0-sun-1.5.0_update16-1.1.i586 (2/8), 20,1 M (74,4 M installiert)
Lade herunter: java-1_5_0-sun-1.5.0_update16-1.1.i586.rpm [fertig (195,7 K/s)]
Installiere: java-1_5_0-sun-1.5.0_update16-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-devel-1.6.0.u7-1.1.x86_64 (3/8), 13,0 M (51,9 M installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 6,2 M
Lade herunter: java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (130,2 K/s)]
Wende Delta an: ./java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-devel-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-alsa-1.6.0.u7-1.1.x86_64 (4/8), 40,0 K (88,0 K installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,5 K
Lade herunter: java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Wende Delta an: ./java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-alsa-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-jdbc-1.6.0.u7-1.1.x86_64 (5/8), 32,0 K (88,0 K installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,2 K
Lade herunter: java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Wende Delta an: ./java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-jdbc-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_5_0-sun-plugin-1.5.0_update16-1.1.i586 (6/8), 469,0 K (1,7 M installiert)
Lade Delta herunter: ./rpm/i586/java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm, 60,7 K
Lade herunter: java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig]
Wende Delta an: ./java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig]
Installiere: java-1_5_0-sun-plugin-1.5.0_update16-1.1 [fertig]</code></pre></p>
Paketverwaltung verloren2008-02-29T07:49:19+01:002013-01-28T13:06:59+01:00Matthias Bachtag:marix.org,2008-02-29:/paketverwaltung-verloren.html
<p>Auf leider nicht nachvollziehbare Weise hatte ich letztens plötzlich mein YaST verloren. Dies machte sich dadurch bemerkbar, dass KDE den Versuch "Installieren von Software" zu Starten mit der Bemerkung es könne "/sbin/yast" nicht finden beendete. Zeitlich fiel das ganze mit einem KDE4-Update zusammen, allerdings war mir bei diesem kein …</p>
<p>Auf leider nicht nachvollziehbare Weise hatte ich letztens plötzlich mein YaST verloren. Dies machte sich dadurch bemerkbar, dass KDE den Versuch "Installieren von Software" zu Starten mit der Bemerkung es könne "/sbin/yast" nicht finden beendete. Zeitlich fiel das ganze mit einem KDE4-Update zusammen, allerdings war mir bei diesem kein Konflikt aufgefallen.</p>
<p>Zum Glück wird die Paket- und Quellenverwaltung inzwischen nicht mehr YaST-intern abgehandelt, sondern durch die libzypper, für die mit zypper auch ein Kommandozeilenwerkzeug existiert. So ließ sich YaST schnell wieder installieren.</p>
<p><!--break--></p>
<p><pre><code>sudo zypper install yast2</code></pre></p>
<p>So bekam ich zwar mein YaST zurück, leider fehlte aber immer noch das Paket zum "Installieren von Software". Mit zypper war dies allerdings auch schnell gefunden.</p>
<p><pre><code>zypper search yast</code></pre></p>
<p>Das gesuchte Paket heißt yast2-packager, also schnell mit zypper installiert.</p>
<p><pre><code>sudo zypper install yast2-packager</code></pre></p>
Rechner ausschalten mit openSUSE 10.32008-02-27T10:15:05+01:002013-01-28T13:07:35+01:00Matthias Bachtag:marix.org,2008-02-27:/rechner-ausschalten-mit-opensuse-103.html
<p>Nachdem ich endlich dazu gekommen war das Windows 2000 auf einem alten PIII 550 MHz durch openSUSE 10.3 zu ersetzen funktionierte der Rechner zwar wunderbar, allerdings weigerte er sich beharrlich sich nach dem Herunterfahren selbständig abzuschalten. Auch unter Windows hatte es damals etwas Nachdruck bei der Konfiguration der Energieverwaltung …</p>
<p>Nachdem ich endlich dazu gekommen war das Windows 2000 auf einem alten PIII 550 MHz durch openSUSE 10.3 zu ersetzen funktionierte der Rechner zwar wunderbar, allerdings weigerte er sich beharrlich sich nach dem Herunterfahren selbständig abzuschalten. Auch unter Windows hatte es damals etwas Nachdruck bei der Konfiguration der Energieverwaltung gebraucht, aber wie diesen Nachdruck unter Linux ausüben? Der Vergleich der Aufrufe des normalen und des Safemode-Systems in Grub legte schnell nahe alle Kombinationen der Parameter apm bzw. acpi = off oder on durchzuspielen. Doch alles half nichts. <a href="http://lists.opensuse.org/opensuse/2008-02/msg03121.html">Der entscheidende Hinweis</a> kam dann zufällig auf der opensuse Mailingliste. Mit der Parametrisierung apm=off und acpi=force schaltet das System sich wie gewünsch von alleine ab sobald es heruntergefahren ist. Das ganze noch mit Hilfe von Yast direkt in GRUB eingetragen und das System läuft, bzw. schaltet ab wie Butter.</p>
Zattoo unter openSUSE 10.2 64-Bit2007-09-15T22:29:51+02:002013-01-28T13:09:46+01:00Matthias Bachtag:marix.org,2007-09-15:/zattoo-unter-opensuse-102-64-bit.html<p>Wie auf <a href=http://www.heise.de/newsticker/meldung/95981>heise online</a> berichtet ist <a href=http://www.zattoo.de>Zattoo</a> jetzt auch in Deutschland frei verfügbar. Leider aber nur als 32-Bit-Programm und mit einer etwas merkwürdigen Installationsanleitung.</p>
<p>Zum Herunterladen ist zunächst eine Registrierung notwendig. Entgegen der Aussage auf der Webseite muss man aber eigentlich noch nicht mal eine gültige Emailaddresse verwenden, da keine Aktivierungsemail verschickt wird, sondern die Addresse wirklich lediglich zur Benutzeridentifikation verwendet wird.</p>
<p>Wie auf <a href="http://www.heise.de/newsticker/meldung/95981">heise online</a> berichtet ist <a href="http://www.zattoo.de">Zattoo</a> jetzt auch in Deutschland frei verfügbar. Leider aber nur als 32-Bit-Programm und mit einer etwas merkwürdigen Installationsanleitung.</p>
<p>Zum Herunterladen ist zunächst eine Registrierung notwendig. Entgegen der Aussage auf der Webseite muss man aber eigentlich noch nicht mal eine gültige Emailaddresse verwenden, da keine Aktivierungsemail verschickt wird, sondern die Addresse wirklich lediglich zur Benutzeridentifikation verwendet wird.</p>
<p>Die Installationsanleitung verwundert etwas, da sie unter anderem möchte, dass man XULRunner in das Zattoo-Verzeichnis installiert, obwohl dieses eigentlich bei openSUSE mitgeliefert wird. An den in der Anleitung angegebenen von Hand angelegten symbolischen Links kommt man leider nicht vorbei. Außerdem sind im RPM leider keine Abhängigkeiten gepflegt. Deshalb müssen einige Bibliotheken leider von Hand auf 32-Bit umgestellt werden.</p>
<p>Bevor man das Zattoo-RPM installiert sollte man zunächst sicherstellen, dass man die folgenden Libraries in 32-Bit installiert hat. Es kann sein, dass weitere Bibliotheken benötigt werden, aber diese sind mir aufgefallen. Um ein Paket in 32-Bit zu installieren muss man im YAST Packetmanagment im Reiter Version die 32-Bit Version (i586) auswählen. Ist das Paket schon installiert kann es notwendig sein das Paket auch noch von Hand auf "Aktualisieren" zu setzen.
<ul>
<li>libgnomeui-32bit (Ok, die ist immer 32-Bit)</li>
<li>gtkglext</li>
<li>mozilla-xulrunner181</li>
<li>faad2</li>
</ul></p>
<p>Nachdem das Zattoo-RPM installiert ist müssen die symbolischen Links hinzugefügt werden. Möchte man die XULRunner-Bibliothek von openSUSE verwenden sehen die Links allerdings etwas anders aus.
<pre><code>sudo ln -s /usr/lib/xulrunner-1.8.1/libgtkembedmoz.so libgtkembedmoz.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxpcom.so libxpcom.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libmozjs.so libmozjs.so.0d
sudo ln -s /usr/lib/libplds4.so libplds4.so.0d
sudo ln -s /usr/lib/libplc4.so libplc4.so.0d
sudo ln -s /usr/lib/libnspr4.so libnspr4.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxul.so libxul.so.0d</code></pre></p>
<p>Anschließen muss man noch den Linker auf die im Zattoo-Verzichnis liegenden Bibliotheken und Links hinweisen.
<pre><code>sudo /sbin/ldconfig /usr/lib/zattoo/</code></pre>
Bei Auslassen dieses Schrittes stürzt Zattoo jedesmal ab sobald es anfängt einen Kanal abzuspielen. In der Logdatei <pre><code>~/.Zattoo/Data/logs/zattoo.errorlog</code></pre> findet sich dann eine Meldung, dass eine bestimmte Funktion nicht gefunden werden konnte. </p>
<p>Persönlich finde ich es auch noch praktisch das Programm als zattoo verfügbar zu machen, da zattoo_player doch etwas lang zum tippen ist und zattood ein Tab-Complete verhindert.
<pre><code>sudo ln -s /usr/bin/zattoo_player /usr/local/bin/zattoo</code></pre></p>
<p>Anchließen hat man einen funktionierenden P2P-Fernseher der auf den ersten Eindruck sehr gut zu funktionieren scheint.</p>
Ton für OSS-Programme2007-07-05T21:04:43+02:002013-01-28T13:10:19+01:00Matthias Bachtag:marix.org,2007-07-05:/ton-für-oss-programme.html
<p>Auf meine OpenSUSE 10.2 Systeme hatte ich zunächst in Anwendungen wie X2, welche beim Ton noch auf OSS setzen, keinen Ton. Zum Glück lies sich das Problem am Ende durch ein einfaches Löschen der Konfiguration von KDesktop lösen.
<!--break-->
Statt Ton bekam ich bei allen Anwendungen die OSS verwenden eine …</p>
<p>Auf meine OpenSUSE 10.2 Systeme hatte ich zunächst in Anwendungen wie X2, welche beim Ton noch auf OSS setzen, keinen Ton. Zum Glück lies sich das Problem am Ende durch ein einfaches Löschen der Konfiguration von KDesktop lösen.
<!--break-->
Statt Ton bekam ich bei allen Anwendungen die OSS verwenden eine Fehlermeldung, obwohl der Ton bei anderen Anwendungen ging.
<pre><code>/dev/dsp: Das Gerät oder die Ressource ist belegt</code></pre>
Jegliche suche nach eventuell noch laufenden Programmen welche die Tonausgabe blockieren könnten brachte zunächst keinen Erfolg. Amarok, Arts etc. waren alle gegen Alsa konfiguriert. Es war auch ohne Probleme möglich mehrere Anwendungen gleichzeitig Ton ausgeben zu lassen. Auch waren die Treiber für die OSS-Emulation unter Alsa geladen.
<pre><code>marix@eddie:~> lsmod | grep oss
snd_pcm_oss 71680 0
snd_mixer_oss 35840 1 snd_pcm_oss
snd_pcm 115464 4 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd 89384 14 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer</code></pre>
Einen entscheidenden Hinweis lieferte ein mutiges Durchstarten von Alsa.
<pre><code>sudo /usr/sbin/rcalsasound restart</code></pre>
Danach hatte ich zwar Ton in X2, allerdings war mein Desktop auf einmal schwarz. Ein Neustarten von KDesktop bestätigte meinen Verdacht. Anschließend war die Tonausgabe wieder blockiert. Beim Neustarten von Alsa beendete KDestkop kommentarlos. Offensichtlich war es für die blockade der Tonausgabe, was sich auch leicht prüfen lies.
<pre><code>marix@eddie:~> lsof /dev/dsp* /dev/snd/**
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
kdesktop 19572 marix mem CHR 116,4 255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix 11r CHR 116,2 255551 /dev/snd/timer
kdesktop 19572 marix 12u CHR 116,4 255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix 13u CHR 116,6 255819 /dev/snd/controlC0</code></pre>
Blieb die Frage, wie man das Problem löst. Ein kurze Suche mit meiner Leiblingssuchmaschine (nicht die mit den zwei O, dafür bin ich schon zu lange im Netz) lieferte mir dann den entscheidenden Hinweis. Auf http://www.linux-club.de/ftopic60033.html ist zu lesen, dass diese Problem wohl durch die Konfiguration von KDesktop verursacht ist. Löschen der Konfiguration löst das Problem.
<pre><code>mv ~/.kde/share/config/kdesktoprc ~/.kde/share/config/kdesktoprc.bak</code></pre>
Leider habe ich nicht herausgefunden welcher Teil der Konfiguration das Problem verursacht, da diese eigentlich keine Informationen zur Tonausgabe enthält. Allerdings hat ein Löschen auch nur zur Folge, dass man den Bildschirmhintergrund und den Bildschirmschoner neu setzen muss, der Aufwand hält sich also in Grenzen.
Das beste daran ist, dass jetzt auch Descent 3 wieder richtig funktioniert. Das hatte sich bis jetzt nämlich immer kommentarlos gleich wieder beendet.</p>
<p>Kleines Update: Nach diesen Änderungen ist es jetzt auch möglich OSS-Programme mit aoss zu verwenden. Dies hat den Vorteil, dass man den Amarok im Hintergrund weiterlaufen kann und somit Musik und Anwendungston hat.</p>
Arts Startprobleme schnell gelöst2007-07-05T11:08:52+02:002013-01-28T13:10:45+01:00Matthias Bachtag:marix.org,2007-07-05:/arts-startprobleme-schnell-gelöst.html
<p>Seitdem ich mein KDE mithilfe der Quelle http://software.opensuse.org/KDE:/KDE3/opensuse_10.2/ aus dem SuSE-Build-Service auf 3.5.7 aktualisiert habe stürzte Arts immer beim Start ab.
<!--break-->
Ein Start des artsd in der Konsole erzeugte anschließend diese Ausgabe.
<pre><code>marix@eddie:/opt/kde3/lib64> artsd
unix_connect: can't connect …</code></pre></p>
<p>Seitdem ich mein KDE mithilfe der Quelle http://software.opensuse.org/KDE:/KDE3/opensuse_10.2/ aus dem SuSE-Build-Service auf 3.5.7 aktualisiert habe stürzte Arts immer beim Start ab.
<!--break-->
Ein Start des artsd in der Konsole erzeugte anschließend diese Ausgabe.
<pre><code>marix@eddie:/opt/kde3/lib64> artsd
unix_connect: can't connect to server (unix:/tmp/ksocket-marix/eddie.site-5e24-468ca6d0)
loading extension from '/opt/kde3/lib64/libartsmidi.so' failed: /opt/kde3/lib64/libartsmidi.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsmidi.la.
MCOP ObjectManager: can't find implementation for Arts::MidiManager.
loading extension from '/opt/kde3/lib64/libartsbuilder.so' failed: /opt/kde3/lib64/libartsbuilder.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsbuilder.la.
MCOP ObjectManager: can't find implementation for Arts::ArtsBuilderLoader.
Speicherzugriffsfehler</code></pre>
Das ist dann auch schon der entscheidende Hinweis zur Lösung des Problems. Anscheinend wurden bei der Erstellung der Pakete ein paar Links vergessen. Ein hinzufügen der Links löst das Problem.
<pre><code>
sudo ln -s libartsmidi.so.0 libartsmidi.so
sudo ln -s libartsbuilder.so.0 libartsbuilder.so
sudo ln -s libartsakode.so.0 libartsakode.so
sudo ln -s libarts_akode.so.0 libarts_akode.so
</code></pre></p>
USB-Joysticks und openSUSE 10.22007-05-09T00:58:28+02:002013-01-28T13:11:50+01:00Matthias Bachtag:marix.org,2007-05-09:/usb-joysticks-und-opensuse-102.html
<p>Schließt man einen USB-Joystick an hat <a href="http://www.opensuse.org">openSUSE</a> ein recht merkwürdiges Verhalten. Zumindest gilt dies für meinem Fall, bei dem ein Logitech Extreme 3D Pro an ein Asus Motherboard mit nForce 570 SLI-Chipsatz angeschlossen wird. Auf dem System läuft openSUSE 10.2 x86_64. Zum Glück lässt sich diese Problem mit wenigen …</p>
<p>Schließt man einen USB-Joystick an hat <a href="http://www.opensuse.org">openSUSE</a> ein recht merkwürdiges Verhalten. Zumindest gilt dies für meinem Fall, bei dem ein Logitech Extreme 3D Pro an ein Asus Motherboard mit nForce 570 SLI-Chipsatz angeschlossen wird. Auf dem System läuft openSUSE 10.2 x86_64. Zum Glück lässt sich diese Problem mit wenigen Handgriffen lösen.</p>
<p><!--break--></p>
<p>Zunächst scheint das System den Joystick korrekt zu erkennen, was unter anderem anhand von dmesg zu sehen ist.
<pre><code>marix@eddie:~> dmesg | grep Joystick
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D Pro] on usb-0000:00:02.0-1
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D] on usb-0000:00:02.0-4</code></pre>
Wie zu sehen ist habe ich gleich zwei Joysticks angeschlossen. Zunächst schein aber alles zu funktionieren.</p>
<p>Interessant wird die Sache sobald man versucht den Joystick zu verwenden. Started man zum Beispiel das hervorgagende <a href="http://www.dxx-rebirth.de">D1X-Rebirth</a> bekommt man eine wenig erfreulich Meldung.
<pre><code>sdl-joystick: found 0 joysticks</code></pre>
Bestätigt wird die schlechte nachricht auch beim Einsatz von joy2key.
<pre><code>Error opening /dev/input/js0!
Are you sure you have joystick support in your kernel?</code></pre>
Wie die Meldung vermuten lässt, liefert ein <code>ls /dev/input/ | grep js</code> nichts zurück. Der Joystick funktioniert zwar als USB-Gerät, aber seine Semantik ist unbekannt.</p>
<p>Die Fehlermeldung von joy2key führt zur Lösung. Um den Joystick auch unter /dev/input zu sehen muss das Kernelmodul joydev geladen werden.
<pre><code>eddie:~ # modprobe joydev</code></pre>
Damit dies auch bei jedem Systemstart automatisch geschieht muss eine zeile in /etc/init.d/boot.local eingefügt werden.
<pre><code>/sbin/modprobe joydev</code></pre>
Nun steht der Joystick auch bei jedem Systemstart sofort zur Verfügung.</p>
<p>Nun zur Kuriosität. Startet man YaST und installiert neue Software funktioniert der Joystick anschließend reproduzierbar auch so. In diesem Fall scheint aus irgendeinem Grund das Modul also immer geladen zu werden. Sieht fast so aus, als wären Joysticks leider nicht mehr verbreitet genug um von Anfang an berücksichtigt zu werden und wurden beim Startup einfach vergessen.</p>