Seit ein paar Wochen bin ich – und das auch sehr zufriedenstellend – auf meinem Samsung Galaxy S5 Duos (klteduos) von CyanogenMod (CM) auf LineageOS (LOS) umgeschwenkt.

Vorab noch schnell, bevor es zum eigentlichen Thema geht, was dazu. – Erst nach einem full wipe läuft LOS rund. Zuerst hatte ich von CM 13 auf LOS 14.1 mit nem dirty flash (= also Beibehaltung aller Daten, bis auf Cache und Dalvik Cache) mittels TWRP aktualisiert, aber da konnte ich anfangs die zu dem Zeitpunkt aktuellen Open GApps schon nicht installieren und am Ende landete ich sogar in ner Rebootschleife …
Grundsätzlich ist eig. alles ganz einfach. – Auch ne offizielle LOS-Wikiseite gibts dazu. Oder halt auf die Schnelle:

  1. aktuelles nightly-Image von LOS für klteduos ziehen
  2. su-Modul (für Root-Rechte) für LOS ziehen (fürs klteduos die arm-Variante)
  3. Open GApps ziehen (arm, v7.1)
  4. alles auf die SD-Karte packen, so nicht eh schon dort hin herunter geladen wurde
  5. ins Recovery (TWRP) booten (wer TWRP noch nich drauf hat, kann es sich hier besorgen)
  6. Backup vom CM machen (so für den Notfall … ;-))
  7. full wip (= factory reset) machen
  8. die drei gezogenen Images/Zips nacheinander installieren (TWRP kann die auch in eine Queue packen, is ganz nett)
  9. reboot 🙂

So und nun zum Thema … – LOS benutzt (=also hat integriert) aktuell noch einige CM-Apps, so auch den CM-Dateimanager (com.cyanogenmod.filemanager, v3.0.0) und ärgerlicherweise hat der nen Bug beim Zugriff (der näml. angeblich wegen fehlender Rechte nicht geht) auf die SD-Karte.

Beim ersten Feststellen hatte ich dann iwo im Netz gefunden, dass ich die originale APK löschen und den CM-Dateimanager (als APK) neu installieren sollte. Genau weiß ich nicht mehr, ob das geklappt hatte, auf jeden Fall ging es heute (nach dem zwischenzeitl. OTA-Update eines neuen nightly, was sehr gut klappt) nicht mehr.
Also habe ich nochmal recherchiert und stolperte über o.g. Bug, in dem in einem Kommentar von Malessio am 4.2. ein kleiner Trick steht, der auch bei mir funktioniert hat.

so now i've added /mnt/media_rw/77B8-1D11 to the bookmarks and i can access the external sd-card even without root as it should

(Bitte beachten, dass 77B8-1D11 die individuelle UID der SD-Karte ist und bei jedem Device unterschiedlich ist. Bei mir gab es nur einen Ordner in /mnt/media_rw/ und mit dem klappt der Zugriff, ich habe auch noch die root-Option in den Einstellungen aktiv, auf jeden Fall jetzt problemlos …)

Am Rande: Mal schauen, wie lange der CM-Dateianager überh. noch in LOS drin sein wird. – Die Entwickler(_innen?) haben sich wohl entschieden, den nicht weiter in LOS zu integrieren. (Ich finde es schade, da mir die Alternativen – über „Downloads“, oder Einstellungen > Speicher zu gehen – zu krepelig und unzureichend erscheinen …)

In diesem Sinne: *happyflashing*! 😀

Heute war nen ‚schöner‘ verbummelter Tag …

Geschichte

Gestern Abend kommt von einem Familienmitglied die Chatnachricht „mein Rechner geht nicht mehr“, auf die ich antworte „mal Strom für mindestens eine Minute trennen“. Am Ende hilft das (nat.) nix und wir verabredeten uns für heute zu einem Telefonat.

Zu 10 Uhr dann das erste Telefonat und ich stelle recht schnell fest, dass Remote-Support ohne X und somit nur per Telefon echt ma nich geht. (Das Buchstabieren von iwelchen Kommandos ist ganz schön mühsam …)
Heraus gekommen ist immerhin, dass es sich um einen Login-Loop unter Ubuntu 16.04 (ich war anfangs noch der Meinung, dass es noch ein von mir installiertes 14.04 ist) handelt, welches seit ca. letzten Freitag besteht.

Nach ner Stunde habe ich die Faxen dicke und leider nicht mal ansatzweise ne Idee außer, dass es iwas mit der recht alten NVIDIA GeForce 6800 GS in der Aldi-Multimediakiste zu tun hat. In /var/log/Xorg.* und ~/.xsession-errors war so richtig nix zu finden.

Dann kümmerte ich mich erst einmal darum, wie ich remote auf den Desktop per SSH zugreifen kann. Dazu war es dann nötig, auf der Fritz!Box (über die der andere Rechner an INet angebunden ist) ne Portweiterleitung einzurichten und openssh-server auf dem zu reparierenden Rechner zu installieren. (Also wieder andere Baustellen …) – Das hat aber glücklicherweise dann ganz gut geklappt.

Dann hatte ich etwas Zeit (auch wenn ich nebenbei etwas HomeOffice machen ‚musste‘) zum umsehen, Loop-Ursache lokalisieren und das System noch etwas aufräumen.

Idee 1

Zuerst versuchte ich mein Glück mit dem Update des proprietären Nvidia-Treibers aus dem Paket nvidia-$NR.
Ergebnis: Ohne Erfolg, da die (alte) GeForce nur bis zum Paket nvidia-304 unterstütz wird. Also alles wieder zurückgedreht …

aptitude purge ~nnvidia- && aptitude install nvidia-304

Idee 2

Dann dachte ich mir, ich verzichte ganz auf den proprietären Kram und setze auf den (offenen) Nvidia-Treiber nouveau.
Ergebnis 2: Blöd nur dass der iwie nicht mit dem Monitor zusammenarbeiten wollte und ich nicht in der Lage war, eine annehmbare (größer 640×480) Auflösung einzustellen, obwohl ich (seit Ewigkeiten mal wieder) ne komplette /etc/X11/xorg.conf händisch gebastelt hab …
(Früher musste man alles händisch machen und Dinge haben nur geklappt, wenn man die korrekten Parameter hatte. Heute wird extrem viel automatisch gemacht und man kann oft gar nix mehr groß händisch ändern, wenn der Automatismus versagt. *grml*)

Zielgerade

Ich stieß dann (iwie in meinem 30sten Tab) auf den Foreneintrag „Anmeldung auf graphischer Oberfläche nicht möglich“ im ubuntuusers.de-Forum. Eigentlich nur, weil der recht aktuell ist. (Viele andere Recherchetreffer waren schon ewig alt …)
Der dort verlinkte Launchpad-Bug #1634802 brachte mich jedoch immer noch nicht auf die Zielgerade, jedoch auf eine Fährte. – Nämlich den (auf Ask Ubuntu verlinkten) Launchpad-Bug #1639180, der in der Beschreibung auch meine Fehlermeldung (die ich am Ende in /var/log/syslog fand) enthält:
X Error of failed request: BadValue (integer parameter out of range for operation).

Lösung

Letzten Donnerstag (3.11.16) – und da kommen wir ärgerlicherweise wieder zu Ausgangssituation .oO(Hätte ich das mal ernst genommen und in meine Recherche zu Beginn eingebunden!) – wurde die Version „304.132-0ubuntu0.16.04.2“ verteilt. Diese scheint (wie bspw. obige Bugs ja auch zeigen) einige Unzulänglichkeiten zu haben und verursachte auch auf meinem Problemsystem den Login-Loop.

Die vorhergehende Version „304.131-0ubuntu3“ lief (und läuft) ohne diese Probleme. – Ergo habe ich ein Downgrade durchgeführt.

Dazu also wieder alle installierten Nvidia-Pakete deinstallieren:

aptitude purge ~nnvidia- && aptitude install nvidia-304

Dann die „304.131-0ubuntu3“ installieren:

apt-get install nvidia-304=304.131-0ubuntu3

Am Ende noch (da das System ja nicht täglich unter meiner Kontrolle ist) die „304.131-0ubuntu3“ in der (neuen) Datei /etc/apt/preferences.d/nvidia-304 (mit folgenden Inhalt) gepinnt (s. Apt-Pinning)

Package: nvidia-304
Pin: version 304.131-0ubuntu3
Pin-Priority: 1001

Und nach nem Reboot war der Login-Loop weg … 🙂 *fertsch*

Danke an die Community, ohne die in der ja doch recht kurzer Zeit (von letztem Donnerstag bis heute) eine Lösung nicht in meinen eigenen Kräften gewesen wäre!

Vor guten vier Jahren wechselte ich von Delicious auf eine selbst gehostetes SemanticScuttle-Installation.

Seit 2013 wird SC nicht so richtig aktiv weiter entwickelt – vllt. ist es aber ja auch so fertig, wie es ist, und ja, es gibt sporadische Aktualisierungen im GitHub-Repo des Entwicklers Christian Weiske  – und über die Jahre habe ich festgestellt, dass ich die ‚semantischen Funktionalitäten‘ nicht (wirklich) benutze.

Als ich dann gestern durch Zufall beim Aktualisieren von FDroid über die Shaarlier-App stolperte und mir heute Shaarli testweise installiert hatte, war ich recht schnell entschlossen, das ca. 12 MB große SC mit dem nur 3 MB umfassende Shaarli für meine gut 2.400 Links zu ersetzen. – Gesagt, getan …

FYI: Ab heute wird bm.sok.ai mit Shaarli betrieben. – Und das sogar ganz angenehm auch unter Android …

Für die Migration der Bookmarks musste ich beim Umzug noch etwas basteln … – Das Problem an SC ist, dass es in meiner Version keinen separaten Export der öffentlichen und privaten Bookmarks erlaubt.
Also änderte ich das API-Skript etwas, um zuerst nur die publics aus SC exportieren zu können. Diese importierte ich dann in Shaarli.
Dann exportierte ich alle SC-Bookmarks und importierte diese noch einmal in Shaarli als private und ohne das Überschreiben existierender Bookmarks.
Das public export-Skript stelle ich bei Gelegenheit noch einmal hier iwo online …

Old but not busted … – Dieser Inhalt wurde vor mehr als 3 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

Gerade hatte ich das Problem, dass meine aktuell installierte Version von ffmpeg nicht so wollte wie ich und mir eine Videodateikonvertierung mit einer Fehlermeldung quittierte.

Nach einer kleinen Recherche stellte sich heraus, dass das Problem bekannt und bereits in einer aktuelleren Version behoben ist. Da ich aber nun nicht so schnell eine aktuellere Version installieren konnte und obiges Problem auch nur bei einer Datei auftrat, fand ich folgende Möglichkeit bei ubuntuforums.org zur (temporären) Benutzung einer statischen (bereits kompilierten) Version von ffmpeg.

wget http://ffmpeg.gusari.org/static/32bit/ffmpeg.static.32bit.2014-02-23.tar.gz
tar xzvf ffmpeg.static.32bit.2014-02-23.tar.gz
./ffmpeg -i input [output options] output

Erläuterung:
Mit dem ersten Befehl wird die gepackte 32bit-Variante von ffmpeg vom 23.02.2014 herunter gelanden. Der zweite entpackt die Datei, wobei die beiden Dateien ffmpeg und ffprobe entstehen. Als drittes wird die gerade entpackte Datei ffmpeg benutzt, um die Konvertierung durchzuführen.

… und schwupdiwup war mein Problem (jedenfalls temporär) behoben … – Danke an FakeOutdoorsman!

Old but not busted … – Dieser Inhalt wurde vor mehr als 5 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

Seit ein paar Wochen habe ich den ownCloud-Client unter Ubuntu installiert. Dieser lief auch recht gut & brauchbar – bis auf ein paar kleine ‚Macken‘. So zum Beispiel auch das Problemchen, welches bei DonnerDrummel kurz erklärt ist. Dies war besonders nach dem Aufwachen des Rechners regelmäßig zu beobachten.

Vor ein paar Tagen erhielt ich dann bei Neustart des Clients die Meldung, dass die Version 1.0.3 verfügbar ist. Allerdings habe ich mich dann gewundert, dass ich diese bei der Softwareaktualisierung nicht angeboten bekomme. Heute habe ich dann nochmal versucht, dem Problem auf den Grund zu gehen und bin über DonnerDrummels Beitrag gestolpert. Dann habe ich mir nochmal die Anleitung zur Installation des Clients angeschaut und festgestellt, dass ich ein anderes Repo installiert hatte, als es da angegeben ist – ich hatte

“isv:ownCloud:communiy“
in der URL, welches jetzt
“isv:ownCloud:ownCloud2012″
ist. Offensichtlich hat sich da etwas ‚offiziell‘ geändert, was ich bis dato nicht mitbekommen hatte.

Lange Rede, kurzer Sinn – HowTo zum Update des ownCloud-Clients:

  1. "owncloud-client" – Version 1.0.2 – vollständig deinstallieren (ein Update hat nicht funktioniert).
  2. Das Repo (aus der Anleitung; s.o.) kontrollieren und korrigieren.
  3. "owncloud-client" – jetzt in Version 1.0.3-1 – (neu) installieren.

Voila – das erste Aufwachen hat den Fehler im Client nicht mehr produziert… 🙂
Schön ist auch, dass der csync-Prozess (der im Hintergrund für die Synchronisiation zuständig ist, nicht mehr meine .xsession-errors-Datei ‚vollmüllt‘. Dafür gibt es (jetzt?) im Client selber einen Knopf, der die Logs anzeigt. (Blöd nur, dass das Fenster mit dem Log nicht schließbar ist und gerade nur mit "xkill" beendet werden konnte… *egal*)

Abschließend bleibt zu sagen, dass obige ‚Anleitung‘ ohne jegliches Gewehr meinerseits veröffentlicht ist und dass ich mich generell sehr über das ownCloud-Projekt und die alles in allem sehr gut funktionierende Software freue! 🙂