Willkommen zum openSUSE Planeten

Dies ist eine Zusammführung der Blog-Einträge von Mitwirkenden im openSUSE-Projekt.

Zum Hinzufügen eines Blog-Feeds bitte die Anleitung lesen.


Dienstag
09. April 2019


face

Liebe LeserInnen,

dieses Jahr ist es wieder soweit! In Nürnberg findet vom 24.05.-26.05.2019 die alljährliche openSUSE Conference 2019 statt!

https://events.opensuse.org/

Wir brauchen noch fleißige HelferInnen! 🙂

Wenn Ihr Zeit und Lust habt als Helfer zu arbeiten meldet euch bei uns im Kontaktformular oder unter folgender E-Mail:

ddemaio{at}opensuse{dot}org

Ich zähle auf euch! 😉 Vielleicht sehen wir uns in Nürnberg! Als Helfer werdet ihr mich natürlich antreffen!

Viele Grüße

Andi


Sonntag
07. April 2019


face

Im 21.Jahrhundert sind die Social Media kaum wegzudenken – so stellt sich für openSUSE-lernen.de die Frage, ob wir auf den Social Media (Facebook, Twitter oder Instagram) vertreten sein sollen?

Ihr könnt ab heute darüber abstimmen!

Die Umfrage geht bis zum 12.05.2019!

Coming Soon

face

Ihr merkt sicher, dass mir eure Meinung und Wünsche ein großes Anliegen ist. Daher nutze ich die Umfragen, um mir ein Meinungsbild zu schaffen.

In dieser Umfrage geht es darum, welche Medien ihr euch wünscht (z.B. Podcasts, Live-Videos, How-To-Tutorials)

Ihr könnt ab heute an der Umfrage teilnehmen!

Diese Umfrage geht bis zum 12.05.2019!

Coming Soon

face

Es ist eine lange Zeit her, dass der Wochenrückblick geschrieben wurde und über Entwicklungen und Veränderungen bei openSUSE berichtet wurde.

Daher stellt sich nun die Frage, ob ihr einen Wochenrückblick wieder haben wollt, damit ihr „up-to-date“ seid, was in der openSUSE-Welt los ist.

Zur Abstimmung steht der Turnus, ob wöchentlich, 2-wöchentlich, 1x im Monat oder 1x im Quartal sowie die Kombi mit „Breaking-News“.

Ihr könnt an der Umfrage ab heute teilnehmen.

Die Umfrage geht bis zum 12.05.2019!

Ich freue mich auf eine gute Beteiligung!

Viele Grüße

Euer

Andi

Coming Soon

face

Liebe LeserInnen,

mit großer Freude habe ich gelesen, dass viele von euch sich freuen, dass der Blog fortgesetzt wird. Die bisherigen Kommentare bestärken diese Entscheidung! 🙂

Ihr sollt wissen, wer der „Neue“ ist und daher habe ich mir gedacht, dass ich mich kurz vorstelle:

Mein Name ist Andreas Artz (Spitzname: Andi) und ich bin 29 Jahre alt. Gebürtig komme ich aus NRW (Raum Düsseldorf). Ich lebe allerdings seit 4 Jahren im Raum Gießen/Mittelhessen. Abitur habe ich 2008 gemacht und seitdem diverse Fächer studiert: Geschichte, Archäologie und Kath. Theologie.

Ich bin Freiberufler und arbeite als Nachhilfelehrer, so dass ich meine Zeit frei einteilen kann. Es ist Fluch und Segen zugleich 🙂

Die Computerwelt hat mich schon als kleines Kind immer fasziniert und habe gerne am PC gearbeitet oder gerne am PC/Laptop rumgeschraubt. In die Linux-Welt kam ich gut vor 4 Jahren und habe klassisch mit LinuxMint und Ubuntu gearbeitet. Am Ende bin ich aber bei openSUSE Tumbleweed hängen geblieben, was ein stabiles System ist.

In meiner Freizeit programmiere ich gerne, treffe Freunde, koche und bei gutem Sonnenschein bin ich auch im Garten.

Ich hoffe, dass ihr nun einen kleinen Eindruck von mir erhalten konntet.

Habt einen schönen sonnigen Sonntag.

Viele Grüße

Andi


Samstag
06. April 2019


face

Ein Überblick über die openSUSE-Konferenzen 2019

  • openSUSE Summit Nashville (USA) vom 05.04 bis 06.04.2019
  • openSUSE Conference 2019 in Nürnberg vom 24.05 bis 26.05.2019

Hier findet ihr den Link zum Nachlesen:

https://events.opensuse.org/


Freitag
05. April 2019


face

Mein finnischer Freund und Kollege Pekka Leppänen ist derzeit auf der SUSEcon 2019 in Nashville. Er wird einen Artikel über die Themen der diesjährigen Konferenz schreiben und uns somit ein paar Eindrücke mittels Bildern zur Verfügung stellen!

Der Artikel wird vorraussichtlich nächste Woche hier online gestellt. Sprache ist Englisch! 🙂

Viele Grüße

Andi


Montag
25. März 2019


face

Liebe openSUSE-Leser,

viele von euch haben sich mehr oder weniger mit dem Gedanken angefreundet, dass opensuse-lernen.de aufhört.

Doch zu eurer großen Freude können wir euch nun folgende Mitteilung machen:

Thomas und Ich haben uns zusammengesetzt und werden eine Übergabe machen, so dass ich opensuse-lernen.de mit dem selben Herzblut von Thomas weiterführen möchte. Somit wird weiterhin neuen und alten openSUSE-Nutzern eine Plattform des Austausches, der Entwicklung von openSUSE und Tipps&Tricks gegeben sein.

Ich freue mich auf eure Meinung!

Viele Grüße

Andreas Artz


Sonntag
10. März 2019


face

Hallo liebe openSUSE-Anwender.

Ich werde Anfang April 2019 diesen openSUSE Blog einstellen. Inzwischen bin ich seit über einem Jahr zu Linux Mint gewechselt und damit sehr zufrieden. Meine Zeit mit openSUSE ist größtenteils vorbei. Ich habe nur noch zwei Rechner mit openSUSE, aber weit mehr mit Linux Mint zu betreuen.

Also werde ich diesen Blog nicht weiter pflegen und auch abschalten. Sollte jemand Interesse haben diesen Blog weiter zu führen kann er sich gerne mit mir in Verbindung setzen.


Sonntag
06. Januar 2019


face

Du hast vielleicht schon gehört, dass die Wahlen für drei offene Sitze im openSUSE Board im Gange sind. Ich habe eine Weile darüber nachgedacht, für das Board zu kandidieren und jetzt scheint es der richtige Zeitpunkt zu sein, um mich einzubringen.

Der nachfolgende Text ist die deutsche Übersetzung einer einfachen, unbearbeiteten Kopie meiner Bewerbung.

Einführung, Biographie und Beiträge

Mein Name ist Vinzenz Vietzke, aber ich bevorzuge es, beim viel kürzeren “vinz” oder “vinzv” zu bleiben. Ich bin 34 Jahre alt, lebe in einer kleinen Stadt in Süddeutschland. Wie die meisten deutschen Linux-Anwender in meinem Alter habe ich bereits Ende der 90er Jahre meine ersten Schritte mit S.u.S.E. gemacht. Im Laufe der Jahre wechselte ich zwischen verschiedenen Distributionen und trug auf verschiedene Weise zu etlichen von ihnen bei. Mein Hauptberuf ist Produktmanagement und Marketing beim Linux-Hardwareanbieter TUXEDO Computers.

openSUSE und TUXEDO

Ausgehend von nur einem Laptop mit openSUSE bieten wir bei TUXEDO heute rund 20 verschiedene Modelle sowie eine große Auswahl an Desktop-PCs mit vorinstalliertem Leap 15. Kunden erhalten außerdem kostenlosen lebenslangen Support für ihr vorinstalliertes System. Deshalb muss natürlich auch unser kostenloses Telefon/E-Mail-Supportteam für openSUSE geschult werden. Für dieses ganze Projekt war und bin ich als Technik- und Projektleiter sozusagen verantwortlich, um openSUSE auf die Computer von TUXEDO zu “bringen”. Ich bin mit oS in Kontakt getreten, habe ausgearbeitet, wie und wann wir alles realisieren können.

Zusätzlich zu den technischen Angelegenheiten bin ich die treibende Kraft bei TUXEDO Computers, damit unser Unternehmen die Unterstützung von openSUSE intensiviert. Seit Oktober 2018 sponsern wir daher offiziell das openSUSE-Projekt. Wir bieten jedes unserer Modelle als Vorführ- und Workshop-Gerät kostenlos an und kümmern uns um die Logistik- und Event-Betreuung. Außerdem sponsern wir die oSC19 in Nürnberg mit Geräten zur Demonstration und für Installationsfeste.

Natürlich sind das vor allem finanzielle Anstrengungen und unternehmensinterne Projekte. Aber um openSUSE einen größeren Bekanntheitsgrad zu verschaffen, braucht es jemanden, der koordiniert, vorantreibt und sich kümmert. Deshalb nenne ich meine Beiträge zu openSUSE meist “Meta-Beiträge”.

i18n

Neben den teils bezahlten und teils Freizeitaktivitäten für TUXEDO koordiniere ich Upstream-Übersetzungsteams von Xfce, übersetze aktiv openSUSE und vielen anderen Projekten. Für Details siehe meine Profile bei Crowdin, Gnome, Transifex sowie meine persönliche Website..

Ziele

Wie jedes von Freiwilligen geführte Projekt hat auch openSUSE seine Probleme zu lösen. Die meisten von ihnen sind offensichtlich und bereits in Arbeit: Konsolidierung von Webauftritten, Reinigung des Wikis, Sortierung der Kommunikationsinfrastruktur und mögliche Erweiterungen. Ich glaube nicht, dass es noch etwas mehr braucht, um diese Dinge außer der Zeit voranzutreiben. Der Vorstand hat in der Vergangenheit bei diesen Dingen eine wirklich großartige Arbeit geleistet und wird es sicherlich auch in Zukunft tun.

Große und kleine Probleme

Eines der Hauptthemen, die ich erlebe, ist die öffentliche Wahrnehmung, z. B. wie openSUSE als Distribution wahrgenommen wird


face

About two years ago, I wrote a mail titled "Another openSUSE Board candidate". These two years passed quickly, and I really enjoyed being part of the Board and helping the community whenever needed.

I'd like to continue this "job", and therefore decided to run for re-election.

I use openSUSE since years (it was still named „SuSE Linux“ with lowercase „u“ back then) and started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1300 bugs. Nowadays, OBS ruins my bugzilla statistics by introducing the option to send a SR ;-)

One of my current activities in openSUSE is working in the Heroes team, where I started with moving and upgrading the wiki. I also help out on various *.opensuse.org servers since someone was evil enough to give me root permissions on lots of them ;-) (Transparency note: I helped to setup the elections.opensuse.org server before last year's elections - but will of course not touch it until the elections finish.)

My other openSUSE hobbies ;-) are AppArmor and PostfixAdmin, where I'm active in upstream development and as packager. AppArmor also turned out to be a good opportunity for cross-distribution collaboration.

You can find me on several mailinglists and on IRC (nickname "cboltz"), and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.

My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)

Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random [1] signatures under my mails, so be careful what you write ;-)

There are some things I‘ll never do (you might remember them from two years ago):

  • use a stable release on my main computer – Tumbleweed is just too good ;-)
  • open a bugreport if fxing the bug and sending a SR is faster
  • be too serious – hey, our motto is „Have a lot of fun...“ ;-)
  • drink beer ;-) (sorry, not even openSUSE beer)

If you want to read more from or about me, have a look at


I wish all candidates good luck, and hope that we‘ll see some more candidates and lots of voters!



[1] sometimes I hand-pick signatures, and this is one of these cases with a non-random signature ;-) (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception)
--
Christian, there are times you are a pain in the ass, there are times I really like you.
This is one of both of those times ;)
[Richard Brown]


Sonntag
09. Dezember 2018


face

Kmail, das Mailprogramm des KDE Projekts, kommt ja nicht alleine daher. Mit dabei ist auch ein Adressbuch, eine Terminverwaltung, ein Benachrichtigungsdienst und noch einiges mehr. Das ganze wird von Akonadi, dem dahinterliegenden Backend der gesamten KDE PIM Suite, sozusagen am Laufen gehalten.

Standardmäßig läuft Akonadi mit MySQL als Datenbanksystem, was bei mir aber immer wieder Zicken gemacht hat. Daher habe ich mich mal nach Alternativen umgesehen und bin neben SQLite bei PostgreSQL gelandet. Über SQLite und die Implementierung in Akonadi gab es leider einige negative Berichte, darum habe ich es direkt aussortiert.
Mit PostgreSQL hatte ich keine Erfahrungen, konnte es aber recht schnell einrichten. Die Anbindung von Akonadi und somit Kmail an PostgreSQL war ebenfalls einfach.

Alle Schritte unter openSUSE

Zuerst installieren wir alle nötigen Pakete für PostgreSQL und die Akonadi-Anbindung:

# zypper in postgresql-server libQt5Sql5-postgresql

PostgreSQL Server aktivieren und starten:

# systemctl enable --now postgresql

Postgres-Nutzer und -Datenbank anlegen:

# su - postgres
$ createuser <dein-nutzername>
$ psql postgres
postgres=# alter user <dein-nutzername> createdb;
postgres=# \q;
# exit

Dann richten wir – mit deinem regulären Nutzerkonto – den Datenbankzugriff einrichten:

$ createdb akonadi-<dein-nutzername>

Nun stoppen wir Akonadi und löschen bzw. verschieben die Einstellungen. Das ist besonders wichtig, falls du Akonadi schon einmal gestartet hast!

$ akonadictl stop
$ rm -rf ~/.local/share/akonadi

Die Verbindung zum Datenbankserver passen wir in der Datei ~/.config/akonadi/akonadiserverrc wie folgt an:

[%General]
Driver=QPSQL

[QPSQL]
Host=/tmp/akonadi-<dein-nutzername>.hash
InitDbPath=/usr/bin/initdb
Name=akonadi
Options=
ServerPath=/usr/bin/pg_ctl
StartServer=true

Abschließend Akonadi neu starten und du bist startklar:

$ akonadictl start

Sonntag
11. November 2018


face

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

Die grundlegenden Funktionen von Keybase sind über das Kommandozeilenwerkzeug keybase verfügbar. Dieses wird vom Paket keybase-client bereitgestellt und lässt sich in Tumbleweed durch ein einfaches sudo zypper install keybase-client installieren. Für Leap 15.0 ist das Paket leider nur als Versuchspaket verfügbar, welches sich am besten per 1-Klick-Installation von software.opensuse.org installieren lässt.

Außerdem bietet Keybase noch zwei weitere nützliche Funktionen. Mit dem dazugehörigen Dateisystem lassen sich Daten verschlüsselt und signiert mit anderen Nutzer tauschen. Auch öffentlich lassen sich darüber Dateien anbieten. Diese erscheinen dann unter https://<nutzername>.keybase.pub, und sind natürlich nicht verschlüsselt sondern nur signiert. Hierfür wird das Paket kbfs benötigt. Ist diese installiert, kann man per systemctl --user start kbfs das Dateisystem starten, welches dann unter ${XDG_RUNTIME_DIR}/keybase/kbfs erscheint.

Die zweite nützliche Funktion ist es Git-Repositories verschlüsselt in Keybase abzulegen. Hierzu wird das Paket kbfs-git benötigt. Sobald diese installiert ist, und das Dateisystem aktiv, kann Git auf Repositories welche das Protokoll keybase nutzen zugreifen. Die Verwaltung erfolgt hierbei über das Kommando keybase git.


Dienstag
30. Oktober 2018


face

Seit letzter Woche ist Piper in openSUSE Tumbleweed als Paket enthalten. Piper 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.

Ein Screenshot von Piper

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.

Zur Installation muss das Paket piper ausgewählt werden, entweder in der grafischen Paketverwaltung, per 1-Klick-Installation auf software.opensuse.org oder auf der Kommandozeile:

sudo zypper install piper

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.


Montag
22. Oktober 2018


face

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) Worker kompatibel ist, welches immer noch der Standard ist.

Um HTTP/2 zu aktivieren ist zunächst ein kompatibles MPM zu installieren. Eine gute Wahl ist hierbei das MPM Event, welches unter openSUSE durch das Paket apache2-event bereitgestellt wird.

sudo zypper install apache2-event

Alle notwendige Konfiguration kann anschließend in der Datei /etc/sysconfig/apache2 vorgenommen werden:

  1. Das korrekte MPM auswählen: APACHE_MPM=event.
  2. Das HTTP2-Module durch hinzufügen von http2 zum Wert von APACHE_MODULES aktivieren.
  3. Den Wert HTTP2 zu APACHE_SERVER_FLAGS um die von openSUSE mitgelieferte Konfiguration für HTTP/2 zu aktivieren.

Ab dem nächsten, per systemctl restart apache2 durchführbaren, Neustart ist der Server dann per HTTP/2 zu erreichen.

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.


Samstag
13. Oktober 2018


Matthias Bach: GameMode

22:00 UTC

face

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 Feral Interactive entwickelte GameMode.

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

Da selbst Spiele von Feral Interactive noch nicht durchgängig GameMode unterstützen gibt es außerdem libgamemodeauto. Libgamemodeauto kann per LD_PRELOAD mit einer Anwendung mitgeladen werden und sorgt dann automatisch für den Wechsel in den Spielemodus. Installiert man libgamemodeauto über das openSUSE-Paket libgamemodeauto0, so findet es sich in /usr/lib64/libgamemodeauto.so.0. Um es im Spiel game zu nutzen ist diese dann wie folgt zu starten:

LD_PRELOAD=/usr/lib64/libgamemodeauto.so.0 game

Um Spiele per Steam mit libgamemodeauto zu starten ist in den Startoptionen des Spieles folgendes einzutragen:

LD_PRELOAD=$LD_PRELOAD:/usr/lib64/libgamemodeauto.so.0 %command%

Diese Kommandozeilen finden sich auch in der Paketbeschreibung von libgamemodeauto0, welche sich per zypper info libgamemodeauto0 anzeigen lässt.

Der einfachste Weg GameMode zu installieren ist den Download oder die Anleitung von software.opensuse.org zu nutzen. In Tumbleweed reicht ein einfaches zypper install ligbamemodeauto0. In Leap ist libgameodeauto leider noch nicht eingezogen, so dass zuvor das Repository games:tools hinzugefügt werden muss.

Zusätzliche Aktionen für den Start und das Ende des Spielemodus lassen sich in der Datei ~/.config/gamemode.ini definieren. Bei mir sieht diese so aus:

[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

Mit boinccmd wird Boinc für die dauer der Spielesitzung angehalten. Mit akonadictl halte ich effektiv mein Emailprogram an und mit balooctl 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 killall gamemoded. Durch die nächste Anwendung, welche den GameMode nutzen möchte, wird der Prozess automatisch wieder gestartet, dann mit der neuen Konfiguration.

Für einfache Tests gibt es außerdem noch die Möglichkeit den Spielemodus mittels gamemode -r explizit zu aktivieren. Beenden des Programmes per


Samstag
09. Juni 2018


face

Seit dem 25. Mai 2018 ist openSUSE Leap 15.0 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.

openSUSE Leap 15.0 ist jetzt verfügbar

Der NVIDIA-Treiber

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.

Sollte das System bereits aktualisiert und Nouveau aktiv sein, so empfiehlt es sich den alten NVIDIA-Treiber mittels zypper remove nvidia* komplett zu deinstallieren und anschließen neu zu installieren. Eine Neuinstallation mittels zypper install --force hat bei mir in der Vergangenheit meißtens nicht den gewünschten Erfolg gebracht.

UEFI

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.

Repositories

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.

Die konfigurierten Repositories

Zypper kann einem mit repos -u 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:

> 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 

Freitag
25. Mai 2018


face

Es ist soweit. Die openSUSE Entwickler haben die nächste Version „Leap 15“ veröffentlicht. Mit diesem Release sind die Versionsnummern der beiden SUSE Produkte openSUSE uns SLE im Einklang gebracht. Damit veröffentlichen die Entwickler die zweite Hauptversion der Leap Reihe nach Leap 42.

openSUSE Leap 15 wird den Kernel  4.12 von SLE 15 übernehmen. Bei Leap 42 war immerhin schon der Kernel 4.4 im Einsatz. Das könnte Benutzer sehr neuer Hardware vielleicht etwas in Bedrängnis bringen.

Bei den Desktops wird Leap 15 auf KDE Plasma 5.12, Gnome 3.26, Mate 1.18, XFCE 4.12 aufrüsten. Es werden auch LXDE und LXQt verfügbar sein.

Der Kernel 4.12 und Der Desktop KDE Plasma 5.12 werden beide als s.g. LTS (Long-Term-Support) Versionen ausgeliefert.

openSUSE Leap 15 wird als neue Hauptversion aber keine grundlegenden Neuerungen mit sich bringen, die eingefleischte openSUSE User eventuell aus der Bahn werfen könnten. Es wird sich vorwiegend um Aktualisierungen der verwendeten Komponenten, wie Desktops, Bibliotheken und Pakete handeln. Zudem gibt es einige Modernisierungen beim Design, was aber mehr das Ergebnis der aktualisierten Desktops ist.

openSUSE hat deutlich an der Installationsroutine gearbeitet. Einige Punkte, die bei den vorigen Versionen widersprüchlich, teils zu kompliziert oder auch schwer verständlich waren, sind überarbeitet und aufgeräumt worden. Zum Beispiel war die Partitionierung durch die Anzeige der ganzen Subvolumes für viele zu verwirrend. Da diese jetzt standardmäßig wieder ausgeblendet sind, hat man mehr Übersicht über die wirklichen Partitionen.

openSUSE Leap 15 wird mit seiner Software- und Paketauswahl auf Stabilität ausgelegt sein. Wer mehr Wert auf aktuellste Programme und Pakete legt, sollte sich openSUSE Tumbleweed ansehen.

openSUSE Leap 15 kann auf der Projektseite als 64 Bit DVD Images (3,6 GB) oder als 64 Bit Netimages (118 MB) heruntergeladen werden. Das Netimage lädt bei der Installation alle ausgewählten Komponenten von den openSUSE Servern nach. Es sollte also schon eine recht gute Internetverbindung bestehen. 32 Bit Versionen werden, wie auch schon bei Leap 42, nicht angeboten.

Neu ist aber, dass wieder zwei Live Images zum Download bereit stehen. Ein KDE Live Images (859 MB) und ein Gnome Live Images (909 MB).

Für den Betrieb von openSUSE Leap 15 ist lt. Entwickler folgende Hardware empfehlenswert:

• 2 GHz Dual-Core-Prozessor oder besser

• 2 GB System-Speicher

• Mehr als 40GB freier Festplattenspeicher

• Entweder ein DVD-Laufwerk oder USB-Port für das Installationsmedium

• Ein Internetzugang ist hilfreich, und für den Netzwerk-Installer erforderlich

Wenn man bereits ein openSUSE System verwendet, kann man das bestehende System recht einfach upgraden, indem man im DVD/USB-Bootmenü Upgrade auswählt oder ein ‚Online Upgrade‘ mit einigen wenigen Kommandos durchführt.


Mittwoch
09. Mai 2018


face

Grid Autosport 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 Gran Tourismo 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.

Der Startbildschirm von Grid Autosport auf openSUSE

Das Problem

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:

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

Hier liegt also eine Inkompatibilität zwischen der vom Spiel mitgebrachten Curl-Bibliothek und den von Steam mitgebrachten Bibliotheken SSL und Crypto vor.

Die Lösung aus dem Netz

Beim Googeln findet sich schnell eine Lösung welche vorschlägt libcrypto.so.1.0.0 aus der Steam-Runtime entfernen. 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


Dienstag
24. April 2018


face

openSUSE Tumbleweed enthält jetzt zwei neue Pakete welche ich erstellt habe: python-emoji und python-ntfy. Ersteres hat es sogar noch in openSUSE Leap 15.0 geschafft.

Die Funktionalität von python-emoji ist schnell erklärt und trotzdem unglaublich nützlich, wie diese leichte Abwandlung des Beispiels aus der Paketbeschreibung auf PyPI zeigt:

>> import emoji
>> print(emoji.emojize('Python ist :thumbs_up:'))
Python ist 👍

Natürlich funktioniert dies sowohl in modernem Python als auch in klassischem Python.

Eines der Pakete welche von python-emoji profitieren ist python-ntfy. python-ntfy 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 ntfy done. 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. 😉


Montag
01. Januar 2018


face

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 im Wiki von openSUSE detailliert dokumentiert. Mit wenigen kleinen Änderungen lässt sich so auch openSUSE Leap auf dem Raspberry Pi 2 nutzen, und zwar ohne an diesen Monitor oder Maus anschließen zu müssen.

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 http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/. Für den Betrieb ohne Tastatur und Monitor bietet sich die Variante Just enough OS (JeOS) an. Damit findet man die passende Datei indem man die Downloadseite nach JeOS-raspberrypi2 durchsucht. Aktuell ist dies http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz. Es empfiehlt sich auch die Prüfsumme zu checken.

> 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

Die Warnung zu den nicht formatierten Zeilen liegt daran, dass der Inhalt mit PGP signiert ist. Die Signatur lässt sich mit GPG prüfen.

> 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

Jetzt wo klar ist, dass das Image nicht beschädigt ist, kann man der Anleitung für Tumbleweed im openSUSE-Wiki folgen.

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 dmesg 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 (sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)) und die Partitionsliste (sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3) ausgegeben.

> 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 

Samstag
16. September 2017


face

Wer das Handling von Tätigkeiten mit Administratorenrechten (“Root”) wie ich aus der Debian-Welt gewohnt ist, wird mit openSUSE zu Anfang so seine Schwierigkeiten haben. Mit zwei Benutzern geht es noch, da man ja das selbe Passwort sowohl für den User als auch für Root einstellen kann. Aber spätestens bei mehr Nutzerkonten ist damit schon Schluss, außer man gibt das Root-Passwort an alle weiter. Beide Lösungen sind sicher irgendwie praktikabel, aber schön ist das alles nicht. Vor allem weil ja eigentlich sudo installiert wäre – aber nur so halbgar genutzt wird.

Also habe ich mal bei meiner aktuellen openSUSE Tumbleweed daran gemacht, dem System ein vernünftiges sudo-Konzept beizubringen und dieses dann auch für YaST anzuwenden. Das war etwas fieselig herauszufinden, hat am Ende aber gut funktioniert.

Los geht’s!

visudo

Standardmäßig fragt sudo nach dem Root-Passwort. Das ist ziemlich unsinnig, also ändern wir es!

  1. Im ersten Teil arbeiten wir noch als normaler Benutzer. Die Zeilenangaben können abweichen, je nach Alter der Datei/Systemversion und vorherigen Änderungen daran.

    sudo visudo
  2. Die Parameter in Zeile 43 beginnend mit env_keep = “LANG… ergänzt du am Ende innerhalb der Anführungszeichen mit:

    DISPLAY XAUTHORITY
  3. Die Zeilen 68 und 69 kommentierst du komplett aus, damit nicht mehr das Passwort des “Zielusers” abgefragt wird:

    #Defaults       targetpw
    #ALL    ALL = (ALL) ALL
  4. Zusätzlich kommentierst du Zeile 81 ein, löschst also das Kommentarzeichen # weg:

    %wheel ALL=(ALL) ALL
  5. Speichern, schließen und dann deine(n) Benutzer entweder über YaST oder direkt im Terminal der Gruppe “wheel” hinzufügen:

    gpasswd -a <dein-username> wheel

    Durch Aus- und wieder Einloggen wird die Änderung dann auch übernommen und sudo möchte ab sofort im Terminal immer dein Benutzerpasswort haben.

YaST

Für die grafische Version von YaST wird PolicyKit zur Authentifizierung genutzt, hier ist noch etwas mehr Arbeit nötig. Ab hier arbeitest du als root, wechsle also mit su – den Account.

  1. Erstelle eine PolicyKit Action für YaST

    vim /usr/share/polkit-1/actions/org.opensuse.pkexec.yast2.policy
  2. Folgenden XML-Block fügst du in die Datei ein. Achte dabei bitte auf Zeilenumbrüche beim Kopieren/Einfügen.

    <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
    <policyconfig>
    
      <action id="org.opensuse.pkexec.yast2">
        <message>Authentication is required to run YaST2</message>
        <icon_name>yast2</icon_name>
        <defaults>
          <allow_any>auth_self</allow_any>
          <allow_inactive>auth_self</allow_inactive>
          <allow_active>auth_self</allow_active>
        </defaults>
        <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/yast2</annotate>
        <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
      </action>
    
    </policyconfig>

    Speichern, schließen – der Erfolg lässt sich als regulärer Benutzer mit pkexec /usr/sbin/yast2 überprüfen.

  3. Die vorgegebene Rechte-Konfiguration sicherst du und ersetzt sie durch die System-Konfiguration. Unsere Datei wird bei einem Upgrade übrigens nicht überschrieben.

    mv /etc/polkit-default-privs.local /etc/polkit-default-privs.local.bkup
    cp /etc/polkit-default-privs.standard /etc/polkit-default-privs.local

    Die nötige Anpassung ist überall auth_admin durch auth_self zu ersetzen. Du kannst


Mittwoch
06. September 2017


face

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.

Ich nutze tatsächlich häufig das Verzeichnis /tmp. 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 virtuellen Python-Umgebungen lege ich, seit mich Holger Peters mal auf diese Idee gebracht hat, stets dort ab. Seit einiger Zeit löschte mir meine openSUSE meine gerade angelegten Dateien aber immer kurz nach dem Systemstart unter der Nase weg.

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 Systemd-Timer.

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

Der alte Cronjob hatte eine Konfigurationsdatei in /etc/sysconfig in der man die Schonzeit für Dateien in /tmp und /var/tmp konfigurieren konnte. Beim Systemd-Job übernehmen die Konfigurationsdateien von systemd-tmpfiles diesen Job. Die dazugehörige Manpage ist tmpfiles.d (5).

Die Standardatei /usr/lib/tmpfiles.d/tmp.conf 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.

# 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 -

Die schuldige Konfiguration fand sich in /etc/tmpfiles.d/tmp.conf. Hier muss, bei einem der vielen Versionsupgrades welche mein System hinter sich hat, ein kleiner Übertragungsfehler passiert sein.

d /tmp 1777 root root 0d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Mit dem Alter Null Tage wird systemd-tmpfiles 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.

d /tmp 1777 root root 1d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Und das schöne an Systemd ist, dass man so eine Änderung dann auch gleich sehr leicht testen kann.

sudo systemctl start systemd-tmpfiles-clean.service

Eine Anwendung welche mit dem agressiven Aufräumen der temporären Dateien gar nicht klar kommt ist übrigens meine früher so geliebter Browser Opera. Nachdem die temporären Dateien weggräumt wurden findet dieser seine bereits laufende Instanz nicht mehr und fliegt dann beim Versuch


Samstag
05. August 2017


face

Nachdem ich meine Workstation von openSUSE 13.1 auf openSUSE Leap 42.1 migriert 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.

Das Problem

Nach dem Update fanden CUDA nutzende Anwendungen keine Grafikkarte. So meldete Boinc No usable GPUs found. Prinzipiell funktionierte die Grafikkarte aber. So hatte ich volle 3D-Beschleunigung, und auch nvidia-smi meldete die erwarteten Daten:

+------------------------------------------------------+
| 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                                               |
+-----------------------------------------------------------------------------+

Die Analyse

NVIDIA bietet CUDA zwar für einige SUSE-Varianten zum Download, 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 OpenCL benötigt man nur die Header, welche man einfach direkt zum Code legen kann, und einen C-Compiler.

Schon der erste Versuch mit einem Beispielprogramm welches nur die OpenCL-Runtime initialisiert zeigt das Problem:

> sudo ./platform
modprobe: FATAL: Module nvidia-uvm not found.
Failed to get platforms: -1001

Das sudo ist hier übrigens nur vorangestellt um es zu ermöglichen Kernel-Module nachzuladen. Ohne sudo erhält man den gleichen Fehler, aber ohne die essentielle Information zum Kernelmodul.

Schnell konnte ich herausfinden, dass eigentlich alle Kernelmodule installiert sind:

> 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

Allerdings war das nicht das Modulverzeichnis des aktuell laufenden Kernels:

> 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

Wo liegen also dessen Module? /lib/modules/4.1.13-5-default/updates existiert nicht. Das NVIDIA-Modul ist aber schnell gefunden:

> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko

Nur fehlt in diesem Verzeichnis das nvidia-uvm.ko.

Die Lösung

Eine Neuinstallation des dazugehörigen Paketes lässt dann endlich auch OpenCL wieder richtig initialisieren:

> 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

Um die Grafikkarte tatsächlich zu verwenden war dann allerdings noch ein Neustart notwendig.


Montag
10. Juli 2017


face

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 http://de.opensuse.org/KDE/KDE4 auch Links zur Installation mit einem Klick. Wer ein x64-System hat oder es sowieso lieber per Hand macht findet hier eine kurze Anleitung.

Zunächst sind in Yast über den Punkt Software-Repositories folgende Repositories hinzuzufügen:

  • http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0/
  • http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0/
  • http://download.opensuse.org/repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop/
Die letzten beiden sind optional, erhöhen aber die Anzahl der zur Verfügung stehenden Anwendungen.

Wie unter http://de.opensuse.org/KDE/KDE4 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 nichts bietet libqt-x11 >= 4.4.2 benötigt von kdebase4-runtime-4.1.1-48.2.i586.

  • http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/

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.


Sonntag
08. Januar 2017


face

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

Achtung: 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 nicht mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.

Ist ein USB-Stick als Schlüssel sicher?

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.

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.

Die Anleitung

Backup

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.

Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl mkinitrd sonst dennoch aktualisiert werden.

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
Außerdem sollte man sich der Einfachheit halber gleich einen passenden Eintrag im Grub anlegen, wozu man in der Datei /boot/grub/menu.lst die passenden Zeilen einfügt:
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 


Montag
19. Dezember 2016


face

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 dessen Supportendes, 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 openSUSE Leap 42.2 durch. Wie bei jeder Rechnerneuinstallation stolperte ich dabei über ein paar Eigenarten, aber insgesamt läuft das System wunderbar.

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.

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.

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.


Montag
05. Dezember 2016


face

Da es für meine geneigte Leserschaft (auch die in den Planeten von OSBN und Debianforum.de) vielleicht interessant ist oder jemand jemanden kennt: Mein Arbeitgeber sucht derzeit Mitarbeiter für Kundenbetreuung, Support & Service im Bereich Linux.

Zur Verstärkung unseres Teams in Königsbrunn suchen wir Sie.

Wir freuen uns auf Sie als:

Mitarbeiter (m|w) Kundenbetreuung, Support & Service

Ihre Aufgaben in unserem Haus umfassen:

  • Durchführen von Hardwaretestes
  • Technische Beratung und Unterstützung von Kaufinteressenten telefonisch als auch in schriftlicher Form, vorwiegend per E-Mail
  • Technische Hilfestellung bei Fragen zu Betriebssystemen der Linuxfamilie, insbesondere Ubuntu
  • Prüfung von Kundengeräte auf Hard- oder Softwarefehler sowie deren Beseitigung

Mehr Infos gibt es im Firmenblog. Für Rückfragen stehe ich natürlich auch gerne zur Verfügung.


Donnerstag
17. März 2016


face

AMD Catalyst 15.12 (fglrx 15.302) (Radeon Crimson Edition) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-15.12.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1, 13.2, 42.1 und Tumbleweed sowie bis Kernel 4.5 (offiziell nur bis Kernel 3.19).

Hinweis: Unter openSUSE Tumbleweed wird der AMD Treiber nicht funktionieren. Die Version vom X-Server ist zu neu für den Treiber.

Ab sofort wird die Integrität der heruntergeladenen Dateien mit SHA256 geprüft. SHA1 ist somit obsolet und sollte besser nicht mehr verwendet werden.

Neues Feature vom Packaging Skript:

  • systemd Support für den automatischen Bau des fglrx-Kernelmodules (openSUSE 13.2 und höher)

Gelöste Probleme:

  • [SWDEV-82980] Ubuntu 15.10 fails when building the .deb packages

Link: AMD Catalyst 15.12 Release Notes

Folgende Steam-Spiele habe ich getestet und laufen mit diesem Treiber (Fettdruck = Neu):


Samstag
12. März 2016


face

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.

Meine Workstation nutzt ein vermutlich nicht ganz gewöhnliches Set-Up. OpenSUSE ist parallel zu Windows 10 installiert, und beides wird per UEFI Secure Boot 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 BIOS-Boot, 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 PEBKAC 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.

Leider tritt einem beim Versuch die DVD mit openSUSE Leap 42.1 per UEFI zu booten Bug 950569 in den Weg. Der Bootcode auf der DVD ist nicht korrekt signiert, was auf meinem System zufolge hat, dass der Bildschirm einfach schwarz bleibt. Das Problem lässt sich lösen, indem man Secure Boot im BIOS temporär deaktiviert. 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.

Ein weiteres Problem bei openSUSE Leap 42.1 ist, dass es zumindest bei Upgrades nicht korrekt mit verschlüsselten Root-Partitionen umgehen kann. Beim Boot „vergisst“ das System nach der Passphrase zu fragen. Wechselt man durch die Konsolen findet zeigt sich folgende Fehlermeldung: Failed to start systemd-cryptsetup@luks<codierte ID>.service:. Ich habe die ID in der Fehlermeldung mal gekürzt ;). Wie in Bug 904987 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 rd.luks.uuid mitgibt.

Die ID des LUKS-Containers lässt sich mit Cryptsetup herausfinden. Liegt die Root-Partition z.B. auf /dev/sda2, so lässt sich die ID wie folgt herausfinden.

> cryptsetup luksUUID /dev/sda2
07246af2-915a-bd54-6a5s-6a5c35d15f45
Der Bootparameter muss

Ältere Artikel ->