Freitag, 14. Mai 2021

LineageOS 17.1 auf Moto G5 nun auch offiziell

Nachdem ich neulich eine inoffizielle Version von LineageOS 17.1 auf einem alten Lenovo Moto G5 installiert habe (und bis auf den Kamerafehler keine Probleme mit dem ROM hatte), habe ich gerade gesehen, dass es seit Februar 2021 auch offizielle LineageOS 17.1 und auch 18.1 Images gibt.

Leider gibt es heute noch keine OpenGApps für Android 11, sodass ich zunächst die aktuelle LineageOS 17.1 anstelle der noch neueren LineageOS 18.1 (die auf Android 11 basiert) gemäß dieser Anleitung installieren werde – denn dafür gibt es die passenden OpenGApps (anders als neulich werde ich aber voraussichtlich die Version “Nano” flashen, so wie die offizielle Anleitung es rät).

Vielleicht auch ganz interessant:

  • Nach der Installation von LineageOS 17.1 und den Nano OpenGApps sind 6,5 GB (40%) der 16GB Speicher belegt.
  • Verwendet habe ich
    • twrp-3.2.1-cedric-vendor-v4.img (nicht das offizielle lineage-17.1-20210506-recovery-cedric.img)
    • lineage-17.1-20210506-nightly-cedric-signed.zip
    • open_gapps-arm64-10.0-nano-20210514.zip

Obwohl dieses keine Anleitung ist, hier die Schritte, die ich durchgeführt haben (nachmachen auf eigene Verantwortung – ich übernehme keinerlei Haftung)

  • Die Installation habe ich abweichend von der offiziellen Anleitung direkt über eine SDCard aus dem twrp recovery ROM gestartet, davor habe ich eine Sicherung gemach und einen komplett Wipe durchgeführt:
    • Ins TWRP booten (Leiser + Power drücken, dann Recovery Rom auswählen) und dort Wipe, Format Data (Achtung, hier werden alle Daten gelöscht, also auf eigene Gefahr / nur nach einem Backup ausführen!)
    • Restart und wieder ins TWRP booten
    • Wipe dann, “advanced wipe” dort “Wipe system data and cache”
    • “Install” aus dem Menü auswählen
    • Rom installieren
    • Gapps (arm64 android 10 nano) installieren
    • Wipe dalvik cache
    • Restart

Samstag, 3. Oktober 2020

Weiterleiten von Com Ports in eine virtuelle Maschine (Hyper-V)

Beim Versuche einen physikalischen ComPort meines Host-Rechners an eine virtuelle Maschine weiterzuleiten, habe ich herausgefunden, dass Microsofts Hyper-V das leider nicht kann.

Abhilfe schafft Tim Howard’s ComPipe welches als eine Art Brücke fungiert:

  • Im Hyper-V Manager der virtuellen Maschine unter ComPort eine Named Pipe z.b. “ComForwarding” einfügen
  • Terminal / Cmd prompt mit Adminstratorrechten starten und
  • ComPipe ausführen:  COMpipe -c \\.\COM2 -p \\.\pipe\ComForwarding

LineageOS 17.1 auf Moto G5

Dies ist keine Anleitung, sondern nur eine Sammlung der Dinge die ich machen musste um LinageOS17.1 auf ein Moto G5 (auch bekannt als Cedric XT1676) zu flashen, welches vorher auf einem Stock Android 8.1.0 lief.

Wer es nachmacht macht das auf eigene Gefahr und ich übernehme keinerlei Haftunge. Beim Unlocken des Bootloaders erlischt die Herstellergarantie und beim Flashen gehen die Daten (Bilder usw. verloren).

  1. Developer Modus aktivieren
    1. In den Einstellungen des Moto G5 auf “Über Telefon” gehen dort dann auf der Buildnummer sieben mal klicken
    2. In den Entwickleroptionen dann “OEM Bootloader freischalten” aktivieren
  2. Bootloader unlocken (freischalten)
    1. Auf der Motorola unlock-your-device Seite (oder hier) anmelden
    2. Android Platform Tools installieren (um ADB und Fastboot zu erhalten)
    3. Motorola Device Manager installieren (um die richtigen Treiber zu erhalten)
    4. Handy per USB mit dem Computer verbinden, “adb reboot bootloader” ausführen, das Handy startet neu im “AP Fastboot Flash Mode (Secure)”
    5. Mit “fastboot devices” feststellen ob das Gerät erkannt wurde (wenn nicht, mal im Windows Gerätemanager schauen)
    6. Mit “fastboot oem get_unlock_data” die Unlockdaten erhalten und auf der Motorola Seite den die Unlock-Data eingeben um den [UNIQUE_KEY] zum erhalten
    7. Mit “fastboot oem unlock [UNIQUE_KEY]” den Bootloader unlocken,
    8. Ggf. nochmal “fastboot oem unlock [UNIQUE_KEY]” ausführen um den Bootloader zu unlocken
  3. TWRP Recovery Rom flashen
    1. “fastboot flash recovery twrp-3.2.1-cedric-vendor-v4.img”
  4. Backups von Persistent und EFS
    1. ins Recovery rom booten (Lautstärke leiser + Power drücken, dann nacheinander loslassen)
    2. Backup der EFS Partition
    3. Dann unter Advanced, Terminal mit dd die persist partition kopieren:
      1. dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
      2. cp /sdcard/persist.img /external_sd
  5. LinageOS flashen
    1. Ins Recovery Rom booten (Lautstärke leiser + Power drücken, dann nacheinander loslassen)
    2. ggf. unter Mount die sd karte mouten
    3. Unter “Install” das Lineage ROM flashen
  6. GApps flashen
    1. OpenGapps Arm64, Android 10, >=Mini Nano auswählen und auf der SDKarte speichern
    2. Im Recovery Rom unter Install die GApps flashen

Freitag, 2. Oktober 2020

Shelly 1PM, Fluxdb und Grafana

Eigentlich wollte ich nur schnell einen Shelly 1PM installieren um den Stromverbrauch an einer Teilstrecke einer Phase zu protokollieren.

Da mir die Visualisierung von Grafana sehr gefällt, möchte ich den Verlauf des Stromverbrauchs in einer FluxDB ablegen und in Grafana darstellen und auswerten.

Shelly 1PM sollte dabei keine Verbindung zum internetaufbauen, ebenso sollten FluxDB und Grafana nur im lokalen LAN auf einer Synology DS212+ laufen (ärgerlich das die FluxDB per default direct Nutzungsdaten nach Hause sendet).

Normalerweise wäre die installation von Grafana und FluxDB recht einfach auf der Synology über Docker möglich. Jedoch wird die DS212+ nicht unterstütz, sondern lediglich die folgenden Modelle:

  • Serie 20:FS6400, FS3400, RS820RP+, RS820+, DS620slim, SA3600, SA3400, SA3200D
  • Serie 19:RS1619xs+, RS1219+, DS2419+, DS1819+, DS1019+, DVA3219
  • Serie 18:FS1018, RS3618xs, RS2818RP+, RS2418RP+, RS2418+, RS818RP+, RS818+, DS3018xs, DS1618+, DS918+, DS718+, DS218+
  • Serie 17:FS3017, FS2017, RS18017xs+, RS4017xs+, RS3617xs+, RS3617RPxs, RS3617xs, DS3617xs, DS1817+, DS1517+
  • Serie 16:RS18016xs+, RS2416RP+, RS2416+, DS916+, DS716+, DS716+II, DS216+, DS216+II
  • Serie 15:RS815RP+, RS815+, RC18015xs+, DS3615xs, DS2415+, DS1815+, DS1515+, DS415+
  • Serie 14:RS3614xs+, RS3614RPxs, RS3614xs, RS2414RP+, RS2414+, RS814RP+, RS814+
  • Serie 13:RS10613xs+, RS3413xs+, DS2413+, DS1813+, DS1513+, DS713+
  • Serie 12:RS3412RPxs, RS3412xs, RS2212RP+, RS2212+, RS812RP+, RS812+, DS3612xs, DS1812+, DS1512+, DS712+, DS412+
  • Serie 11:RS3411RPxs, RS3411xs, RS2211RP+, RS2211+, DS3611xs, DS2411+, DS1511+, DS411+, DS411+II
  • *Serie 10:RS810RP+, RS810+, DS1010+, DS710+

Python3

Python3 selbst gibt es auch für die DS212+ im Synology Store.

Den Paketmanager pip bekommt man per:

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py 
sudo python3 get-pip.py

Um später mit der influxDB zu kommunizieren (und dort die protokollierten Daten abzulegen) benutze ich das Paket FluxDB:

sudo python3 -m pip install influxdb
vormals habe ich das alte, inoffizielle paket influx-client genommen, was auch gut funtkioniert:
sudo python3 -m pip install influx-client

Um die Daten vom Shelly 1PM auszulesen benutze ich ShellPy

sudo python3 -m pip install ShellyPy==0.1.4

FluxDB

Zunächst habe ich mir einen neuen User “iot” erstellt und in dessen home directory folgendes gemacht:

wget https://dl.influxdata.com/influxdb/releases/influxdb-1.7.10_linux_armhf.tar.gz
tar xvfz influxdb-1.7.10_linux_armhf.tar.gz

danach die dateien

  • influx 
  • influxd 
  • influx_inspect 
  • influx_stress 
  • influx_tsm

in aus dem entpackten Archiv in eine neuen Ordner “influxdb” bewegt.Dort habe ich dann eine neue Datei “influxd.conf” erzeugt mit folgendem Inhalt:



#only start this service after the httpd user process has started
start on started httpd-user

# stop the service gracefully if the runlevel changes to 'reboot'
stop on runlevel [06]

# run the scripts as the 'iot' user. Running as root (the default) is a bad idea.
setuid iot

# exec the process. Use fully formed path names so that there is no reliance on $PATH
exec /volume1/homes/iot/influxdb/influxd -config /volume1/homes/iot/influxdb.conf

dann habe ich noch die datei “influxdb.config” aus dem Archiv in das homeverzeichnis kopiert und die Verzeichnisse für log, meta angepasst, sodass auch diese nach /volume1/homes/iot/influxdb/ schreiben.

Dann das ganze versucht zu starten, nachdem es geklappt hat eine Verknüpfung zum Autostart hinzugefügt:

sudo ln -s influxd.conf /etc/init/influxd.conf

dann gemerkt, dass Synology die dinge Dort nicht ausführt und am Ende herausgefunden, dass man mittlerweile über den Aufgabenplaner Aufgaben nach dem Systemstart ausführen lassen kann:

imageimage

Grafana

Zuerst habe ich es mit folgendem Aufruf probiert:

wget https://dl.grafana.com/oss/release/grafana-6.6.2.linux-arm64.tar.gz 
tar -zxvf grafana-6.6.2.linux-arm64.tar.gz

und  später auch mit den anderen ARM packages probiert – leider ohne Erfolg. Auf Synolgogy DS212+ läuft ein Prozessor der armv5 kompatibel ist – leider bietet Grafana kein entsprechendes Paket an und für das selbst bauen fehlt mir die Zeit.

Chronograf

Auch Chronograf funktionierte leider nicht auf der DS212:

wget https://dl.influxdata.com/chronograf/releases/chronograf-1.8.0_linux_armhf.tar.gz
tar xvfz chronograf-1.8.0_linux_armhf.tar.gz

Aber das lasse ich nun einfach unter windows per “chronograph –r” laufen.

Mittwoch, 16. August 2017

Bitcoin Transaction kommt nicht an

Meist sind zu niedrige Gebühren schuld, dass Bitcoin Transaktionen unbestätigt bleiben. Dieses liegt m.E. vor allem an der schlechten Bitcoin-Core GUI und es kann zu leicht passieren, dass zu geringe Gebühren berechnet werden und die Transaction auch nach Tagen noch “unconfirmed” ist.

Nun hat man mehrere Möglichkeiten:
  • Noch länger warten und hoffen
  • Ist man Empfänger kann man per “Child-Pays-For-Parent” versuchen mit höheren Gebühren die eingehende Transaktion direkt weiter zu verwenden
  • Die Transaktion “übersteuern” indem die gleichen Coins “nochmal”, dieses mal mit höheren Gebühren, ausgegeben werden (double spending)
  • Durch das Verfahren “Replace by Fee (RBF)” könnte man noch im Nachgang die Gebühr erhöhen. Dazu hätte aber der Bitcoin Core Client vorher mit der Option “-walletrbf” gestartet werden müssen um RBF-Transaktionen zu erstellen.

Meist ist das nicht der Fall. Ich gehe daher wie folgt vor:

  • Zunächst verhindere ich, dass meine Transaction von meinem Client erneut gesendet wird. Dieses erreiche ich, in dem ich den Bitcoin Core Qt client mit der Option -walletbroadcast=0 starte
  • In der GUI suche ich die betreffende Transaktion, wähle diese aus und wähle “Abandon transaction”. Was in der deutschen GUI etwas sperrig mit “Transaction einstellen” übersetzt ist.
  • Wenn das Feld ausgegraut ist, kann man versuchen den Befehl über per RPC abzusetzen. Hierzu kopiert man sich vorher die Transaktions ID und führt den Befehl abandontransaction <txid> im Debug Fenster / Konsole aus.

Falls die Fehlermeldung

Transaction not eligible for abandonment (code -5)

erscheint, beende ich den Bitcoin core client, suche das Daten-Verzeichnis und Lösche die Datei “mempool.dat”.

Danach starte ich den Client erneut und nun sollte “Transaktion Einstellen” auswählbar sein bzw. der RPC Befehl abandontransaction erfolgreich durchgeführt werden.

Später wieder daran denken die Option -walletbroadcast zu entfernen.

Sonntag, 23. April 2017

Asus AsSysCtrlService und asComSvc deinstallieren

Gerade habe ich gemerkt, dass die Deinstallation des Asus Programmes “AI suite” leider nicht alle Dienste und Dateien entfernt.

Besonders ärgerlich ist, dass ein Dienst asComSvc relativ Viel Arbeitsspeicher nutzt und diesen nicht wieder frei gibt. Offenbar ein Memoryleak.

Um die betreffenden Dienst zu stoppen und danach zu deinstallieren (die Dateien bleiben in C:\Program Files (x86)\ASUS\ vorhanden, werden aber zukünftig nicht als Dienst gestartet) geht man wie folgt vor:

  • Windows Taste + x drücken
  • Eingabeaufforderung “"(Administrator)” auswählen
  • dort dann folgendes eingeben und jeweils bestätigen:
    • sc stop AsSysCtrlService
    • sc delete AsSysCtrlService
    • sc stop asComSvc
    • sc delete asComSvc

Donnerstag, 19. Januar 2017

Keepass: Konflikte vermeiden

Ich nutze derzeit das Synology Cloud Station Drive also Dropbox-Ersatz im Heimnetz. Leider gab es bislang Probleme, wenn mit Keepass Dateien gleichzeitig auf mehreren Rechnern geöffnet bzw. bearbeitet wurden. Da Keepass eine Sychronisierungsfunktion bietet, lassen sich die Konflikte jedoch vermeiden wenn man der entsprechenden Keepass Anleitung folgt und nur noch indirekt (per Synchronisation) auf diejenige Datei zugreift, die per Cloud Station Drive im Heimnetz verteilt wird.