Skip to content

Debian auf einem PCEngines APU2 installieren

^ v M ><
Normalerweise nutze ich die APU's mit pfsense oder opnsense als Firewall, aber diesmal soll ein etwas multifunktionaleres OS drauf, daher wie üblich: Debian.

Die Anleitungen lesen sich simpel. einfach Installer auf USB-Stick schreiben, USB-Stick rein, Serial-Kabel rein, anschalten, installieren, läuft.
Wie immer sind die Anleitungen gelogen. Es ist nie einfach. Es ist immer unnötig fucking kompliziert.

Erstes Problem: Der Installer lädt nicht. Es hängt nach ISOLINUX. Klar, der Installer kann kein Serial. Also: Netinstall-CD patchen, neu bauen, nochmals versuchen. Etwas Hilfe leistet dieser Github-Gist:
- Netinstall-Image herunterladen
- lokal mounten: mount -o loop debian-10.7.0-amd64-netinst.iso /mnt/temp/
- Arbeitsverzeichnis erstellen: mkdir iso-rework
- Kopieren: cp -r /mnt/temp/. iso-rework/
- Dateien bearbeiten: cd iso-rework/isolinux && chmod +w *.cfg
- in isolinux.cfg die Zeile SERIAL 0 115200 0 einfügen
- in txt.cfg die letzte Zeile ersetzen mit append gfxpayload=text console=ttyS0,115200 initrd=/install.amd/initrd.gz --- quiet
- wieder ins übergeordnete Verzeichnis zurückwechseln: ../..
- ISO neu bauen: xorriso -as mkisofs -rational-rock -joliet -joliet-long -full-iso9660-filenames -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -appid "Debian10.7" -eltorito-boot isolinux/isolinux.bin -eltorito-catalog isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso iso-rework
- und nun den USB-Stick neu bespielen: dd if=debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso of=/dev/sdX bs=4M && sync

JETZT kann man das Ding einstecken und "einfach" booten.
Nächstes Problem: Konsolenoutput ist unleserlich. Lösung Teil 1: USB-Serial-Kabel nicht in einen USB-Hub sondern direkt in den PC stecken. Lösung Teil 2: Putty verwenden. Aber das lässt sich grafisch nicht konfigurieren (denn das wäre ja einfach), also muss man es von der Kommandozeile richtig aufrufen: putty /dev/ttyUSB0 -serial -sercfg 115200,8,n,1

Über Putty kann man nun schön beobachten, wie BIOS und Isolinux geladen werden und die Installationsauswahl angezeigt wird. Natürlich nicht "Graphical Installer" sondern "Install" (für Textinstallation) wählen. Das klappt bei mir jedoch nicht über serial... Ich brauche eine USB-Tastatur...

Nochmals von vorn. Und: Es lädt den Textinstaller. Doch kommen wir nun zum major fuckup des Tages, der mich extrem viel Zeit kostete, um mit Boot-Optionen zu experimentieren, es mit Debian 9 zu versuchen und sogar ein anderes APU zu probieren, um auszuschliessen, dass nicht ein Hardware-Defekt vorliegt:
Nun stecke ich in der Sprachauswahl des Installers und da geht wieder nichts mehr. Ich kann keine Sprache auswählen. Ich kann Tab, Space, Enter drücken, nichts passiert. Ich kann Eingaben über Putty versuchen, nichts passiert. Tatsächlich scheint dies ein bekanntes Problem von ein paar Laptops zu sein.
Irgendwann fand ich die brachiale Lösung: Nach Auswahl des Installers sofort die USB-Tastatur ausstecken, bevor der Kernel zu weit geladen hat. Dann über Putty weiterarbeiten.

Wieder einmal: Eine supereinfache Tätigkeit, zur völligen Perversion verkompliziert. Einfach, weil nichts "einfach" sein darf. One does not simply. Nicht wahr, Boromir?

OpenHAB vs Xiaomi Sensoren

^ v M ><
Vor einiger Zeit habe ich angefangen, mit OpenHAB das Monitoring von meinen Servern auf die ganze Wohnung auszuweiten. U.a. wäre es schön zu wissen, ob ich den Tiefkühler im Keller wieder geschlossen oder doch die Tür aus lauter Senilität offen gelassen habe. Entsprechende Sensoren gibt es schon für relativ wenig Geld z.B. von Xiaomi (oder für massiv mehr Geld auch von anderen Herstellern, ob die dann einfacher einzubinden sind, ist die grosse Frage). Allerdings ist die Einbindung der Xiaomi-Sensoren in OpenHAB eine chinesische Oper in mehreren Akten:

Akt 1: Das Starterset

Das Starterset gibt's für rund 80.- und es kommt mit einem Druckschalter, zwei Türsensoren und zwei Bewegungsmeldern sowie der Basisstation. Gemäss Beschreibung ist alles ganz einfach: Die Basisstation starten, auf einem Android-Telefon die Mihome-App installieren, als Serverstandort "Mainland China" wählen, App mit der Basisstation verbinden, über ein verstecktes Menü den Developer-Mode aktivieren, den Key auslesen und damit die Basisstation in OpenHAB integrieren.
Dann wäre alles ganz einfach mit einem Datenfluss Sensor -> Xiaomi-Hub -> OpenHAB.
Ja, aber...
Genau, denn das ganze geht nur mit der Basisstation "Mainland China Edition", welche in Europa nicht erhältlich ist. Vermutlich kann man sie über einen chinesischen Grosshändler von Übersee liefern lassen (Reisestromadapter nicht vergessen, chinesische Stecker passen nicht in europäische Steckdosen). Aber die EU-Edition ist unbrauchbar:
- wählt man in der App Serverstandort "Mainland China", so lässt sich die Basisstation nicht finden und somit auch nicht verbinden
- wählt man Serverstandort "Europa", so fehlt das versteckte Menü, um den Developer-Mode zu aktivieren.

Akt 2: Veraltete App

Mit etwas Recherche ergab sich, dass auf dubiosen Seiten eine veraltete Version der Mihome-App zu finden ist, welche einen Fehler enthält: Sie schreibt ein Debug-Log. Worin der Zugriffskey zu finden ist. Leider hilft der alleine nicht weiter. Damit kann man zwar über die Xiaomi Mi IO Erweiterung von OpenHAB den Hub einbinden. Aber das war auch schon alles. Auf die Sensoren hat man deswegen noch keinen Zugriff. Dafür müsste weiterhin der Developer-Mode aktiviert werden, welcher auch einen Telnet-Zugang auf dem Gerät öffnet.

Nun gäbe es noch zwei weitere Optionen: Eine modifizierte Mihome-App von einer russischen Website, die komplett in kyrillisch gehalten ist. Nun äääh... Njet! Oder aber den Lötkolben auspacken, den seriellen Port abgreifen, sich damit Terminal-Zugang verschaffen und darüber den Telnet-Server aktivieren. Nun, da dies mit guter Wahrscheinlichkeit das Gerät schrotten kann, lasse ich das auch (vorerst) lieber. Immerhin könnte ich es noch weiterverkaufen, solange es noch funktioniert.

Akt 3: Der Aqara-Hub

Ein erneuter Blick in die Dokumentation des Mihome-Bindings zeigt: Der Hub in Version 3 (welcher als Aqara Hub für Apple Homekit im Handel ist), soll etwas zugänglicher sein. Der kostet leider alleine schon fast so viel wie das ganze Set. Und kann dann genau so wenig. Entsprechend habe ich den umgehend wieder zurückgesendet...

Akt 4: Billiger Zigbee-Stick

Die Xiaomi-Geräte halten sich, wie aller proprietärer Müll, natürlich nie ganz genau an die Standards. Aber immerhin genug, dass das Protokoll noch knapp als Zigbee durchgeht. Also habe ich für 9€+3.50€ Versand beim reichsten Mann der Welt einen USB-Zigbee-Stick gekauft. Zu meiner grossen Überraschung wurde dieser, obwohl Elektrogerät, vom reichsten Mann der Welt seinem Marktplatz aus Deutschland über den Rhein versendet. Sehr unüblich. Und kam auch superschnell an. Ebenfalls unüblich.
Es handelt sich um einen simplen USB-Stick mit CC2531-Chip und zigbee2mqtt-kompatibler Firmware vorinstalliert. Sehr genial!

Grundsätzlich würde OpenHAB zwar den Zigbee-Stick direkt über das Zigbee-Binding ansprechen können. Der Datenfluss wäre dann Sensor -> USB-Stick -> OpenHAB. Aber da war doch bei Xiaomi was mit Protokollstandard und sich daran halten. So lassen sich die Sensoren zwar einbinden, werden aber als "offline" angezeigt und es lässt sich kein Status abfragen. Es gilt also wie üblich: wieso einfach, wenn es auch kompliziert geht?

Nun beginnt die von-hinten-durch-die-Brust-ins-Auge-Installation für den Datenfluss Sensor -> USB-Stick -> zigbee2mqtt -> mqtt-broker -> OpenHAB.
Als erstes wird der Stick angeschlossen, dieser wird als USB-Serial-Gerät /dev/ttyACM0 erkannt.
Nun muss ein MQTT-Broker installiert werden, z.B. mosquitto aus den Debian-Paketquellen. Dieser wird ohne weitere Konfiguration gestartet.
Als nächstes wird zigbee2mqtt mit gefühlt zweitausend Node.JS-Abhängigkeiten installiert (u.a. npm aus den Debian Backports, wenn man Debian Stable als Basis nutzt). Dies ist, im Gegensatz zum später folgenden OpenHAB-Teil, hervorragend dokumentiert, so dass sich dieser Teil eher als Malen-nach-Zahlen denn Systemadministration anfühlt.
Nun können die Geräte im Prinzip schon eingebunden werden. Dazu einfach den Sensor mit der in der Packung beiliegenden SIM-Pin resetten, und gut. Gemäss Anleitung kann es sein, dass man den Vorgang mehrmals wiederholen muss, bei den ersten beiden Sensoren hat es aber jeweils auf anhieb geklappt. Ein Blick in journalctl -u zigbee2mqtt -f zeigt denn auch gleich Aktivität an.
Jetzt kommt der harte Teil: OpenHAB mit MQTT verbinden. Das ist sehr oberflächlich und abstrakt dokumentiert. Dazu kommt beim Googeln nach Lösungen das Chaos mit Anleitungen für MQTT1- und MQTT2-Binding hinzu. Welche nun bei meiner Installation gilt? Böh? Letztendlich habe ich die Anleitungen für MQTT2 befolgt, das hat irgendwann auch funktioniert. Vermutlich: MQTT1==OpenHAB1, MQTT2==OpenHAB2 (und bei mir läuft 2.5).

Wie also vorgehen:
In der zigbee2mqtt-Konfigurationsdatei /opt/zigbee2mqtt/data/configuration.yaml den Output nicht als JSON sondern Attribut ausgeben lassen. Dazu folgende Zeilen einfügen, speichern, zigbee2mqtt neu starten:
experimental:
    output: attribute
Und wenn wir schon in der Konfiguration herumfummelt, sollte man auch gleich den Sensoren vernünftige friendly_name vergeben.
Zuerst das MQTT-Binding in OpenHAB installieren.
Dann in /etc/openhab2/things/ eine .things-Datei mit den nötigen Einträgen erstellen. Irgendwann habe ich im Forum halbwegs taugliche Anleitungen gefunden...
Und sich nun wundern, dass die Things zwar im GUI auftauchen, aber keinerlei Daten gelesen werden... Signalstärke? NaN. Batterielevel? NaN. Zustand? Off. grrrmpf. Nach langem Debuggen (ja, zigbee2mqtt schreibt in mosquitto, mittels mosquitto_sub -v -t '#' kann man da schön mitlesen) irgendwann einfach mal den spontanen Windows-Reflex ausgelöst und OpenHAB selbst neugestartet. Uuund! Bingo! Alles tut. So einfach! Der Neustart ist übrigens für jedes neu hinzugefügte (oder umbenannte) Gerät nötig.

Das Finale: die OpenHAB-Things-Datei

Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [ host="127.0.0.1", secure=false] {
  Thing topic xdoor1 "Xiaomi Door Sensor" @ "Location" {
  Channels:
    Type switch : contact "contact" [ stateTopic = "zigbee2mqtt/xdoor1/contact", on="true", off="false" ]
    Type number : voltage "voltage" [ stateTopic = "zigbee2mqtt/xdoor1/voltage" ]
    Type number : battery "battery" [ stateTopic = "zigbee2mqtt/xdoor1/battery" ]
    Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/xdoor1/linkquality" ]
  }
}

Weitere Sensoren lassen sich nun einfach dem Bridge-Block hinzufügen. Mit etwas mehr Tippaufwand lassen sich auch Sensoren ausserhalb des Bridge-Blocks definieren:
Thing mqtt:topic:MosquittoMqttBroker:BodySensor "Xiaomi Body Sensor" (mqtt:broker:MosquittoMqttBroker) @ "Location" {
  Channels:
    Type switch : occupancy "occupancy" [ stateTopic = "zigbee2mqtt/xbody1/occupancy", on="true", off="false" ]
    Type number : voltage "voltage" [ stateTopic = "zigbee2mqtt/xbody1/voltage" ]
    Type number : battery "battery" [ stateTopic = "zigbee2mqtt/xbody1/battery" ]
    Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/xbody1/linkquality" ]
}
Die vorhandenen Channels lassen sich per mosquitto_sub oder journalctl herausfinden. Sobald man einen Sensor stimuliert, sendet er alle diese Angaben an den Zigbee-Controller.

Applaus

Natürlich is OpenHAB gerade in Kombination mit Zigbee (oder Z-Wave) bezüglich Möglichkeiten ein Fass ohne Boden. Schon ohne Funkanbindung lässt sich einiges an Technik anbinden: Drucker, Mail- und XMPP-Konten, WLAN (bzw dazu verbundene Endgeräte), Telefonanlagen, mpd (Music Player Daemon), Videokameras (z.B. via Zoneminder - aber das wäre ein Blogeintrag für sich). Mit Zigbee wird alles noch viel wilder. Nach den Sensoren kann das ganze restliche Haus eingebunden werden, von Lampen, Heizung und Rolladensteuerung über die Waschmaschine zum Rasenmäher bis zur Wallbox des Elektrofahrzeugs.
Wenn weitere Zigbee-Sensoren/Aktuatoren etwas weiter weg aufgestellt werden sollen, nimmt man einfach einen Raspberry Pi, schliesst daran einen weiteren USB-Stick an, installiert zigbee2mqtt und lässt damit die Sensordaten übers Netzwerk an den MQTT-Broker auf der OpenHAB-Maschine senden.

LineageOS auf Galaxy S2 (i9100) installieren

^ v M ><
Mir ist ein altes Samsung Galaxy S2 in die Hände gekommen, das für einen potentiellen Empfänger tauglich gemacht werden sollte. Bislang war bereits ein etwas in die Jahre (oder doch nur Monate?) gekommenes Cyanogenmod installiert. Aber Cyanogenmod ist tot, darum soll auf jeden Fall aktuellste Software installiert werden. Da kommt fast nur LineageOS in Frage (v.a. auch da ich damit gute Erfahrungen auf S3 und S5 gemacht habe). Da der Empfänger noch empfindlicher auf seine Privatsphäre achtet als ich, habe ich die Google-Apps weggelassen. Diese zu installieren benötigt aber nur einen weiteren Befehl und zwei Klicks mehr in der Recovery.

Leider war die Installation nicht ganz einfach, da die /system-Partition erstens nur 500MB gross ist (das ist zu klein, LineageOS verlangt mindestens 600MB), zweitens einen Defekt hat und drittens alle im Internet gefundenen Anleitungen zur Installation und Repartitionierung falsch sind, insbesondere die offizielle Anleitung von LineageOS. Ausserdem sind die meisten Anleitungen von Windows-Schafen geschrieben und nutzen Odin, während mir unter Linux Heimdall zur Verfügung steht.

Als Voraussetzung für diese Anleitung setze ich voraus, dass der Leser mit TWRP bereits vertraut ist. Ausserdem gilt ganz klar: Anwendung auf eigene Gefahr!

Beim i9100 sind ein paar Spezialitäten zu beachten, so ist das Recovery-Image in das Kernel-Image integriert.

So hat's bei mir funktioniert:
Erst sichergehen, dass auf dem Computer die aktuellsten Versionen von heimdall und adb installiert sind.
Download von PIT-Dateien (eine Art Partitionstabelle für Samsung-Geräte) von hier
Download von TWRP (Custom Recovery) von hier
Download des aktuellsten LineageOS-Build von hier
Ggf Download des su-addons und/oder gapps, wenn benötigt.
Aus lineage-14.1-*-nightly-i9100-signed.zip muss die Datei boot.img extrahiert werden.
Aus Pit_files.rar muss die gewünschte PIT-Datei extrahiert werden, ich habe I91001GB_4GB.pit (1GB /system, 4GB /data) verwendet.

Boot des Telefons in den Download-Modus mittels VolDown-Home-Power (Bestätigen mit VolUp). Anschliessend das USB-Kabel anschliessen.
Upload des neuen PIT-Files und flashen der Recovery mittels:
heimdall flash --repartition --pit I91001GB_4GB.pit --RECOVERY twrp-3.1.0-0-i9100.img --KERNEL boot.img --no-reboot

Danach das Telefon ausschalten, das USB-Kabel ausziehen, kurz die Batterie entfernen (ansonsten liess es sich bei mir nicht wieder booten), Batterie wieder einfügen.
Start des Telefons in den Recovery-Modus mittels VolUp-Home-Power
TWRP sollte nun starten. In TWRP den Menüpunkt "Wipe" -> "Advanced Wipe" -> "System" -> "Repair or Change File System" -> "Resize File System". Bei Erfolg auf "back" klicken und in der Übersicht auf "Change File System" -> "ext4". In der Übersicht wird die Dateisystemgrösse falsch angezeigt, evtl sogar als 0 Byte. Dies ignorieren. Nach erfolgter Reformatierung auf "back" klicken. In der Übersicht sollte jetzt korrekt 1007MB als Dateisystemgrösse angezeigt werden. Dasselbe Spiel für "Data" und "Internal Storage" wiederholen. Es können dabei viele rote Fehler angezeigt werden, dass Partitionen nicht eingebunden werden können. Dies kann (hier) ignoriert werden.
Nun das Telefon wieder ausschalten, Batterie raus und wieder rein, und erneut in den Recovery-Modus booten.
in TWRP erneut auf "Wipe" -> "Advanced Wipe" und einen gleichzeitigen Wipe von Dalvik, Cache, System, Data und Internal Storage durchführen. Wenn keine roten Fehlermeldungen erscheinen, kann der Flash-Vorgang beginnen. Ansonsten muss so lange mit der Reformatierung herumgespielt werden, bis es klappt.

Nun das USB-Kabel wieder anschliessen und mittels adb die zu installierenden zip-Dateien hochladen:
adb push lineage-14.1-*-nightly-i9100-signed.zip /sdcard0/
Wichtig! Der interne Speicher heisst /sdcard0/, nicht /sdcard/, wie in vielen Anleitungen behauptet!

In TWRP nun auf Install gehen und die zip-Dateien gemäss handelsüblicher Anleitungen flashen. That's it. Uff. Ja, ist kompliziert und viel unnötiger Aufwand.

Update: Ein Leser weist mich auf diese hervorragende Anleitung hin... für Windows :-P

Update: Ein weiterer Leser gibt noch zwei Tipps mit:
1. Wenn es mit dem Download der PIT-Datei nicht funktioniert, anderes USB-Kabel, bzw. anderen USB Port benutzen. Den Tipp gab's an verschiedenen Stellen und hat mir geholfen.

2. Ich habe es dann ums verrecken nicht geschafft, per "adb" etwas auf's Handy zu schieben. Ich habe es dann letztendlich auf eine Micro-SD karte kopiert, die ins Handy gesteckt und von dort installiert.

Android und Linux verknüpfen: KDE Connect (ohne KDE)

^ v M ><
Per Zufall bin ich auf eine sehr coole Software gestossen: KDEConnect. Damit lässt sich ein Android-Telefon von einem Linux-PC aus fernsteuern. Oder der Linux-PC lässt sich von einem Android-Telefon aus fernsteuern. Oder man kann recht bequem Dateien zwischen Telefon und PC austauschen. Einzige Bedingung: Beide Geräte müssen sich im gleichen lokalen Netzwerk befinden (ob WLAN, kabelgebunden oder gemischt ist egal).

Wie es der Name schon sagt, ist KDEConnect eigentlich für die KDE-Desktopoberfläche entwickelt worden. Mit ein Bisschen tricksen läuft es aber auch relativ gut unter schlankeren Desktops wie z.B. dem von mir präferierten XFCE. Als erstes sollte es auf dem Telefon installiert werden, das geht bequem aus dem Play Store (oder wie f-droid auf Google-freien Systemen). Nun kann es gleich gestartet werden und auf einen paarungsbereiten PC warten.
Danach muss es mitsamt einiger Abhängigkeiten auf eben diesem PC installiert werden (hier wie immer für Debian Jessie erklärt):
aptitude install kdeconnect qdbus-qt5 kde-runtime

Nun müssen die KDE-Hintergrunddienste initialisiert werden:
$ qdbus org.kde.kded /kded loadModule kdeconnect
true
$ kbuildsycoca4 -noincremental

Und schon sollte es tun:
$ kdeconnect-cli --list-devices
- Samsung Galaxy S III: xxxxxxxxxxxxxxx (reachable)
1 devices found
$ kdeconnect-cli --pair --device xxxxxxxxxxxxxxx

Benachrichtigungen des Telefons poppen nun fröhlich auf dem Desktop auf.

Als Feinschliff kann noch das indicator-Applet installiert werden, damit Telefoninformationen im Systray dargestellt werden. Dieses ist leider noch nicht in Debian stable enthalten und muss händisch kompiliert werden. Immerhin war der Autor aber so freundlich, schon die ganzen Debian-Paketierdaten zur Verfügung zu stellen, so dass im Handumdrehen ein .deb-Paket erstellt werden kann, das eine saubere Installation (und Deinstallation) der Software erlaubt.
$ git clone https://github.com/vikoadi/indicator-kdeconnect.git
$ aptitude install build-essential valac libappindicator3-dev libgtk-3-dev debhelper #ggf weitere Pakete nötig
cd indicator-kdeconnect
$ dpkg-buildpackage -rfakeroot -uc -b
$ cd ..
$ su
# indicator-kdeconnect_0.1_amd64.deb
# exit
$ indicator-kdeconnect


Das ist echt ein Tool, das ich schon lange gebraucht habe (ohne es zu wissen) :-)

CyanogenMod aufs Galaxy S5

^ v M ><
Gestern hat das Unfairphone zwar nochmals ein Software-Update erhalten, das zwar an der Oberfläche kratzt (z.B. Bildschirmflackern behebt oder den sinnlosen Privacy Indicator angeblich endlich deaktivierbar macht), aber die richtigen Probleme (fehlende Konfigurationsmöglichkeiten, fehlender Privacy Guard, fehlende Unterstützung für Dateisysteme) natürlich nicht behebt. Aber das ist dennoch zu spät, denn heute hat mir der Pöstler Ersatz geliefert. Diesmal ein von im Vergleich zum Unfairphone nicht ganz so glücklichen Chinesen zusammengeklebtes Galaxy S5. Warum so ein altes Gerät? Nun, im Prinzip ist es dasselbe wie das Unfairphone, nur in irreparabel, leicht und ohne zweiten SIM-Slot. Ansonsten ist die Hardware ziemlich identisch. Und: Es gibt eine recht solide Unterstützung durch CyanogenMod!

Gemäss Anleitung ist die Installation so kinderleicht wie beim S3. Doch der Teufel liegt wie immer im Detail. Erst startet man das Gerät mittels VolDown-Home-Power im Download-Modus und installiert ein Recovery-Image:
heimdall flash --RECOVERY twrp-3.0.2-1-klte.img --no-reboot
Heimdall v1.4.0
[..]
ERROR: Failed to download PIT file!

Muh! Wäre ja zu schön, wenn es auch nur ein einziges Mal einfach wäre!

Also muss als erstes Heimdall auf die letzte Version von github aktualisiert werden. Wie bei all meinen technischen Einträgen wird Debian als Basis verwendet. Bevor nun irgend ein Troll meint, na klar, mit der Uralt-Version aus Debian ist das auch kein Wunder: den Spruch kann man sich hier sparen, da auch die letzte offiziell veröffentlichte Version von Heimdall (1.4.1) nicht ausreicht. Es muss zwingend die Version aus dem git-Repository sein!
aptitude install build-essential cmake libusb-1.0-0-dev qt5-default libgl1-mesa-glx libgl1-mesa-dev
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd bin

Nun kann erneut gemäss Anleitung versucht werden zu flashen:
./heimdall flash --RECOVERY /path/to/twrp-3.0.2-1-klte.img --no-reboot

D.h. man startet die Recovery mittels VolUp-Home-Power. Als kleinen Umweg habe ich mittels des gestarteten Recovery erst ein Backup erstellt und dieses mit ADB auf den Desktop-Computer kopiert:
adb pull /sdcard/TWRP TWRP

Danach kann man aber wirklich gemäss Anleitung weitermachen, ein möglichst minimales Google-Apps-Paket installieren und sich an einem relativ schlanken, funktionalen Telefon mit verstärktem Schutz der Privatsphäre erfreuen.

Und das Unfairphone? Wird wegen Nichtgebrauchs verkauft. Und das S3? Wird zur Bastelplattform umfunktioniert.

Line Messenger unter (Debian) Linux mit Pidgin

^ v M ><
Um Kontakt nach Fernost zu halten, bestand die Notwendigkeit einer Messenger-Lösung, die auf Mobilgeräten und Desktops (und zwar idealerweise als Plugin für Pidgin) läuft, Videotelefonie beherrscht und nicht von Microsoft stammt. Somit fällt Skype weg, da unterdessen zum Evil Empire aus Redmond zugehörig. WhatsCrap fällt auch weg, da nicht (legal) abseits eines einzelnen Mobilgeräts nutzbar. Viber fällt auch weg, da von keiner der bestehenden Parteien genutzt. XMPP hat seine lieben Probleme mit der Videotelefonie (und wird ausserdem nur von mir, nicht aber den Gegenparteien genutzt... seufz...).

Die Desktop-Anforderung ist für mich ein zwingendes Argument, da mir die Fummelei auf dem Telefon einfach zu mühsam ist. Ausserdem will ich nicht alle paar Sekunden die Hände von der Tastatur nehmen und das Gerät wechseln. Der Wechsel zwischen produktiver Arbeitsumgebung und Messenger ist gerade noch akzeptabel.

Die Notlösung hierfür heisst "Line Messenger" aus Korea, ist in Japan super populär und die Verwendung unter Linux selbstverständlich ein Gefrickel ohne offizielle Absegnung. Aber immerhin gibt es ein inoffizielles Plugin für Pidgin. Dessen Installation funktioniert relativ gut gemäss Anleitung auf der verlinkten Seite (code_name bei Debian ist stable, testing oder unstable, bei Ubuntu der jeweilige Release-Name, d.h. trusty, vivid oder wily). Ein paar Worte zur Einrichtung wären aber nicht verkehrt gewesen...

Zuerst muss man Line auf einem Mobilgerät installieren, ein Konto erstellen und damit Online gehen. Als nächstes muss eine Email-Adresse verknüpft werden, das macht man durch Klick auf das Icon [...] rechts oben, dann die Einstellungen (das Zahnradsymbol gleich unter [...]), "Account" und "Email Account Registration". Dort trägt man eine eigene Email-Adresse ein und vergibt ein Passwort dafür. Wichtig: Keinesfalls das Passwort des Email-Kontos angeben! Man erhält nun eine Email mit einem Verifikationscode, welchen man in der App eingeben muss.
Zuletzt muss man auf Privatsphäre verzichten und unter "Chats & Voice Calls" die Option "Letter Sealing" deaktivieren. Dies ist die Ende-zu-Ende-Verschlüsselungsoption von Line, die purple-line leider noch nicht unterstützt. Andererseits handelt es sich bei Line um eine rein proprietäre Anwendung, daher gilt eh jede dort implementierte Verschlüsselung bestenfalls als "Security By Obscurity" ohne nachweisbaren Wert!

Nun startet man Pidgin mit installiertem Line-Plugin. Unter Accounts -> Manage Account -> Add... muss folgendes eingetragen werden:
Protocol: Line
Username: Die mit dem Line-Konto verknüpfte Email-Adresse
Password: Das in der App gesetzte Passwort zu dieser Email-Adresse
[x] Remember password
Nach Klick auf Add wird das Konto hinzugefügt und verbunden. Beim ersten Verbindungsversuch poppt ein Fenster mit einem Verifikationscode auf, der innert drei Minuten in der App eingetragen werden muss. Es dauerte bei mir jedoch rund eine Minute, bis das entsprechende Popup auf dem Mobilgerät erschien.

Anschliessend ist Line auch vom Desktop-Computer aus chatbereit. Es gibt jedoch einige Einschränkungen des sich in in sehr langsamer Entwicklung befindlichen Plugins: neben der fehlenden E2E-Verschlüsselung ist ausschliesslich Text-Chat möglich, d.h. keine Audio- oder Videotelefonate. Für diese muss weiterhin auf die mobile App zurückgegriffen werden. Abbrüche der Internetverbindung werden nicht erkannt und man bleibt scheinbar verbunden. Als Presence-Status gibt es ausschliesslich die Wahl zwischen Online/Available oder Offline (kein Away). Bilder können nicht verschickt, sondern nur empfangen werden. Diese werden dann auch nur angezeigt, wenn sie einzeln empfangen werden. In Text eingearbeitete Icons werden nicht korrekt dargestellt.

Custom Debian Live USB-Stick

^ v M ><
Ausgehend von einem bestehenden Debian-Installer-Hybrid-Image habe ich ein Live-System für USB-Sticks gebaut, das an meine Bedürfnisse angepasst ist. Für Notfälle bietet sich deses System für die Hosentasche ebenso an, wie für spontane Installationen.

Benötigt wird zuerst ein passend vorkonfiguriertes, bestehendes Image. Das spart gegenüber einer frischen Zusammenstellung viel Zeit und Testaufwand. Das Vorgehen ist aber ansonsten weitgehend Identisch, weshalb ich dieser Anleitung folgen konnte. Sämtliche Schritte müssen mit root-Rechten durchgeführt werden. Als Basis habe ich das Debian 8.1 Installer-Image mit XFCE benutzt.

Einige nötige Pakete müssen auf dem Host-System installiert und die Arbeitsverzeichnisse erstellt werden:
aptitude install syslinux syslinux-utils squashfs-tools rsync xorriso isolinux
mkdir -p live_boot/chroot/
cd live_boot/
mkdir -p image/live

Danach wird das als Vorlage genutzte ISO gemountet und entpackt:
mkdir /mnt/iso /mnt/iso_root
mount debian-live-8.1.0-amd64-xfce-desktop.iso /mnt/iso -o loop
mount /mnt/iso/live/filesystem.squashfs /mnt/iso_root -o loop
rsync -av /mnt/iso_root/* chroot/
rsync -av /mnt/iso/* image/ --exclude=/mnt/iso/live

Nun gehen wir in's chroot:
mount -o bind /dev chroot/dev
cp /etc/resolv.conf chroot/etc/resolv.conf
chroot chroot

Das chroot muss nun noch mit ein paar Pseudodateisystemen und Einstellungen versorgt werden, bevor es vollständig operabel wird:
mount none -t proc /proc
mount none -t sysfs /sys
mount none -t devpts /dev/pts
export HOME=/root
export LC_ALL=C

Ab jetzt befindet man sich im chroot und kann die nötigen Modifikationen des künftigen Live-Systems vornehmen, z.B. die Konfiguration anpassen, beliebige weitere Pakete installieren oder das System aktualisieren. Dabei geht man genau gleich vor, wie bei einem installierten Arbeitssystem. Damit der USB-Stick z.B. alle WLAN-Karten unterstützt, können Firmware-Dateien (aus Debian non-free) nachinstalliert werden. Die Tastaturbelegung kann in /etc/default/keyboard an die eigene Tastatur angepasst werden, etc.

Ist man mit den Anpassungen fertig, wird das chroot wieder abgebaut und verlassen:
aptitude clean
rm -rf /tmp/*
echo > /etc/resolv.conf
umount -l /proc
exit
umount chroot/sys
umount chroot/dev/pts
umount chroot/dev
rm chroot/root/.bash_history

Nun wird das squashfs-Image mit dem root-Dateisystem erzeugt und der Kernel kopiert. Ein allfällig bestehendes squashfs-Image sollte aber davor gelöscht werden, da es sonst ergänzt statt überschrieben würde:
rm image/live/filesystem.squashfs
mksquashfs chroot image/live/filesystem.squashfs -e boot
cp chroot/boot/vmlinuz-3.16.0-4-amd64 image/live/vmlinuz
cp chroot/boot/initrd.img-3.16.0-4-amd64 image/live/initrd.img

Als vorletzter Schritt wird das ISO erzeugt. xorriso kann unter Verwendung von isohybrid, welches sich bei Debian im Paket syslinux-utils befindet, direkt ein bootfähiges Hybrid-ISO generieren. Gegenüber genisoimage hat xorriso mehrere Vorteile, einerseits wird das Hybrid-ISO in einem Schritt erstellt (statt es nachträglich per iso-hybrid Aufruf zu konvertieren), andererseits wird ein korrekter MBR auf den Stick geschrieben, so dass sich dieser nachträglich noch mit gparted umpartitionieren liesse. Der xorriso-Befehl wurde mit Tipps aus dem Ubuntu-Forum noch etwas optimiert:
cd image
xorriso -as mkisofs -D -r -J -joliet-long -l -V "Debian Live" -b isolinux/isolinux.bin -c isolinux/boot.cat -iso-level 3 -no-emul-boot -partition_offset 16 -boot-load-size 4 -boot-info-table -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -o ../debian-live.iso .
cd ..

Dieses Hybridimage ist nicht per UEFI startbar, daher müssen UEFI-Systeme für dieses Image weiterhin den Legacy-Bootmodus aktiviert haben.

Das Image wird abschliessend auf einen USB-Stick geschrieben und kann danach getestet werden:
dd if=debian-live.iso of=/dev/sdX

OpenVPN nach Ruhezustand neu verbinden

^ v M ><
Wird der Laptop in den Ruhezustand oder Schlafmodus versetzt, verbindet OpenVPN nach dem Aufwecken nicht mehr und muss jeweils manuell neu gestartet werden, um den Tunnel neu aufzubauen. Das lässt sich doch sicher automatisieren? Natürlich, schliesslich wird auf dem Notebook Linux genutzt.

Unter Debian mit dem traditionellen SysV-Init geht das folgendermassen: Im Verzeichnis /etc/pm/sleep.d/ wird eine neue Datei 99openvpn erstellt und Ausführungsrechte mittels chmod +x 99openvpn gesetzt. Der Dateiinhalt lautet:
#!/bin/bash
case "$1" in
resume|thaw)
/etc/init.d/openvpn restart
;;
esac

Unter Systemen mit systemd ist das natürlich alles wieder anders, weil sich dort systemd um den Ruhezustand kümmert. Entsprechend braucht man ein anderes Skript an anderem Ort. Diesmal kommt das Skript nach /lib/systemd/system-sleep/ (der Ort kann bei anderen Distributionen abweichend sein) und heisst z.B. openvpn.sh. Auch hier werden wieder Ausführungsrechte mittels chmod +x openvpn.sh gesetzt. Das Skript enthält folgenden Inhalt:
#!/bin/bash
case "$1" in
post)
/bin/systemctl restart openvpn
;;
esac

Das war's, nun klappt's auch wieder mit OpenVPN. (Lösungsweg per Zufall inspiriert via thinkwiki, für systemd angepasst dank fedoraforum)

Bildauswahl mit Geeqie

^ v M ><
Zum Betrachten von Bildern auf den Desktop-Rechnern nutze ich das Programm geeqie, welches schnell, flexibel und mal mehr, mal weniger leichtgewichtig ist. Um unkompliziert eine Auswahl an Bildern aus einer grösseren Kollektion vorzunehmen, habe ich ein kleines Skript geschrieben, und geeqie darum erweitert. Die Idee ist, dass auf Tastendruck das aktuelle Bild in ein festgelegtes Verzeichnis kopiert werden soll. Mit dieser Kopie kann dann später weitergearbeitet werden (schneiden, verkleinern, verschicken...).

Dazu geht man folgendermassen vor:
In /usr/local/bin legt man eine Skript namens "geeqie-select.sh" mit folgendem Inhalt an:
#!/bin/bash
myfile="$1"
selections="$HOME/misc/selections"

oldpath=$(dirname "$myfile")
subdir=$(basename "$oldpath")

if [ ! -d "$archive/$subdir" ]; then
mkdir -p "$selections/$subdir"
fi

cp "$myfile" "$selections/$subdir/"

Die Zeile "selections" legt fest, wohin die ausgewählten Bilder gespeichert werden. Nicht vergessen, das Skript ausführbar zu machen (chmod +x).

Nun startet man geeqie und wählt im Menü "Edit -> Preferences -> Configure Editors" und klickt dort auf den Knopf "New". Dort fügt man folgende .desktop-Definition ein (unten noch den Namen von new.desktop zu z.B. geeqie-select.desktop ändern...):
[Desktop Entry]
Version=1.0
Type=Application
Name=Geeqie Select
Exec=/usr/local/bin/geeqie-select.sh %f
Categories=X-Geeqie;
OnlyShowIn=X-Geeqie;
X-Geeqie-Menu-Path=FileMenu/FileOpsSection

Dies erzeugt einen neuen Eintrag "Geeqie Select", welcher im geeqie-Menü unter "File -> Geeqie Select" erreichbar ist.

Nun muss noch ein Tastenkürzel definiert werden. Dazu wählt man "Edit -> Preferences -> Preferences" und wechselt dort aufs "Keyboard"-Tab. Nun sucht man in der Liste den Punkt "Geeqie Select" und weist ein noch freies Tastenkürzel zu. Fertig.

Nun kann man das vorher festgelegte Tastenkürzel drücken, und es wird eine Kopie im festgelegten Zielverzeichnis erstellt.

Eine Unschönheit gibt es allerdings, wenn die angezeigten Bilder in einem schreibgeschützten Ordner liegen, meckert geeqie, dass das Zielverzeichnis schreibgeschützt sei. Das ist natürlich falsch, lässt sich aber leider nicht verhindern.

Debian Jessie: Umgebungsvariablen bei Login setzen

^ v M ><
Egal, was man in /etc/profile.d/mycustomfile.sh definiert... Debian mit XFCE und lightdm liest es nicht ein. Dies ist offiziell so gewollt. Da gilt: korrekt konfigurieren. Da niemand so wirklich weiss, wie's geht, gilt: ausprobieren bis es klappt.

Der korrekte Weg:
erstelle eine Datei mit den nötigen export-Statements im Verzeichnis /etc/profile.d/ - wichtig ist, dass die Datei auf .sh endet. Aus Sicherheitsgründen sollte sie root gehören und auch nur durch root beschreibbar sein (chown root:root /etc/profile.d/* und chmod o-w /etc/profile.d/*). Der Dateiinhalt schaut dann z.B. so aus (der Rest meines Systems ist amerikanisch kolonialisiert mit en_US.UTF-8):
export LC_PAPER=de_CH.UTF-8
export LC_MEASUREMENT=de_CH.UTF-8
export LC_TIME=de_CH.UTF-8
export LC_MONETARY=de_CH.UTF-8
export EDITOR=vi


Als nächstes muss /etc/profile durch $HOME/.profile eingelesen werden. Dazu fügt man in die Datei folgende Zeile ein:
. /etc/profile


Damit auch grafische Anwendungen die Umgebungsvariablen mitbekommen, muss $HOME/.profile nun durch $HOME/.xsessionrc eingelesen werden. Wenn die Datei nicht existiert, kann man sie einfach mit folgendem Inhalt erstellen:
. $HOME/.profile


Somit hat man eine konsistente Profilumgebung in allen Konsolen und in grafischen Anwendungen.

Vorsicht, ~ für $HOME und source für . sind reine Bash-Aliase und dürfen nicht verwendet werden! Das ist die grosse Stolperfalle, welche es zu umgehen gilt und die so ziemlich überall unerwähnt bleibt (im Debian-Bugreport wie auch in diesem ansonsten hilfreichen Beispiel werden diese Bashismen verwendet)

Wichtig ist natürlich, dass die locale-Definitionen existieren. Unter Umständen müssen diese erst über den Befehl dpkg-reconfigure locales aktiviert und generiert werden.

Infrarot - IrDA, lirc und Tauchcomputer - mit Linux

^ v M ><
Bis vor kurzem dachte ich, dass Infrarot an sich eine tote Datenübertragungstechnologie der Technikantike sei. Seit PDAs durch Smartphones ersetzt wurden und für die drahtlose Übertragung generell Bluetooth oder das omnipräsente WLAN genutzt wurden, welche den Vorteil haben, dass keine direkte, ungestörte Sichtverbindung bestehen muss, sind infrarotfähige Geräte eher selten geworden. Witzigerweise unterstützen die neusten Samsung-Telefone wieder Infrarot, mein altes S3 tut dies jedoch nicht.

Doch dann habe ich meinen ersten Tauchcomputer gekauft. Dieser war Teil eines preisgünstigen Komplettpakets inkl. Regulator. Wichtiges Kriterium war die Unterstützung durch Subsurface, damit ich die Tauchgänge auch mit meinen Linux-Computern auswerten kann. In der Tat steht das Gerät auf der Kompatibilitätsliste. Daher habe ich da auch gar nicht länger über das Übertragungsprotokoll informiert und sofort eingekauft.

Kaum angekommen wurde das Gerät ausgepackt und oh! Kein USB-Kabel mit dabei? mmmh, wie überträgt es dann? Oho, das Handbuch besagt Infrarot!? Was nun?

Nach kurzer Suche habe ich in meinem Hardware-Fundus ein altes IrDA-USB-Dongle wiedergefunden. Dies lag 10 Jahre lang unbenutzt umher, da es nicht durch lirc, die Linux-Software für Infrarot-Fernsteuerungen unterstützt wird. Dieses also auf Verdacht in den PC eingesteckt, den Tauchcomputer mit der Infrarot-Schnittstelle in Sichtweite hingelegt, Subsurface gestartet und den korrekten Tauchcomputer eingestellt. Sehr positiv: Subsurface stellt automatisch die korrekte serielle Schnittstelle (/dev/ttyS3) ein. Dann noch in Subsurface auf den "Importieren"-Knopf gedrückt und... der Tauchcomputer piept und Subsurface zeigt einen Fortschrittsbalken an. DAS ist doch mal ein positives Zeichen.

Wenn der Import nicht funktioniert, müssen folgende zwei Dinge geprüft werden: Erstens muss der Benutzer Mitglied in der Gruppe "dialout" sein. Zweitens muss unter Debian das Paket irda-utils installiert sein.

Doch wieso funktioniert mein IrDA-Adapter nicht mit lirc? Nun, für Fernbedienungen muss ein weiteres Protokoll, CIR, unterstützt werden. Mein Adapter vom Typ mcs7780 beherrscht aber wie fast alle USB-Adapter nur SIR, MIR und FIR und kann im Gegensatz zu seriellen Adaptern auch nur schwerlich manipuliert werden.

Welcher Adapter sollte nun gekauft werden? Das hängt natürlich primär vom Tauchcomputer ab, und welche Transfermodi dieser unterstützt. Leider schweigt sich der Hersteller in meinem Fall diskret aus (Nachtrag: Im Computer selbst kann der Tranfermodus zwischen Lo und Hi umgestellt werden - somit dürften SIR und FIR unterstützt sein). Generell scheinen die Adapter im Handel selten geworden zu sein und die Modellvielfalt ist eher gering. Gut verfügbar sind die Modelle von Polar für deren Uhren. Diese sind aber meiner Meinung nach unverhältnismässig teuer und unterstützen u.U. nur SIR. Generell sollte man daher immer zu einem Modell greifen, das alle drei gängigen Modi unterstützt.
Welche Modelle von Linux unterstützt werden, ist ebenfalls eher schwierig in Erfahrung zu bringen. Die verfügbaren Dokumentationen sind uralt und stammen teilweise aus Zeiten von Kernel 2.4. Und natürlich halten die Hersteller der Dongles in ihren Werbebroschüren oft geheim, welche Chips sie verbauen.

Fazit (tl;dr): Aus meiner Erfahrung ist klar, dass der Moschip msc7780 von Linux bestens unterstützt wird und für Datenübertragungen mit den meisten Infrarot-Endgeräten funktionieren sollte.

Galaxy S3 mit CyanogenMod

^ v M ><
Kitkat auf S3
Nachdem mein tragbarer Computer mit eingeschränkter Telefoniefähigkeit und Staatsüberwachung immer langsamer geworden ist, habe ich vor ein paar Monaten endlich einen kompletten Reset durchgeführt und die originale Bloatware durch das relativ schlanke CyanogenMod (inkl Google Apps Paket) ersetzt. Das hat sich absolut gelohnt, das Gerät flitzt regelrecht und konnte dadurch seine Lebens- bzw Gebrauchsspanne nochmals deutlich verlängern.

In Benutzung ist hier ein Samsung Galaxy S3 i9300. Die Installation verlief problemlos und strikte gemäss Anleitung von einer Debian 7 (amd64) Maschine aus.

Vorteile:
  • Sehr flotte Bedienoberfläche
  • Brandaktuelles Android 4.4 Kitkat, welches ja gemäss Samsung nicht auf dem Gerät laufen sollte.
  • Monatliche (Sicherheits)Updates
  • Viel weniger installierter, unnützer Bloatmüll. Lediglich von Google ist noch Bloat drauf. Google Maps ist leider derzeit noch eine ziemliche Killerapp, ansonsten wäre ein komplett freies System mit z.B. f-droid als Appstore sicher denkbar. Mal auf Nokias Here-Maps warten :-)
  • Reduzierter Speicherverbrauch (was wohl auch zur höheren Geschwindigkeit beiträgt)
  • Im Allgemeinen eine längere Akkulaufzeit - die Laufzeit scheint mir aber etwas stärker zu schwanken als mit der Originalfirmware. Das ist aber eine subjektive Empfindung ohne wissenschaftliche Prüfung
  • Tiefere Latenz und Jitter im WLAN
  • Unterstützung für Linux-Dateisysteme wie ext4. Sehr schön bei USB-Datenträgern und grossen SD-Karten
Eins muss man Samsung allerdings lassen, grad die Samsung eigenen Apps sowie viele Touchwhiz-Funktionen waren ausgesprochen durchdacht, hilfreich und ergonomisch, so dass der Ersatz doch etwas Zeit und den Test diverser Apps benötigt hat:
  • Bildbetrachter: QuickPic - das hatte ich schon mit der Originalfirmware im Einsatz
  • Kamera: Focal Beta - leider friert die Kamera gelegentlich ein oder die App tut zwar so, als ob sie Bilder machen würde, tut dies aber nicht. In jedem Fall hilft nur ein kompletter Neustart des Geräts. Ob das an Focal oder CyanogenMod liegt, habe ich bislang nicht herausgefunden. Die aktuelle Version der CM-Standard-Fotografie-App macht unterdessen einen deutlich besseren Eindruck als vor ein paar Monaten, so dass ich hier womöglich wechseln werde.
  • Bildschirm aktiv halten, wenn in Benutzung: Smart Stay + Die App erfüllt an sich den Zweck, wofür sie installiert wurde, verursacht aber einen gewaltigen und nicht dokumentierten Datenverkehr. Meine "Zweckselfies" möchte ich allerdings nicht in den Händen der NSA oder des Entwicklers wissen, weshalb die App mittels Firewall ruhiggestellt werden sollte.
  • Anrufe Ruhigstellen durch Umdrehen: Flip - Silent
  • Spezielle SMS-Klingeltöne für einzelne Kontakte: Ringo
  • Ersatz für das SPlanner Kalenderwidget: SolCalendar
Natürlich ist auch mit CyanogenMod nicht alles Milch und Honig, in Sachen Hardwareunterstützung funktioniert z.B. die Bildausgabe auf externe Monitore per HDMI-Adapter nicht mehr. Das ist allerdings ein Feature, das ich eh kaum je gebraucht habe, somit kann ich damit leben. Etwas unzufrieden bin ich auch mit der SMS-App, welche leider nicht anzeigt, wie viele Zeichen schon getippt wurden. Auch schön wäre es, wenn die SMS-App gleich die Funktionalität von Ringo integrieren würde. Ärgerlich: Der Empfang von MMS scheint nicht zu funktionieren.

PCEngines APU TinyCore BIOS Update

^ v M ><
Erst den USB-Stick präparieren:
dd if=/dev/zero of=/dev/sdb bs=512 count=1
mkfs.vfat -F32 -I /dev/sdb
syslinux /dev/sdb
mount /dev/sdb /mnt/temp
cd /mnt/temp
tar -jxf /tmp/apu_tinycore.tar.bz2


Danach das APU vom USB-Stick booten und das BIOS updaten:
cd /mnt/sda
flashrom -w apu140405.rom
poweroff

Network Bonding, Bridges und virtuelle Maschinen

^ v M ><
Bonding ist super: mehrere Netzwerkkarten können zu einer zusammengefasst werden, um Geschwindigkeit oder Ausfallsicherheit zu erhöhen. In meinem Fall wollte ich einfach etwas mehr Speed für virtuelle Maschinen.

An sich ist die Konfiguration super simpel und gemäss Debian Wiki vorzunehmen. Das funktioniert mit dem Bonding-Mode balance-rr u.U., aber nicht mit virtuellen Maschinen, wenn diese mit dem Bonding-Interface an eine Bridge gehängt werden. Das resultierte in meinem Fall in:
br1: received packet on bond0 with own address as source address


Die Empfehlung lautet, stattdessen den Modus 802.3ad zu verwenden, sofern vom Switch unterstützt. Bei meinem Procurve 1810G muss dazu unter Trunks -> Trunk Configuration ein Trunk mit Mode "LACP Active" erstellt werden. Diesem werden alle Switchports zugewiesen, woran die im Bond verwendeten Netzwerkkarten hängen.

Damit nun das Bonding-Interface mit 802.3ad auch richtig initalisiert wird, fehlt dem System u.U. noch das Paket "ethtool", welches ebenfalls installiert werden muss:
aptitude install ethtool


Eine Kontrolle von /proc/net/bonding/bond0 zeigt, dass das Bonding-Interface jetzt korrekt hochfährt und die Slave-Interfaces einbinden kann (MII Status: up)