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.


Donnerstag
21. Juni 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, so findet es sich in /usr/lib64/libgamemodeauto.so. Um es im Spiel game zu nutzen ist diese dann wie folgt zu starten:

LD_PRELOAD=/usr/lib64/libgamemodeauto.so 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 %command%

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

Der einfachste Weg GameMode zu installieren ist den Download oder die Anleitung von software.opensuse.org zu nutzen. Leider ist GameMode noch nicht in die eigentliche Distribution eingezogen, so dass ein einfaches zypper install libgamemodeauto noch nicht ausreicht, da 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 Strg


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


Freitag
10. Juni 2016


face

Nach dem Server-Umzug ist mir aufgefallen, dass viele meiner Scripte unterschiedliche Zeichensätze s.g. Zeichenkodierungen aufweisen. Das war auf dem alten System kein Problem, da es großzügig darüber hinweg gesehen hat. Auf dem neuen werden Dateien etwas strikter behandelt. So wird aus einem Ä mal ganz schnell ein Ã¤ ö ü. o.ä. … Nun könnte man alle Dateien mittels Kwrite o.ä. manuell behandeln, allerdings gibt es dafür schon ein schönes Script (inkl. Fehlerbehandlung):

Lexo.ch

Einfach in ein übergeordnetes Verzeichnis kopieren und im Terminal mit “ ./converter.sh /pfad/zu/den/Dateien „aufrufen. Es behandelt den Ordner rekursiv d.h. bezieht auch alle Unterordner ein. Dabei wandelt es nur Dateien um, die dafür geeignet sind (es wird auf ein Array mit Endungen zurück gegriffen) und noch nicht in UTF-8 sind.

Nachtrag:
Ein wichtiger Hinweis an dieser Stelle: legt euch vor dem Umwandeln unbedingt eine Kopie der Daten an.
Sollte das Charset einer Datei nicht erkannt werden, wird diese auch nicht konvertiert. Diese Sicherheits-Einstellung wird für die Liste filestoconvert aufgeweicht. Es kann daher vorkommen, dass 0-Byte Dateien entstehen. Wer auf Nummer-Sicher gehen will, leert die Liste. Andernfalls sollte z.B. mittels Kompare der Zustand vorher und nachher verglichen werden. Auch praktisch ist folgende Code-Zeile, die alle 0-Byte Dateien auflistet: find $dir -size 0 -print

#!/bin/bash

# Created by LEXO, http://www.lexo.ch
# Version 1.0
#
# This bash script converts all files from within a given directory from any charset to UTF-8 recursively
# It takes track of those files that cannot be converted automatically. Usually this happens when the original charset
# cannot be recognized. In that case you should load the corresponding file into a development editor like Netbeans
# or Komodo and apply the UTF-8 charset manually.
#
# This is free software. Use and distribute but do it at your own risk. 
# We will not take any responsibilities for failures and do not provide any support.

#checking Parameters
if [ ! -n "$1" ] ; then
  echo "You did not supply any directory at the command line."
  echo "You need to provide the path to the directory that contains the files which you want to be converted"
  echo ""
  echo "Example: $0 /path/to/directory"
  echo ""
  echo "Important hint: You should not run this script from within the same directory where the files are stored"
  echo "that you want to convert right now."
        exit
fi

# This array contains file extensions that need to be checked no matter if the filetype is binary or not.
# Reason: Sometimes it happens that .htm(l), .php, .tpl files etc. have a binary charset type. This script
# does not convert binary file types into utf-8 because it might destroy your data. So we need to include these file types
# into the conversion system manually to tell the conversion that binary files with these special extensions may be converted anyway.
filestoconvert=(htm html php txt tpl asp css js)

# define colors
# default color
reset="\033[0;00m"
# Successful conversion (green)
success="\033[1;32m"
# No conversion needed (blue)
noconversion 

Sonntag
05. Juni 2016


face

Schneller als gedacht ist der Umzug von oYoX.de auf einen neuen Server vollendet.
In diesem Zusammenhang habe ich auch gleich die Verbindung zwischen Server und Browser mittels Lets-Encrypt Zertifikat abgesichert.
Ich wünsche weiterhin viel Spaß beim Lesen.

wordress_umzug

ajax loader

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
27. Februar 2016


face

chrome_opensuse_leap_graphic_issueSeit openSuse 42 treten bei mir vermehrt seltsame Phänomene zutage. So führt das Abspielen von HTML5 Videos in Chrome teilweise zu einer systemweiten Bildverzerrung. Auch wenn ich Chrome minimiere und wieder auf Vollbild schalte, treten diese Verzerrungen auf.

 

 

Video zu dem Problem:

Unter Umständen liegt es an der Hardwarebeschleunigung von Chrome. Wenn man diese deaktiviert, sollten die Probleme nicht weiter auftreten:

  1. In die Chrome Einstellungen wechseln: chrome://settings/ (in der Adressleiste eingeben)
  2. auf „Erweiterte Einstellungen anzeigen“ unten klicken.
  3. Nun bis zum Ende scrollen und dort den Haken bei „Hardwarebeschleunigung verwenden, falls verfügbar“ entfernen.

Nach einem Neustart von Chrome sollte das Problem nicht mehr auftreten.

Weitere Informationen hierzu: https://www.quora.com/How-do-I-reduce-avoid-the-heavy-CPU-usage-of-Google-Chrome-in-Ubuntu (englisch)

ajax loader

Montag
08. Februar 2016


face
screenshot_einstellung

Klick für Vollansicht

Beim Einstellen der eigenen Tastenkürzel unter „Eigene Kurzbefehle“ ist mir aufgefallen, dass man keine Bildschirmfotos mittels der „Druck“ Taste anfertigen kann. In den Vorgänger-Versionen wurde für diesen Zweck KSnapshot genutzt. Seit Leap ist das neue Programm für Bildschirmfotos Spectacle

Interessanterweise ist unter den „Eigenen Kurzbefehlen“ noch immer KSnapshot der „Druck“-Taste zugewiesen.

Das können wir jedoch einfach und schnell ändern, denn es existiert ebenfalls schon der Menü-Punkt „Screenshots“.Wir nehmen also unter der Gruppe „Voreingestellte Aktionen“ den Haken bei „Bildschirm-Drucken“ weg und klicken einmal in der Gruppe „Screenshots“ auf „Start Screenshot Tool“ im Reiter Auslöser klicken wir neben dem Wort Kurzbefehl auf den Knopf und danach einmal auf die Druck-Taste. Damit wird die Taste dem Tool zugewiesen. Fertig.

ajax loader

Freitag
05. Februar 2016


face

g13Vorbemerkung:

Wer das ein oder andere Spiel unter Linux spielt oder ein leistungsfähiges, aber kleines Macro-Keyboard sucht, ist mit dem G13 von Logitech sehr gut beraten. Das gute Stück gibt es 74 Euro bei Amazon oder gebraucht für ca. 30 Euro. Die Einrichtung gestaltet sich überaus einfach, da es bereits Treiber für Linux gibt. Zum Erstellen der Macros gibt es eine GUI (in Java), welche einem viel Arbeit abnimmt.

Quelle des Treibers: https://code.google.com/p/linux-g13-driver/
Alternativ: Installationspaket von oYoX: Note: There is a file embedded within this post, please visit this post to download the file.

Installation:

1. Paket herunterladen und entpacken.

2. g++ installieren:

sudo zypper in gcc-c++   (installiert: gcc48-c++ gcc-c++ )

3. libusb-1_0-0 und libusb-1_0-devel installieren:

sudo zypper in libusb-1_0-0 libusb-1_0-devel

3 b. Alternativ über „Yast2 Software“ installiert:

libusb-1_0-0
libusb-1_0-devel

4. In den Ordner wechseln, dort die Datei „Makefile“ öffnen und folgende Zeile tauschen:

FLAGS = 
LIBS     = -lusb-1.0

# in

FLAGS = -L /lib64 
LIBS = -lusb-1.0 -l pthread

5. Mit der Konsole in den Ordner wechseln und dort „make“ eingeben
Damit wurde der Treiber erstellt.

6. Nun kann die GUI gestartet werden:

g13_gui

java -jar Linux-G13-GUI2.jar

7. Jetzt wird es etwas tricky, denn die GUI schreibt die Konfiguration in den Home-Ordner des jeweiligen Benutzers, da sie nicht mit root gestartet wird/wurde.
Der G13 Treiber muss jedoch mit root gestartet werden und sucht demnach auch im root-Ordner nach der Konfiguration.

Linux bietet uns hier nun eine wunderbare Lösung: Symbolische Verknüfungen.
Wir legen also im Root-Verzeichnis eine Verknüpfung auf den Konfigurations-Ordner des aktuellen Users an:

sudo ln -s /home/USERNAME/.g13 /root/.g13
# (USERNAME bitte gegen den aktuell angemeldeten Benutzername austauschen)

8. Nachdem das GUI-Fenster wieder geschlossen ist und der symbolische Link erzeugt wurde, kann der Treiber gestartet werden:

sudo ./Linux-G13-Driver

9. Ab jetzt ist es möglich, die GUI auch bei laufendem Treiber zu starten und Tasten anzupassen.

Die Änderungen werden sofort übernommen, allerdings muss nach den Änderungen / Anpassungen der Tasten und Makros das Profil auf der G13 neu geladen werden. Dazu einfach eine andere Profil-Taste (4 Tasten direkt unter dem Display) drücken und dann zum aktuellen Profil zurück kehren. Damit lädt sich die G13 alle Konfigurationen.

Anmerkung zum oYoX Paket

Ich habe die GUI etwas angepasst (Hintergrundbild), sodass die Tastenbelegung besser zu lesen ist. Auch sind zwei Starter (Bash-Scripte) im Paket, welche noch an den jeweiligen User-Pfad angepasst werden müssen.

Downloads

Note: There is a file embedded within this post, please visit this post to download the file.

ajax loader

Donnerstag
28. Januar 2016


face

plasmacrashWer nach einem Update von openSUSE vor einem schwarzen Desktop steht und evtl. mit Fehlern wie „Plasma crashed“ konfrontiert wird, muss nicht verzagen. Das Problem liegt im NVIDIA Treiber und lässt sich sehr leicht lösen, indem man selbigen neu installiert.

Update vom 04.02.2016:
Mit dem Tool DKMS entfällt die ständige Neu-Installation. Dazu einfach vor der (erneuten) Installation DKMS installieren:

sudo zypper in dkms

Danach wird an „NVIDIA-Linux-x86_64-352.63.run“ einfach noch das Kommando -dkms angehängt. Von nun an wird nach einem Kernel-Update der Treiber automatisch neu gebaut.

Einfach dieser Anleitung folgen:

# Mittels ALT + F5 in die Konsole wechseln und in den Ordner mit der 
# ./NVIDIA-Linux-x86_64-352.63.run wechseln

su
cd /home/USERNAME/Downloads/
sh ./NVIDIA-Linux-x86_64-352.63.run -uninstall

# Der Anleitung folgen... bei der Frage nach dem Backup das Backup 
# einspielen (wiederherstellen) lassen.

# Nun ist wieder der Standard-Treiber eingebunden und ein Start zum 
# Desktop sollte möglich sein.
# Also einen Neustart durchführen lassen...
 
reboot -h now

# Nach dem (hoffentlich erfolgreichen Neustart) wieder vom Desktop 
# abmelden (nicht herunterfahren) und mittels ALT + F5 erneut in die 
# Konsole wechseln.

# Jetzt den Treiber erneut installieren:

su
cd /home/USERNAME/Downloads/
sh ./NVIDIA-Linux-x86_64-352.63.run
# ANMERKUNG: evtl. mit -dkms (siehe oben). Dann lautet die Zeile:
# sh ./NVIDIA-Linux-x86_64-352.63.run -dkms

# Den Anweisungen folgen und ein Backup anlegen lassen 
# (geschieht automatisch). Außerdem die 32bit Libs installieren lassen.

# Der NVIDIA Treiber ist nun wieder eingebunden. Jetzt sollte alles 
# wieder funktionieren. 
# Also noch einen Neustart durchführen lassen...
 
reboot -h now

Vielleicht gibt es ja in den unendlichen Weiten des Internets ein Script, was nach einem (Kernel-)Update das ganze etwas vereinfacht…

ajax loader

Sonntag
24. Januar 2016


face

Nachdem oYoX immer unübersichtlicher wurde und zahlreiche WordPress-Plugins dafür gesorgt hatten, dass alles irgendwie überladen war, habe ich mich zu einer großen Putzaktion durchgerungen.

besen_putzen.jpg
Zuerst sollte ein neues, frisches Layout her: modern und mit übersichtlicheren Kategorie, damit man Einträge schneller findet.
Das neue Layout ist nun breiter und passt sich dynamisch an die Bildschirmgröße an. Auch ist es über Smartphones nun ohne das WordPress Plugin nutzbar, was zu einem einheitlicheren Design führt. Vor allem aber zeigt es die Informationen kompakter / übersichtlicher.
So weit so gut. Jetzt steht aber für die kommenden Tage noch einiges an Arbeit an: Alle Einträge müssen an das Layout angepasst bzw. vereinheitlicht werden. Ungültige Beiträge müssen aussortiert und auch das Download-System auf Vordermann gebracht werden.
Sollte es in den kommenden Tagen daher noch zu dem ein oder anderen „Schluckauf“ kommen, dann bitte ich um etwas Geduld.
Bild: Note: There is a file embedded within this post, please visit this post to download the file. …
ajax loader

Ältere Artikel ->