Fryboyter

Warum man einen Androiden mit einer alten Version von TWRP nicht flashen sollte

Gestern war mal wieder Bastelzeit. Und Layer-8-Zeit. Ich wollte schon vor längerem einmal das Omni-ROM auf meinem Mobiltelefon installieren. Gestern habe ich mir mal die Zeit genommen, zumal sonst keiner daheim war und endlich mal Ruhe geherrscht hat.

Also schnell mal Windows gebootet, MyPhoneExplorer gestartet (warum gibt es eigentlich kein vergleichbares Programm, das direkt unter Linux läuft? Na ja egal.) und Kontakte, SMS usw. gesichert. Sowie noch so gut… Was brauche ich jetzt? Das Omni-ROM… Gut also selbiges in der aktuellen Version heruntergeladen und die MD5-Summe verglichen. Passt. Nun noch die aktuelle Version von Google-Apps besorgen und beides auf das Mobiltelefon kopieren. Dabei habe ich gemerkt, dass noch einige ROM von Paranoid Android auf dem Handy liegen. Weg damit. Ready to roll? Jep! Also Mobiltelefon neu gebootet und TWRP gestartet. Wie ging das jetzt noch gleich. Ach ja… Cache und Davlik Cache plätten. Gesagt getan. Und nun das neue ROM installieren. Genau an der Stelle hätte mir jemand auf die Finger klopfen sollen. War nur leider keiner da. Das Flashen ging mit einem netten Failure nach hinten los. Nach ein paar Sekunden nervösem googlen hatte ich den Grund gefunden. Meine Version von TWRP ist zu alt. Verdammte Axt! Was nun? Datensicherung vorhanden? Check. Datensicherung auf dem Mobiltelefon vorhanden? Natürlich nicht. Da sich das Mobiltelefon nicht mehr unter Windows oder Linux mounten lässt, habe ich jetzt wohl ein kleines Problem.

Kurz davor, mir schon mal ein neues Mobiltelefon zu bestellen, habe ich über Google das Tool adb.exe gefunden. Damit lässt sich wohl jede Menge Blödsinn anstellen. Unter anderem soll man damit wohl auch flashen können, wenn man, so wie ich, Mist gebaut hat. Da ja nicht wirklich mehr schiefgehen kann, habe ich mir dann gleich mal Android SDK installiert. ADB ist ein Bestandteil davon. Als Nächstes habe ich mein Telefon in den Recovery-Modus gebootet, ADB Sideload gestartet und versucht mittels adb.exe ein aktuelles Image von TWRP hochzuladen. Hat auch geklappt. Als ich über die Installationsfunktion installieren wollte, wurde die Datei aber nicht gefunden. Nur Zip-Dateien. Also gut, dann packen wir das Image in eine ZIP-Datei und laden Sie noch einmal hoch. Mit dem Ergebnis, dass die Datei angeblich nicht geöffnet werden kann. Unter Windows klappt es aber problemlos. Hmm… Google schlägt mir als weitere Lösung fastboot.exe (ebenfalls Bestandteil des SDK) vor. Da selbiges auch auf der Seite von Omni-ROM empfohlen wird, kann es Versuch ja nicht schaden. Also starten wir das Telefon mal in den Fastboot-Modus und geben in die Konsole unter Windows mal “fastboot flash recovery twrp.img” ein und drücken beherzt auf Return. So wie es aussieht, tut sich etwas, und es wird erfolgreich abgeschlossen.

Nach einem Neustart begrüßt mich TWRP in der aktuellen Version. Sollte ich mal wieder mehr Glück als Verstand haben? Ein erneuter Versuch Omni-ROM zu installieren wird erfolgreich abgeschlossen. Eindeutig mehr Glück als Verstand.

Lange Rede, kurzer Sinn… Für den Notfall sollte man immer ein funktionsfähiges Backup auf dem Telefon haben, nicht nur auf dem Rechner. Und RTFM schadet auch nicht. Hätte ich letzteres gemacht, wäre mir das mit der alten Version von TWRP schon vorher aufgefallen.

Ausfall der Webseite und die Entdeckung von Pydio

Heute ist für ein paar Stunden diese Seite nicht erreichbar gewesen. Der Grund war, dass mal wieder so ein Vollidiot gemeint hat, er müsse sein neues Spamtool mal bei mir ausprobieren. Da er so schlau war, das immer über die gleiche IP zu machen, wollte ich über das Plugin “Yoast WordPress SEO” die Datei .htaccess mal eben anpassen und ihn aussperren. Leider hat mir da ein kapitales Layer-8-Problem einen dicken Strich durch die Rechnung gemacht, sodass man für ein paar Stunden nur der Fehler 500 angezeigt wurde.

Da ich, Firewall sei dank, keine SSH-Verbindung zu meinem Webspace aufbauen konnte, habe ich daher erst mal in die Röhre geschaut. Mein Mobiltelefon, auf dem ein SSH-Client installiert ist, lag natürlich auch daheim. Also doch noch schnell heim und es von dort aus reparieren. Man hat ja sonst nichts zu tun. Bei der Gelegenheit habe ich gleich mal Google gequält, wie ich solche Probleme in Zukunft einfacher lösen kann, ohne mich mit der Firewall anzulegen. Dabei bin ich auf Pydio gestoßen. Genauer kann ich es mir erst heute Abend daheim ansehen. Aber bisher bin ich ziemlich begeistert. Ich würde es als Mischung zwischen Owncloud und einem Dateimanager bezeichnen, der man eine Prise Speed verpasst hat. Auf die Schnelle würde ich sagen, dass Ding bietet so ziemlich alles. Na ja nicht alles, aber sehr viel wie WebDAV, Samba, Dropbox, LDAP/AD, Antivirus, Dateifreigaben, Benutzerverwaltung, EncFs, SFTP, Dateieditoren (ganz wichtig, falls ich mal wieder ein Layer-8-Problem habe) usw. usw. Genaueres findet man unter http://pyd.io/plugins.

Die Installation ist auch idiotensicher. Hochladen, aufrufen und dem Installationsprozess folgen. Die Konfiguration erfolgt entweder in einer Datei oder in einer Datenbank.

Clients für iOS und Android sowie ein Client zum Abgleichen (noch nicht stabil. Für Windows, Mac und Linux) der Dateien werden, wie auch einige Bridges (z. B. zu WordPress) werden ebenfalls angeboten.

Sollten sich heute Abend nicht arge Nachteile herausstellen, werde ich Dropbox und Co. wohl einstampfen.

Wer sich mal ein Bild machen will, findet unter https://demo.pyd.io eine Demoinstallation.

Warum man immer erst die SuFu nutzen sollte

Gestern hatte ich mal wieder ein Erlebnis, bei dem man sich nur an den Kopf fassen konnte. Diesmal allerdings wegen eigener Dummheit. Als ich gestern mein Netbook mal wieder mit den neuen Updates von Arch-Linux versorgen wollte, ist während der Installation ist irgendwann der Rechner ausgegangen. Wann genau kann ich nicht sagen, da ich nicht die ganze Zeit vorm Rechner war. Aber die Ursache war auf jeden Fall ein leerer Akku.

Tja, man sollte wirklich erst mal den Akkustand prüfen, bevor man die Updates einspielt. Das habe ich dann, nachdem ich das Netzkabel angeschlossen und die Kiste wieder gestartet feststellen müssen. Kurz nachdem ich unter LXDE angemeldet habe, gab es eine nette Kernel Panic.

Also wieder ein Neustart. Danach ganz schnell angemeldet und versucht die Logs unter /var/log anzusehen. Kernel Panic. Nächster Versuch. Diesmal allerdings kein Versuch Logs anzusehen, sondern pacman -Syu aufgerufen. Eventuell wurde wegen des leeren Akkus ja nur ein Paket nicht ganz installiert. Kernel Panic. Hmm… Eventuell hat das Dateisystem eine Macke? Also gut, dann booten wir eben die Kiste mal mit dem Installationsmedium von Arch und prüfen mal das Dateisystem der Root- und Homepartion. Hier gab es mal keine Kernel Panic, sondern erst mal eine Hürde, wie man mittels Luks verschlüsselte LVM mountet. Also schnell mal mit dem Smartphone gegoogelt. Ach so geht das… Ein Check des Dateisystems ergab aber nichts. Nicht mal eine Kernel Panic. Also gut, dann schauen wir mal die Logs an. Nichts.

Das suchen wir den Fehler Spielchen habe ich dann noch ca. 2 Stunden gespielt und mich dann entschieden, die persönlichen Daten am Wochenende zu sichern und die Kiste neu zu installieren. Das geht auf jeden Fall schneller. Gut, dass ich aber noch am selben Abend im Forum von archlinux.org vorbeigeschaut habe. Dort habe ich dann diesen Thread gefunden. Und genau in dem Moment habe ich mir an den Kopf gefasst. Denn mein Netbook hat einen Broadcom-Chip für das WLAN, welcher das Modul brcmsmac nutzt. Und bei der abgebrochenen Aktualisierung war bei den neuen Paketen auch der Kernel Linux 3.10.6 dabei. Scheinbar lief die Aktualisierung wohl doch durch. Zumindest bis zum Kernel.

Ich habe mich daher erst mal entschlossen, wieder den alten Kernel 3.10.5 zu installieren. Und schon läuft die Kiste wieder. Da Broadcom ja nicht gerade der Hit unter Linux ist, überlege ich mir jetzt allerdings noch, ob ich die WLAN-Karte gegen eine andere z. B. von Intel tausche. Allerdings soll Lenovo ja im BIOS eine Whitelist führen und so viele Karten aussperren.