Analog zu den letzten Jahren war ich auch dieses mal mit meiner Kamera in Miesenheim unterwegs. Leider diesmal etwas kürzer, da die Vorbereitungszeit etwas knapp war und viele Gruppen Musikanlagen zur Beschallung verwendeten, deren Inhalt ich aus urheberrechtlichen Gründen hier vermeiden muss. Wer dennoch einen Blick auf den Umzug werfen möchte wird wie immer auf YouTube fündig:
https://www.youtube.com/watch?v=8Vnnm1kjEOY
(97.2 MB) 00:46:51
2017-02-26 11:00 🛈Feinstaub ist in letzter Zeit immer wieder in den Nachrichten zu hören – kleine Staubpartikel, welche bis in die Lunge vordringen und gesundheitliche Risiken bergen können. Mit dem SDS011 ist ein erschwinglicher Sensor verfügbar, mit welchem man schnell und einfach eine lokale Messstation aufbauen kann.
In diesem Video gehen wir vom ersten Blick bis zum Auslesen alle Schritte durch, welche ich nach Erhalt des Sensors durchführte. Wer einfach nur Messwerte lesen möchte kann natürlich auch einfach die fertige Firmware von Luftdaten.info verwenden. Ich erarbeite Sensordaten und Protokoll, schreibe eine Testsoftwate am Rechner und portiere sie zusammen mit einer Cloud-Anbindung auf den ESP8266.
00:00 Der Sensor
03:33 Technische Daten
09:56 Das Protokoll
17:15 Sensorwerte am PC interpretieren
23:05 Datensammlung in der Cloud: Thingspeak
26:09 Sensorwerte mit Arduino/ESP8266
42:12 ESP8266-Hardware
43:00 Vergleich mit staatlicher Messstation
45:40 Fazit & Ausblick
00:26 http://www.codefor.de/stuttgart
00:34 http://www.stuttgart.de/feinstaubalarm
01:50 http://en.wikipedia.org/wiki/File:Particlecounter.jpg
03:33 http://www.luftdaten.info
04:45 http://inovafitness.com/software/SDS011%20laser%20PM2.5%20sensor%20specification-V1.3.pdf
09:58 http://cl.ly/ekot
23:05 http://www.thingspeak.com
26:18 https://github.com/nothans/ESP8266/blob/master/examples/RSSI_to_ThingSpeak.ino
PHP-Testcode:
https://gist.github.com/adlerweb/5ea58beb8a6bee3422932983c5c8ae92
Arduino-Testcode:
https://gist.github.com/adlerweb/ce23c61179bec3433279da6c2e7ff969
(160.2 MB) 00:25:56
2017-02-22 15:56 🛈Da die Konstruktion aus vergangenen Zeiten nur bedingt hält zeige ich mal wieder wie schlecht meine Hermwerkerkünste sind und improvisiere aus den Resten ein Regal für den Basteltisch
(91.4 MB) 00:23:29
2017-02-19 11:00 🛈Der Onion Omega 2 ist ein kleines und günstiges Bastelboard, welches sich zwischen kleinen Mikrocontrollern wie Arduino/ESP8266 und den großen Mini-Computern wie dem Raspberry Pi platziert. Mit 580MHz, 64MB RAM und integriertem WLAN wird er für „Internet of Things“-Anwendungen angepriesen.
In diesem Video werden wir einen Blick auf die technischen Daten werfen, uns die Einrichtung anschauen und letztendlich mittels OctoPrint dem 3D-Drucker der letzten Folge ein Webinterface verpassen.
Inhalt
Links
Diese Meldung weist erst mal darauf hin, dass die Installation beschädigt ist. Dies kommt häufig vor, wenn der Updater unterbrochen wird oder ein übereifriger Virenscanner genutzt wird. Eine Reparaturinstallation ist meist keine schlechte Idee – hierzu einfach die aktuelle Installation von der Webseite ohne vorherige Deinstallation ausführen. E-Mails und Einstellungen bleiben hierbei zu großen Teilen erhalten. Zeigt dies keine Wirkung kann auch ein Blick auf die Dateirechte nicht schaden – in meinem Fall war für den Ordner bzw. dessen Dateien das Execute-Recht verweigert.
(305.3 MB) 00:50:02
2017-02-12 11:00 🛈Der 101hero wird vom Macher als günstigster jemals verkaufter 3D-Drucker angepriesen. Im Rahmen des Crowdfundings waren die Geräte teils für 49$ zu bekommen. Für einen 3D-Drucker eine Kampfansage, denn die meisten Bausätze fangen erst bei über 200€ an. Natürlich kommt der Preis mit Abstrichen: Die bebaubare Fläche ist mit 15x15x10cm recht klein, die mit Getriebe ausgestatteten Schrittmotoren haben deutlich weniger Geschwindigkeit und Präzision als die üblicherweise verwendeten NEMAs und auch der Plastikaufbau verspricht nicht gerade eine hohe Stabilität.
Während man den Liefertermin Oktober Crowdfunding-Typisch nicht halten konnte gehen die Geräte langsam in den Versand und einer der Kartons ist auch bei mir eingetroffen. Schauen wir mal, ob man für den Preis tatsächlich irgendeine Funktion erhält.
Business as usual: Pünktlich zum Jahresanfang wird man von sämtlichen Vertragspartnern mit totem Baum zugeworfen. Glücklicherweise habe ich passende Scanner, die das Material in etwas besser verwaltbare Formen überführen können. Zuletzt verwendete ich dazu einen Panasonic/Matsushita KVS-5026, welchen ich aus dem Schrott retten konnte. Zwar habe ich noch einige schnellere Modelle, dieser hatte jedoch bisher die wenigsten Probleme mit Double-Feeding und ist durch die Bauform bei mir einfacher zu nutzen.
Leider war der Start dieses Jahr nicht ganz so erfolgreich – der Scanner wird korrekt erkannt, versuchte ich jedoch einen Scan zu starten gab es den allseits beliebten „Segmentation fault“. Boo.
Der Trick des letzten Problems half dieses mal leider nicht – auch die aktuelle GIT-Version zeigen den selben Fehler. Da es für das passende Backend kvs20xx keinen Maintainer gibt ist wohl auch keine Besserung zu erwarten.
OK, ich bin kein C-Programmierer, habe keine Ahnung von Debuggern unter X86 und produziere auch sonst eher nicht qualitätsorientieren Code – was kann schon schief gehen.
Ein paar Debug-Textausgaben später konnte ich den Fehler auf die Funktion sane_open, genauer die erste „echte“ Codezeile dort „for (i = 0; devlist[i]; i++)“ eingrenzen. Offenbar wurde früher durch sane automatisch ein Scan iniziiert und die devlist daher gefüllt. In der aktuellen Version scheint es beim Aufruf leer zu sein und mit NULL hantieren mag C wohl nicht. Als workaround konnte ich ein paar Zeilen des Fujitsu-Treibers ruberkopieren, welche die Inizialisierung ggf. nachholen. Auch diese musste etwas angepasst werden um mit dem direkten Aufruf umgehen zu können. Immerhin: Der Scanner läuft und ich kann weitermachen. Fein.
diff --git a/backend/kvs20xx.c b/backend/kvs20xx.c
index 955252a3..56095cb5 100644
--- a/backend/kvs20xx.c
+++ b/backend/kvs20xx.c
@@ -1,6 +1,8 @@
/*
Copyright (C) 2008, Panasonic Russia Ltd.
Copyright (C) 2010, m. allan noah
+
+ Attn: Local workaround 2017-02-11 Florian Knodt, sane-kvs@adlerweb.info
*/
/*
Panasonic KV-S20xx USB-SCSI scanners.
@@ -141,6 +143,8 @@ sane_get_devices (const SANE_Device *** device_list,
devlist = NULL;
}
+ sanei_usb_init();
+
for (curr_scan_dev = 0;
curr_scan_dev < sizeof (known_devices) / sizeof (known_devices[0]);
curr_scan_dev++)
@@ -156,7 +160,10 @@ sane_get_devices (const SANE_Device *** device_list,
known_devices[curr_scan_dev].scanner.model,
NULL, -1, -1, -1, -1, attach);
}
- *device_list = (const SANE_Device **) devlist;
+
+ if(device_list && devlist){
+ *device_list = (const SANE_Device **) devlist;
+ }
return SANE_STATUS_GOOD;
}
@@ -168,10 +175,22 @@ sane_open (SANE_String_Const devname, SANE_Handle * handle)
struct scanner *s;
SANE_Int h, bus;
SANE_Status st;
+
+ if (devlist) {
+ DBG (DBG_INFO, "Using prepopulated device list\n");
+ }else{
+ DBG (DBG_INFO, "Device list empty - scanning...\n");
+ st = sane_get_devices(NULL,0);
+ if(st != SANE_STATUS_GOOD){
+ DBG (DBG_WARN, "Scan failed\n");
+ return st;
+ }
+ }
+
for (i = 0; devlist[i]; i++)
{
if (!strcmp (devlist[i]->name, devname))
- break;
+ break;
}
if (!devlist[i])
return SANE_STATUS_INVAL;
Debian mag stabil sein, der aktuell bei Jessie mitgelieferte 3.16er Kernel wird von einigen Dingen jedoch nicht mehr unterstützt, die Installation dieser Softwarepakete ist also nicht mehr möglich. Glücklicherweise gibt es die so genannten Backports, welche neuere Versionen bereitstellen. Nicht ganz so gut getestet, aber immerhin eine Möglichkeit.
Die Einrichtung geht recht schnell – man muss lediglich folgende Zeile in /etc/apt/sources.list hinzufügen:
deb http://ftp.debian.org/debian jessie-backports main
Sucht man nun nach linux-image, also dem Kernel, findet man auch einige neue Versionen. In meinem Fall ist die 4.9.0 aktuell:
# apt-cache search linux-image ... linux-image-4.9.0-0.bpo.1-amd64 ...
Leider gelingt die Installation nicht ohne Klimmzüge, denn der erste Versuch wird mit einer Fehlermeldung quittiert:
# apt-get install linux-image-4.9.0-0.bpo.1-amd64 linux-headers-4.9.0-0.bpo.1-amd64 Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass Sie eine unmögliche Situation angefordert haben oder, wenn Sie die Unstable-Distribution verwenden, dass einige erforderliche Pakete noch nicht erstellt wurden oder Incoming noch nicht verlassen haben. Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: Die folgenden Pakete haben unerfüllte Abhängigkeiten: linux-image-4.9.0-0.bpo.1-amd64 : Hängt ab von: linux-base (>= 4.3~) aber 3.5 soll installiert werden Empfiehlt: firmware-linux-free soll aber nicht installiert werden Empfiehlt: irqbalance soll aber nicht installiert werden E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
Auf den ersten Blick scheint es jedoch keine neue Verison des Paketes zu geben:
linux-base is already the newest version.
Ursache ist die Priorisierung: Sowohl im „offiziellen“ Jessie-Repository als auch in den Backports steckt ein Paket mit dem Namen linux-base. Zwar ist jenes in den Backports aktueller, jedoch werden die Pakete des Stable-Repos bevorzugt. Abhilfe schafft es das Paket explizit aus dem Backports-Repo zu beziehen.
apt-get -t jessie-backports install linux-base
Im Anschluss ist auch die Installation des Kernels fehlerfrei möglich. Mit dieser Methode kann man auch das Kernel-Metapaket installieren um zukünftige Updates automatisch zu erhalten:
apt-get -t jessie-backports install linux-image-amd64
Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung „too many errors“ als FAULTED markiert wurden.
zpool import
pool: tempstore
id: xyz
state: UNAVAIL
status: One or more devices are faulted.
action: The pool cannot be imported due to damaged devices or data.
config:
tempstore UNAVAIL insufficient replicas
sdd FAULTED too many errors
sde FAULTED too many errors
pool: storage
id: xyy
state: UNAVAIL
status: One or more devices are faulted.
action: The pool cannot be imported due to damaged devices or data.
config:
storage UNAVAIL insufficient replicas
sdb FAULTED too many errors
Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:
[ 776.890127] Large kmem_alloc(131128, 0x1000), please file an issue at:
https://github.com/zfsonlinux/zfs/issues/new
[ 776.890129] CPU: 1 PID: 12969 Comm: vdev_open Tainted: P O 4.4.39-gentoo-adlerweb #2
[ 776.890130] Hardware name: LENOVO yxz/ , BIOS xyz 01/10/2012
[ 776.890132] 0000000000000000 ffff880417a37bc0 ffffffff813545d8 000000000240c200
[ 776.890134] 0000000000000000 ffff880417a37c00 ffffffffa0018af1 0000000017a37be0
[ 776.890138] 0000000000000000 ffff88041626d480 ffff8804174ed660 0000000000004000
[ 776.890139] Call Trace:
[ 776.890144] [<ffffffff813545d8>] dump_stack+0x4d/0x65
[ 776.890148] [<ffffffffa0018af1>] spl_kmem_zalloc+0x131/0x180 [spl]
[ 776.890163] [<ffffffffa0109aa8>] vdev_cache_stat_fini+0x258/0xcc0 [zfs]
[ 776.890175] [<ffffffffa010a3ba>] vdev_cache_stat_fini+0xb6a/0xcc0 [zfs]
[ 776.890188] [<ffffffffa014426a>] zio_data_buf_free+0x51a/0xdc0 [zfs]
[ 776.890200] [<ffffffffa014798f>] zio_nowait+0xaf/0x190 [zfs]
[ 776.890215] [<ffffffffa0104cce>] vdev_probe+0xfe/0x200 [zfs]
[ 776.890228] [<ffffffffa01059e0>] ? vdev_accessible+0x70/0x2b0 [zfs]
[ 776.890240] [<ffffffffa0107969>] vdev_open+0x3c9/0x4b0 [zfs]
[ 776.890251] [<ffffffffa0107bdd>] vdev_open_children+0x18d/0x1c0 [zfs]
[ 776.890254] [<ffffffffa001b8ec>] taskq_dispatch+0x3ac/0x5b0 [spl]
[ 776.890257] [<ffffffff810c1ed0>] ? wake_up_q+0x70/0x70
[ 776.890261] [<ffffffffa001b6e0>] ? taskq_dispatch+0x1a0/0x5b0 [spl]
[ 776.890263] [<ffffffff810b8c04>] kthread+0xc4/0xe0
[ 776.890265] [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
[ 776.890268] [<ffffffff81a6a5df>] ret_from_fork+0x3f/0x70
[ 776.890270] [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.
Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall
emerge -va spl zfs-kmod
Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:
emerge -va @module-rebuild
Storage online, Admins glücklich, Update-Doku ergänzt. Passt.
Beim Upgrade einer vCSA 6.0 zu 6.5 ergeben sich die tollsten Fehlermeldungen – und keine ist dokumentiert. Immerhin eine konnte ich Dank des VMWare-Forums schnell herausfinden:
"A problem occurred while getting data from the source vCenter Server."
Selbstverständlich waren die Zugangsdaten des Quellserver korrekt und funktionierten in WebUI bzw. SSH fehlerfrei. Ich übersetze mal in eine für Administratoren verständliche Sprache:
"Kennwort abgelaufen"
Nachdem ein neues Kennwort vergeben wurde läuft das Update an dieser Stelle weiter.