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.


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 

Dienstag
26. Dezember 2017


face

There is this old quote from LKML:

Get back there in front of the computer NOW. Christmas can wait.
[Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel]

The AppArmor developers followed this advise - John released AppArmor 2.12 yesterday (Dec 25), and I just submitted updated packages to openSUSE Tumbleweed (SR 560017).

The most visible changes in 2.12 are support for "owner" rules in aa-logprof and upstreaming of the aa-logprof --json interface (used by YaST). Of course that's only the tip of the christmas cookie ;-) - see the Release Notes for all details.

One important change in the openSUSE packages is that I intentionally broke "systemctl stop apparmor". The reason for this is "systemctl restart apparmor" - systemd maps this to stop, followed by start. This resulted in unloading all AppArmor profiles by the "stop" part and, even if they get loaded again a second later, running processes will stay unconfined unless you restart them. The systemd developers were unwilling to implement the proposed ExecRestart= option for unit files, therefore breaking "stop" is the best thing I can do. (See boo#996520 and boo#853019 for more details.)

"systemctl reload apparmor" will continue to work and is still the recommended way to reload the AppArmor profiles, but accidently typing "restart" instead of "reload" can easily happen. Therefore I chose to break "stop" - that's annoying, but more secure than accidently removing the AppArmor confinement from running processes.

If you really want to unload all AppArmor profiles, you can use the new "aa-teardown" command which does what "systemctl stop apparmor" did before - but who would do that? ;-)

Note that the above (except the recommendation to use "reload") only applies to Tumbleweed and Leap 15.


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


Sonntag
20. August 2017


face

Ich habe mal eine einfache openSUSE Tumbleweed Installation auf einem Single-Bootsystem in VirtualBox als Video aufgenommen. Diese soll nur mal für openSUSE Neulinge oder Umsteiger zeigen, wie der openSUSE Installationsprozess im Gegensatz zu anderen Linux Distributionen oder sogar zu Windows so abläuft und was da so auf einen zukommt.

 



 


Freitag
18. August 2017


face

Telegram ist für mich eine sehr wichtige Messenger-Alternative zu den anderen Platzhirschen.

Warum Telegram?

Weil Telegram neben vielen anderen Vorteilen, auf die ich hier gar nicht weiter eingehen will, zum Ersten einen super Desktop Client für Linux hat und zusätzlich noch einen klasse Web-Client für den Browser. Und um diese geht es mir hier heute. Es macht sich schon recht gut, wenn man den Messenger seiner Wahl auch am Rechner/Laptop ( notfalls auch im Büro 😉 ) mit einer richtigen Tastatur bedienen kann. Und welcher Messenger kommt mit diesen Features sonst noch für uns Linuxer in Frage?

Wer sich gerne weitere Details und Antworten zu Telegram ansehen möchte, kann sich gerne unter https://telegram.org/faq/de belesen. Die Informationen sind in deutsch und es werden viele Fragen beantwortet. Z. Bsp. Wie unterscheidet sich Telegram von WhatsApp? oder Was ist Telegram? u.s.w.

Der Telegram Linux Desktop Client.

Auf der Seite https://desktop.telegram.org/ kann man sich für Linux jeweils ein entsprechendes 32 Bit oder ein 64Bit *.tar.xz Archiv herunterladen.

Auf https://telegram.org fängt alles an. Hier bekommt man alle Versionen für die verschiedenen Plattformen. Wenn man auf „Telegram für PC/Mac/Linux“ klickt …

kommt man zu einer Downloadoption, bei der die Seite an Hand deines Systems schon erkennt, welcher Download für dein System der richtige ist. Alternativ kannst du mit dem Link darunter, weitere Downloads für andere Plattformen aufrufen.

Hier kannst du dann auch für ein anderes System den Telegram-Client oder auch ein 32Bit Paket herunter laden.

Kleine Anmerkung für die Windowsuser: Für Telegram ist auch eine portable Version für Windows verfügbar. 😉

Tja wenn man sich dann für den richtigen Download entschieden hat, speichert man das entsprechende *.tar.zx Archiv auf seinem Computer.

Das herunter geladene Archiv findet man anschließend in seinem Downloadordner.

Dieses Archiv entpackt man jetzt entweder gleich in seinem Homeverzeichnis oder macht es etwas umständlich, wie ich hier und entpackt es erst in dem aktuellen Verzeichnis und verschiebt das Ergebnis dann in den Homeordner. Letzteres ist zwar etwas umständlich, aber beides kommt auf’s Selbe raus.

Nachdem das Archiv entpackt ist und der Ordner „Telegram“ bereit steht, ist es eigentlich unwichtig, in welchem Ordner er sich selbst befindet. Das Verschieben diente hier bei mir nur der Übersicht und der Ordnung. 😉

So sieht das Ergebnis bei mir aus.

In dem Ordner „Telegram“ befinden sich nur zwei Dateien. Einmal eine Datei mit dem gleichen Namen wie der Ordner „Telegram“ und eine Datei namens „Updater“. Die Programmdatei, die ihr durch einen Mausklick (zumindest bei KDE) starten müsst, ist logischerweise „Telegam“. Wer hätte das gedacht? ;-]

Dann geht es auch schon los.

Hier musst du jetzt deine Handynummer eintragen, auf dem du bereits eine Telegram-App am Laufen hast. Wie es dort auch steht: OHNE die erste Null der Telefonnummer.

Darauf hin sendet Dir Telegram eine Codenummer an dein Telegram auf deinem Handy. Diese Codenummer musst


Freitag
11. August 2017


face

openSUSE Tumbleweed ist ja bekanntlich die Rolling-Release-Version von openSUSE mit den immer neuesten stabilen Paketversionen. Tumbleweed ist die openSUSE Version für Anwender, die ein bisschen mehr Aufwand bei der Pflege Ihres Systems nicht scheuen und dafür immer die neueste, aber stabile Software bekommen. Ich zähle mich selbst nicht gerade dazu. Mir liegt die Leap Ausgabe einfach mehr. Nicht zuletzt war bei mir persönlich auch immer die bisherige umständliche Installation des Nvidia Grafiktreibers bei Tumbleweed unter anderem ein Grund doch lieber bei openSUSE Leap zu bleiben.
Denn bislang mussten Nutzer von Tumbleweed den proprietären Nvidia-Grafikkartentreiber manuell installieren und jedes mal bei einem der zahlreichen Kernel-Updates auch manuell aktualisieren. Das war zwar nicht unmöglich und genügend Anleitungen in diversen Foren gibt es auch, aber es war nervig. Ich kam deshalb auch mit Tumbleweed nicht über einige Versuche hinaus.
Ab sofort gibt es aber nun auch für openSUSE Tumbleweed unter der Adresse „https://download.nvidia.com/opensuse/tumbleweed“ein Repository mit dem Nvidia Grafiktreiber. Dieses Verzeichnis mit dem Repository lässt sich übrigens nicht mittels eines Browsers einsehen.
Um unter Tumbleweed dieses Repository schnell hinzuzufügen startet man die Konsole und gibt folgendes ein:

zypper ar https://download.nvidia.com/opensuse/tumbleweed nvidia-tumbleweed

Anschließend installiert man den Treiber mit:

zypper inr

Alternativ kann man beides auch fix per YaST erledigen.

Das benötigte Kernel-Modul des Nvidia-Treibers wird sowohl bei der Installation des Paketes, als auch nach einem Kernel-Update automatisch gebaut.

Stefan Dirsch weist auf der openSUSE-Mailingliste darauf hin, dass unter Umständen GDM Probleme auftreten können. In  diesem Fall sollen Anwender auf XDM oder eine andere Alternative wechseln.

Quelle: openSUSE Mailingliste

https://lists.opensuse.org/opensuse-factory/2017-08/msg00281.html


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.


Mittwoch
02. August 2017


face

In den Release Notes von openSUSE Leap 42.3 weisen die Entwickler darauf hin, das „nathlose Upgrade“ auf Leap 42.3 zu nutzen. Ich habe das mal auf eine andere Art ausprobiert.

Bisher habe ich für Versionsupgrades immer den Weg über das suseeigene Konsolenprogramm „zypper“ empfohlen und beschrieben. Andere Distributionen sind da schon weiter und bieten komfortablere Werkzeuge für diese Aufgabe an. (siehe z.Bsp. Linux Mint) Obwohl, das Upgrade mit zypper ist eigentlich äußerst komfortabel, überaus leicht zu bewerkstelligen und schnell erledigt. Also eigentlich optimal. Hat immer sehr gut bei mir funktioniert.

Aber aus irgendeinem Grund 😉 mögen Linux-Neulinge ( und für diese mache ich das hier) unsere geliebte Konsole nicht so richtig. Also dachte ich mir, muss es auch bei openSUSE einfach und ohne den Ausflug in die Welt der Textkonsole funktionieren. Einfach soll es sein! Nur mit YaST! Also mal los.

Das bei so einem Upgrade immer mal wieder etwas schief gehen kann und man sich vorher mit entsprechenden Sicherungen und Backups sorgfältig absichert, baue ich in diesem Artikel nicht mehr weiter aus, weil es oft genug erwähnt wurde.

1. YaST als Root starten

Das openSUSE Konfigurationstool YaST muss als Root gestartet werden. Dazu braucht man aber nur ganz normal das Icon anklicken. Die Passwortabfrage für Root kommt automatisch.

2. Vorbereitung: Software Quellen (Repositories) auf Leap 42.3 umstellen

In YaST wählt man unter dem Punkt „Software“ die „Software Repositories“ mit einem Mausklick aus

Bei den Repositories wählt man jeden einzelnen Eintrag aus und klickt anschließend auf „Bearbeiten“

Bei JEDEM Repository bzw. Eintrag, bei dem die Versionsnummer (in diesem Fall die 42.2) auftaucht, ändern wir diese in 42.3.

So muss es nach dem Ändern aussehen und mit „Ok“ bestätigen.

Letztendlich muss es dann bei ALLEN Repositories SO aussehen. Alle Repos müssen auf die neue Version umgestellt sein.

Wenn ein Repo dazwischen ist, welches gar keine Versionsnummer beinhaltet, so ist es Versionsunabhängig und kann unverändert bleiben.

Danach kann man die Repository Übersicht mit einem Klick auf „Ok“ schließen.

3. Upgradevorgang

Als nächstes starten wir in YaST den Menüpunkt “ Software installieren oder löschen“

In diesem YaST Fenster klicken wir mit der linken Maustaste nacheinander auf den Menüpunkt „Paket“ , dann auf „Alle Pakete“ und zuletzt auf „Aktualisieren falls neuere Version verfügbar“.

Die darauf folgende Information bestätigen wir mit „Fortfahren“

Jetzt kommt in der Regel, abhängig vom eigenen Umfang der bestehenden Installation, eine Warnung von Abhängigkeitskonflikten. Dies ist für viele die eigentliche Schwierigkeit und die größte Hürde bei diesem Vorgang.

Eine allgemeingültige Empfehlung für diesen Vorgang gibt es auf Grund der vielen individuellen Installationsmöglichkeiten nicht. Wichtig und Richtig ist: Die Konflikte müssen aufgelöst werden. In meinem Fall war es recht einfach, weil ich nur die Installation der neueren Version auswählen brauchte. Also auf dem Screenshot ist das der Punkt 2. “ Ersatz von Paket sowieso mit Version 1.2


Mittwoch
26. Juli 2017


face

Es ist zwar schon ein paar Tage her, aber trotzdem will ich es nicht übergehen. Wie angekündigt hat openSUSE die Version Leap 42.3 veröffentlicht. Nachdem das openSUSE Projekt in den vergangenen zwei Jahren alles etwas umstrukturiert hat, kann man jetzt die openSUSE Leap Ausgabe zwischen der ständig aktuellen Rollingelease Ausgabe Tumbleweed und der Unternehmensversion Suse Linux Enterprise Server (SLES) einordnen. Mit dieser dritten Ausgabe von openSUSE Leap 42 rücken die Communityversion und die Unternehmensversion nach eigenen Angaben der Entwickler noch enger zusammen, denn beide Ausgaben nutzen nun die selbe Codebasis.
Im Große und Ganzen ist die Ausgabe 42.3 eine Vielzahl von Aktualisierungen der Pakete, Desktops, des Kernels und verschiedener Treiber und Module. Dadurch wird die openSUSE Leap 42.3 in Sachen Funktionalität, Stabilität und Hardwareunterstützung modernisiert.
OpenSUSE Leap 42.3 setzt, wie bei openSUSE gewohnt, als Standarddesktop KDE Plasma in der Version 5.8 mit Qt 5.6.2 ein. Zur Auswahl stehen aber selbstverständlich auch andere Desktops, wie z.Bsp. Gnome 3.20 oder Xfce, LXDE, Lxqt oder Mate. Das Desktop Auswahlmenü bei der Installation soll neu gestaltet sein und ich bin schon gespannt darauf es zu sehen.
Diverse Verbesserungen sollen auch bei openSUSE’s einzigartigem Konfigurationstool YaST eingeflossen sein. Die Installation mit SecureBoot und bei EFI Systemen ist verbessert und die Netzwerkoptionen ausgebaut worden.
Eine neue Backup Software namens Borg ist ab sofort in openSUSE enthalten. Diese soll sich mittels eines systemd-Wrappers automatisch um Backups kümmern.
Laut Angaben der Entwickler soll die Verwendung und Installation von openSUSE als Serversystem mit dieser Ausgabe deutlich verbessert worden sein. Dazu hat man den guten alten Textinstaller so aufgebohrt, dass er die selbe Funktionalität besitzt wie das grafische Installationsprogramm. Der Installer soll jetzt komplette Installationen auf entfernte Rechner remote per VNC oder SSH erledigen können. Na das probieren wir doch aus. 😉

Auch Spiele werden auf Linux immer beliebter. openSUSE Leap 42.3 will ein stabiles System bereitstellen um die beliebte Spieleplattform Steam laufen zu lassen. Für Spiele, die noch nicht für Linux verfügbar sind, sind Wine und PlayOnLinux in dieser Ausgabe wieder mit dabei.

Download:

openSUSE Leap 42.3 gibt es nur noch als 64 Bit Version. 32 Bit Versionen werden nicht mehr zur Verfügung gestellt. Es werden zwei Downloadmedien pro Architektur angeboten.

Für Intel 64-bit (x86_64): Die DVD/USB-Stick Variante mit 4,7 GB oder die Netzwerkinstallation mit 85 MB.
Für PowerPC Little Endian (ppc64le): Die DVD/USB-Stick Variante mit 4,2 GB oder die Netzwerkinstallation mit 71 MB.
Für ARMv8 64-bit (aarch64): Die DVD/USB-Stick Variante mit 3,8 GB oder die Netzwerkinstallation mit 91 MB.

Live-Medien sucht ihr von den aktuellen openSUSE Leap Medien vergeblich. Offizielle werden solche nicht mehr angeboten. Dafür gibt es aber nicht offiziell unterstützte Live Medien von der Tumbleweed Ausgabe.

openSUSE Tumbleweed gibt es auch weiterhin als 32 Bit Version neben der 64 Bit Ausgabe. Es werden zwei Downloadmedien pro Architektur angeboten


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.


Montag
24. April 2017


face

openSUSE wird mal wieder die Versionsnummernvergabe ändern. Derzeit ist die Version openSUSE Leap 42.2 aktuell. Im openSUSE – Downloadportal kann man aktuell Leap 42.3 als  Entwicklerversion zum Testen herunterladen. Die 42.3 soll demnach diesen Sommer 2017 als Nachfolger erscheinen. Danach war dann eigentlich die Versionsnummer Leap 43 geplant gewesen. Daraus wird jetzt wohl nichts mehr. Hier greift jetzt die angekündigte Änderung.

Um mit der aus dem selben Haus stammenden Suse Linux Enterprise Ausgabe letztendlich die Ausgabeversionsnummern zu synchronisieren, sprich gleichzuziehen, kommen danach beide Varianten, openSUSE Leap und SUSE Linux Enterprise mit der Versionsnummer 15.x raus. Dies war jetzt deutlich vereinfacht ausgedrückt. OpenSUSE Vorstand Richard Brown hat es auf der Entwicklerliste (englisch) weit ausführlicher begründet und erläutert. Auf Pro-Linux.de oder Linux-Magazin.de kann man es ausführlicher in deutsch nachlesen.

Quellen: openSUSE- Mailingliste, Pro-Linux.de (von Ferdinand Thommes) , Linux-Magazin.de (von Ulrich Bantle)


Dienstag
21. März 2017


face

OpenSUSE Leap 42.1 ist im November 2015 erschienen und wird demnach im kommenden Mai 1 1/2 Jahre alt. Nach dem openSUSE Zeitplan heißt das, das es wahrscheinlich  nach dem 16. Mai 2017 keine weiteren Sicherheitsupdates und Aktualisierungen mehr geben wird. Das ist lt. openSUSE’s Plan genau sechs Monate nach dem Erscheinen der Folgeversion Leap 42.2 und somit der angekündigte Supportzeitraum. Benutzer von Leap 42.1 sollten langsam über einen Wechsel auf openSUSE Leap 42.2 nachdenken. 

Das zumindest gestaltet sich aus meiner eigenen Erfahrung recht einfach. Da es das Konzept der Leap Reihe ist, das die Basis des Systems stets gleich bleibt funktionieren die Upgrades auf die nächste Version problemloser als früher.

Ich habe vor kurzem gerade selbst insgesamt vier verschiedene openSUSE Leap 42.1 Installationen mit „zypper dup“ auf Leap 42.2 problemlos aktualisiert. Und es handelte sich um echte Arbeitssysteme, bei denen auch zusätzliche Repos und haufenweise zusätzliche Software installiert war. Lief alles problemlos durch! 

In diesem Artikel von 2010 habe ich bereits über ein komplettes Versionsupgrade und den Ablauf bzw. die Vorgehensweise mit zypper berichtet. Er ist immer noch aktuell.

Quelle: Pro-Linux, openSUSE-Mailingliste


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.


Donnerstag
01. Dezember 2016


face

Ich weiß, ich weiß. Ich bin viel zu spät dran. Aber da ich anderweitig gebunden war, möchte ich es jetzt doch der Vollständigkeit halber nachreichen.

openSUSE Leap 42.2 hat am 16.November 2016 das Licht der Welt erblickt.

Als Basis dient ja bei diesem openSUSE Leap 42.2 das eigentlich für Unternehmen gedachte SUSE Linux Enterprise 12 mit Service Pack 2.

Die Entwickler haben dieses um weitere aktuelle Software ergänzt und erweitert.

Was bringt openSUSE Leap 42.2 denn nun mit.

  • KDE Plasma 5.8 LTS
  • Qt 5.6
  • KDE Frameworks 5.26
  • KDE PIM-Suite in Version 4 und in Version 5
  • weitere Desktops: GNOME 3.20, LXQt 0.11.0, Enlightenment, MATE, Xfce oder Cinnamon
  • LibreOffice 5.1.5
  • Firefox 49.0.2
  • Samba Version 4.4.2
  • Kernel 4.4 LTS
  • Systemd 228
  • QEMU 2.6.1
  • VirtualBox 5.0.24
  • Docker Version 1.12

Die Installation kann man jetzt auch vie VNC oder SSH im Textmodus vornehmen. Den Textmodus aktiviert man im Boot-Menü mit [F3] oder mit dem zusätzlichen Boot-Parameter „textmode=1“.

openSUSE Leap 42.2 benutzt standardmäßig Btrfs für die Root-Partition und unterteilt diese in mehrere Subvolumes. Für die Home-Partition wird XFS verwendet.

 

openSUSE Leap gibt es ja seit 42.1 nur noch in einer 64-Bit-Version. Das Images umfasst 4,1 GByte. Diese kann auch „nur“ zur Installation genutzt werden.  Ein openSUSE Live-System wird nicht mehr zur Verfügung gestellt. Alternativ kann man auf ein Netzwerkinstallationsmedium ausweichen. Das umfasst ca. 95 MB und lädt während der Installation den jeweils aktuellsten Stand der Pakete aus den Repositories nach. Hat den Vorteil, dass man nach einer Installation mit einem etwas angestaubten Installationsmedium nicht den ganzen Updateprozess hinterherziehen muss. Voraussetzung ist aber, dass man über eine recht zügige Internetverbindung verfügt, sonst wird es ein sehr langwieriger Spaß.

Etwas anders sieht es bei openSUSE Tumbleweed aus. Auf der Seite https://en.opensuse.org/openSUSE:Tumbleweed_installation finden sich sehr wohl noch Images und Medien für 32 Bit Architektur und Live CD Images mit KDE oder Gnome Desktop oder auch die gute alte Rescue-CD.

 


Donnerstag
06. Oktober 2016


face

Die openSUSE Entwickler haben planmäßig ( oder sogar einen Tag früher 😉 ) die 3. Beta von openSUSE Leap 42.2 herausgebracht. In dieser letzten Beta auf dem Weg bis zum finalen openSUSE Leap 42.2 am 16.November 2016 haben die Entwickler als offensichtlichste Neuerung gegenüber den früheren Betaversionen KDE Plasma auf die Versionsnummer 5.8.0 angehoben. Immerhin hat das KDE Projekt vor Kurzem bekannt gegeben, dass  Plasma 5.8 eine LTS Version wird und somit für 18 Monate unterstützt wird. KDE-Anwendungen haben in der Beta 3 auch ein Update auf Version 16.08.1 erhalten. Außerdem wurden diverse andere Pakete aktualisiert. Z.Bsp. wurde VirtualBox  auf Version 5.1.4 aktualisiert, Firefox 49 ist dabei und Thunderbird hat mit der Version 45.3.0 einige Sicherheitsupdates bekommen.

Weitere Neuerungen werden in diese Entwicklung für openSUSE Leap 42.2 nicht einfließen. Bis zur Veröffentlichung sind nun noch zwei Release Candidaten am 18.Oktober und am 02.November vorgesehen.

Die openSUSE Leap 42.2 Beta 3 kann zum Testen wie immer bei openSUSE heruntergeladen werden. Tester sind ausdrücklich dazu aufgerufen, gefundene Fehler bei openSUSE Bugzilla einzureichen.

 

Quelle: https://news.opensuse.org/2016/10/05/beta-3-release-updates-firefox-kde-applications-virtualbox/


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


Samstag
05. Dezember 2015


face

AMD Catalyst 15.11 (fglrx 15.30.1025) (Radeon Crimson Edition) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-15.11.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.4 (offiziell nur bis Kernel 3.19).

Ich habe den AMD Treiber für den kommenden Kernel 4.4 angepasst. Zur Zeit läuft der AMD Treiber mit Kernel 4.4-rc3 einwandfrei. Leider funktioniert der GNOME Desktopmanager nach wie vor nicht. Als Workaround sei ein alternativer Desktopmanager z.B. lightdm zu empfehlen.

[UPDATE 07.12.2015]
Anscheinend ist die Release Notes zur Radeon Crimson Edition nicht vollständig gewesen. Es gibt eine gute und leider auch eine schlechte Nachricht. AMD hat die Unterstützung einiger noch recht aktuelle Grafikkarten aus dem aktuellen Treiber gestrichen. Offenbar nicht alle genannten Grafikkarten, was wiederum zu einem bedauerlichen Glücksspiel wird.

Es betrifft folgende Grafikkarten:

  • Radeon HD 5000 Serie
  • Radeon HD 6000 Serie
  • Radeon HD 7000 – 7600 Serie
  • Radeon HD 8000 – 8400 Serie

Wer noch eine Grafikkarte dieser Sorte hat, sollte besser bei AMD Catalyst 15.9 bleiben oder auf den vom Kernel mitgelieferten Radeon Treiber umsteigen.

AMD arbeitet zur Zeit mit höherer Priorität am freien AMD Treiber amdgpu. Einsehbar in den Git-Repositorien Kernel-Entwicklungszweig und PowerPlay-Entwicklungszweig. Im Gegensatz zum Radeon-Treiber sollte die Performance, das Powermanagement sowie der Re-Clocking Support via PowerPlay-Patch besser mit amdgpu funktionieren und wird im Kernel 4.5 voraussichtlich im nächsten Jahr Februar/März 2016 integriert sein.

Quelle: AMD Radeon™ Software Support for Legacy Graphics Products
Quelle: AMDGPU With PowerPlay Compared To AMD’s Catalyst Linux Driver
Quelle: AMD Publishes AMDGPU PowerPlay Support For Re-Clocking / Power Management
[/UPDATE 07.12.2015]

Gelöste Probleme:

  • [SWDEV-55204] Stuttering when running glxgears with VSync enabled
  • [SWDEV-7339] Intermittent mouse cursor corruption

Link: AMD Catalyst 15.11 Release Notes

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


Sonntag
27. September 2015


face

AMD Catalyst 15.9 (fglrx 15.201.1151) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-15.9.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 und Tumbleweed sowie bis Kernel 4.2 (offiziell nur bis Kernel 3.19).

Wichtiger Hinweis: Die erste Beta-Version von openSUSE Leap (zukünftige openSUSE 42.1) wurde vor wenigen Tagen veröffentlicht. Jedoch wurde der AMD Treiber noch nicht an die neue Version angepasst. Dazu werde ich mich in den nächsten Tagen näher beschäftigen und ein weiteres Update bereitstellen.

Ein weiterer Hinweis: Nach einigen Experimenten mit dem GNOME Desktopmanager konnte ich ihn nicht zum Laufen bringen. Da scheint tatsächlich etwas im Argen zu sein. Hierzu werde ich die AMD Entwickler kontaktieren. Als Workaround empfehle ich für GNOME einen anderen Desktopmanager wie z.B. lightdm bis das Problem behoben ist.

[UPDATE 09.11.2015]
Das Packaging Script wurde aktualisiert. Es wird ab sofort openSUSE Leap 42.1 und Kernel 4.3 unterstützt. Have a lot of fun! ;-)
[/UPDATE 09.11.2015]

Gelöste Probleme:

  • [425910] Driver installation sometimes fails on Ubuntu 14.04.3
  • [424450] Company of Heroes® 2 – Game crashes while running the performance test
  • [424794] Middle-earth™: Shadow of Mordor – Corruption observed in game
  • [424882] DIRT® Showdown – Corruption observed in game
  • [425234] DIRT® Showdown – Game crashes after the loading screen
  • [424802] DOTA™ 2 – Application hang observed while exiting the game
  • [424255] AMD Catalyst™ Installer removing EGL links resulting in Xserver/Xorg load failure
  • [423471] Unable to switch desktop mode after installing AMD Catalyst™ driver
  • [423735] Renaming Counter-Strike: GO and other Steam game binary improves performance

Bekanntes Problem:

  • [419960]: Vari-Bright on some configurations is not decreasing brightness as expected

Link: AMD Catalyst 15.9 Release Notes

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


Samstag
22. August 2015


face

Am 18. + 19. September 2015 (Freitag + Samstag) findet in Kiel die 13. Kieler Open Source und Linux Tage statt. Der Eintritt ist frei. Diesmal ist openSUSE zum ersten Mal in Kiel dabei und erobert nun Schleswig-Holstein – das Land der Horizonte bzw. der echte Norden. Dem Besucher werden interessante Ausstellungen und ein umfangreiches Programm an Vorträgen wie auch Workshops angeboten. Es finden wieder LPI-Prüfungen (Linux Essentials, LPIC-1, LPIC-2, LPIC 3, Univention UVCP) statt.

Am openSUSE-Stand kann jeder Besucher die openSUSE-Distribution einmal Live ausprobieren und sich vom openSUSE-Team beraten lassen. Außerdem werde ich einen Vortrag zu „openSUSE für den täglichen Einsatz“ halten und richtet sich an Linux-Einsteiger oder Umsteiger. Danach werde ich ein Workshop „openSUSE Installationsparty“ leiten, in dem man unter Anleitung openSUSE direkt auf dem eigenen Notebook installiert und bekommt auch ein paar Tipps und Tricks im Umgang mit openSUSE oben drauf. openSUSE-Installationsmedien (USB-Sticks / DVDs) werden kostenfrei zur Verfügung gestellt und können mitgenommen werden. Wer am Workshop teilnehmen möchte, sollte sich besser mit der Anmeldung beeilen. Da nur maximal 10 Plätze reserviert werden können.

Folgende Aussteller sind vor Ort (alphabetisch):

Quelle: Aussteller auf den Kieler Linuxtagen

Ein Auszug aus dem Programm:

  • Das Internet Spiel (Sven Guckes / Beschreibung)
  • Work-Life-Revenue Balance als OSS Unternehmen (Felix Kronlage / Beschreibung)
  • Reds.io – ein Framework für mehr Privatsphäre in der Cloud (Torben Haase / Beschreibung)
  • So fern und doch so nah, nutzen der priv. Cloud mittels SSH (Marek Walther / Beschreibung)
  • Effiziente Lösungsstrategien für IT-Probleme (Hauke Goos-Habermann / Beschreibung)
  • Der Mailer Mutt (Sven Guckes / Beschreibung)
  • Einfach und sicher: OpenVPN mit 2 Faktor Authentisierung auf UCS (Felix Kronlage / Beschreibung)
  • 3D-Druck Verfahren und ihre Vor- und Nachteile (Jan-Tarek Butt / Beschreibung)
  • Die eigene Cloud mit Seafile (Marek Walther / Beschreibung)
  • openSUSE für den täglichen Einsatz (Sebastian Siebert / Beschreibung)
  • invis-Server AD – Small Business für kleine Unternehmen (Stefan Schäfer / Beschreibung)
  • Flexibles Storage-Management unter Linux mit openATTIC (Lenz Grimmer / Beschreibung)
  • Rust – Einstieg in eine neue Programmiersprache (Felix Kronlage / Beschreibung)
  • Zentrales Log-Management mit Graylog (Bernd Ahlers / Beschreibung)
  • Freifunk 2015 (Freifunk Community Kiel / Beschreibung)
  • 1.000.000 Gründe, Linux zu benutzen (Monika Eggers / Beschreibung)
  • Ubuntu in Touch (Torsten Franz / Beschreibung)
  • FreeYourAndroid – Freie Software auf Android-Geräten (Dominic Hopf / Beschreibung)
  • 3D-Scan und Virtualisierungsverfahren (Jan-Tarek Butt / Beschreibung)
  • Fortschritt, Pfusch und Betrug – Bemerkung zu IT-Themen (Uwe Grigat / Beschreibung)

Quelle: Programm der Kieler Open Source und Linux Tage 2015

Ein Auszug der angebotenen Workshops:

  • Puppet, aller Anfang ist leicht! (Tim Schmeling / Beschreibung)
  • Inkscape für Fortgeschrittene 2015 (Samuel Albrecht / Beschreibung)
  • Das eigene Zwei-Faktor-System mit privacyIDEA (Cornelius Kölbel / Beschreibung)
  • Mutt+GPG (Sven Guckes / Beschreibung)
  • Web-Security Workshop (Timo Pagel / Beschreibung)
  • IT-Probleme selber lösen (Hauke Goos-Habermann / Beschreibung)
  • openSUSE Installationsparty – Workshop (Sebastian Siebert / Beschreibung)
  • Fotos bearbeiten

Sonntag
12. Juli 2015


face

AMD Catalyst 15.7 (fglrx 15.20.1046) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-15.7.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 und Tumbleweed sowie bis Kernel 4.1 (offiziell nur bis Kernel 3.19).

[UPDATE 03.09.2015]
Das Packaging Script wurde aktualisiert und enthält einen Patch für die Unterstützung von Kernel 4.2.0. Es waren einige tiefgreifende Änderungen im fglrx-Quellcode nötig, um den Treiber auf dem neueren Kernel zum Laufen zu bringen. Das hat mich etwas ins Schwitzen gebracht. Nun ist es endlich fertig und für die Allgemeinheit verfügbar. :-)
[/UPDATE 03.09.2015]

[UPDATE 25.07.2015]
Das Packaging Script wurde aktualisiert und behebt einen GPL-Konflikt mit pci_ignore_hotplug Funktion. Dieser Kompilierfehler ist mit Kernel 4.1.3 aus dem openSUSE-Kernel Repository aufgefallen.
[/UPDATE 25.07.2015]

Neue Features:

  • AMD PowerXpress support for laptops equipped with Intel 6th generation (Skylake) CPUs
  • Linux Platform Atomics & SVM Fine Grain Buffer support for Carrizo APUs
  • Multi-Device support for OpenCL 2.0

Gelöste Probleme:

  • [421317] Segmentation fault observed while launching some OpenGL games in RHEL7.1
  • [419365] Error message observed during installation through rpm package in RHEL 6.5, 7.0
  • [419162] System hangs while running Dying Light
  • [421858] clinfo could not recognize up to four GPU devices

Bekanntes Problem:

  • [419960]: Vari-Bright on some configurations is not decreasing brightness as expected

Link: AMD Catalyst 15.7 Release Notes

Wichtiger Hinweis: Dieser Treiber unterstützt nun offiziell X-Server 1.17 und läuft wieder mit openSUSE Tumbleweed. Der GNOME Desktopmanager ist nur bedingt funktionsfähig. Das bedeutet, dass ein kleiner Workaround notwendig ist, um es zum Laufen zu bringen. Wer unter GNOME das automatische Benutzerlogin aktiviert hat und ein Benutzerwechsel vollziehen möchte, sollte sich auf einen merkwürdigen Fehler gefasst machen. Alle TTY-Konsolen sind dann schwarz und der Anmeldefenster scheint abgestürzt zu sein. Sobald man den automatischen Benutzerlogin in GNOME ausschaltet, funktioniert der Benutzerwechsel ohne Probleme.

Wer GNOME mit gdm nutzen möchte, muss das Skript nach der Installation des Treibers und noch vor dem Neustart wie folgt als root ausgeführt werden:

sh makerpm-amd-15.7.sh --install-gdm-fix

Sollte es gute Gründe geben, den Fix wieder zu entfernen, lässt er sich einfach wieder rückgängig machen:

sh makerpm-amd-15.7.sh --uninstall-gdm-fix

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

Ältere Artikel ->