(198 MB) 00:35:49
2014-04-27 10:00 🛈Die Multimeter-Serie „MM635“ von Rohde & Schwarz (aka. Keithley 168) stammt aus den 70ern. Ein „Kellerfund“ hat für unter 10€ seinen Weg auf meine Werkbank gefunden, denn Multimeter hat man nie genug und kaputt gibt es nicht.
Radiomuseum
Anleitung incl. Schaltplan (Anmeldung erforderlich)
„Mal schnell“ ein paar Daten im PHP-Code lesbar ausgeben funktioniert üblicherweise sehr zuverlässig mit var_dump(). Auf einem System zeigte sich das Phänomen, dass lange Strings oder verschachtelte Arrays nicht vollständig angezeigt wurden. Ursache ist die Standardkonfiguration vieler Distros der PHP-Extension xdebug. In der entsprechenden ini-Datei lässt sich das Kürzen mit folgenden Zeilen unterbinden:
xdebug.var_display_max_data=-1
xdebug.var_display_max_children=-1
xdebug.var_display_max_depth=-1
(3 MB) 00:03:04
2014-04-24 10:00 🛈Android-Handy zur Hand? Keine App da, die dein Problem vernünftig löst? Warum nicht selber etwas basteln? Mit den kostenlosen „Android Developer Tools“ lassen sich relativ einfach eigene Apps entwickeln. In dieser Folge wird erklärt wo man die nötige Software findet und wie man sie unter Linux installiert.
Anm: Unter Windows ist das Vorgehen nahezu identisch.
(52 MB) 00:07:27
2014-04-22 10:00 🛈Batterietausch einer Casio WaveCeptor WV-58
Mit tcpdump kann man sehr einfach auf der Konsole Netzwerkverbindungen mitlesen und so Fehler genauer betrachten. Üblicherweise lässt sich mit der Option „-w datei.pcap“ dieser Mitschnitt auch als pcap-Datei speichern, welche beispielsweise mit Wireshark geöffnet und weiter analysiert werden kann.
Unter Gentoo zeigten sich heute 2 seltsame Verhaltensmuster:
Mit absoluten oder relativen Pfaden:
tcpdump -i br0 -w /tmp/test.pcap
tcpdump: /tmp/test.pcap: No such file or directory
Ohne Pfad erscheint keine Fehlermeldung, die Datei wird aber augenscheinlich auch nicht erstellt:
host tmp # tcpdump -i br106 -w test.pcap
tcpdump: WARNING: br106: no IPv4 address assigned
tcpdump: listening on br106, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel
host tmp # ls -l test.pcap
ls: cannot access test.pcap: No such file or directory
host tmp #
Auslöser ist das USE-Flag „chroot“ – hierdurch wird der Prozess in ein virtuelles Root gesperrt, sodass Fehler (hoffentlich) nicht zu viel Schaden anrichten können. Alle Pfade beziehen sich auf /var/lib/tcpdump/ – entsprechend sind dort auch die ohne Pfadangabe generierten pcap-Dateien zu finden.
(99 MB) 00:13:52
2014-04-20 10:00 🛈Video von Dave Jones (eevblog)
Meldung über vertauschte Stromkabel
Alternative Firmware
Da Eclipse/Java auf all meinen Produktivsystemen – mal wieder – nur am abstürzen ist sollte es „mal schnell“ eine VM richten. Leider gab es bei der Installation der Android Developer Tools den o.g. Fehler. Etwas seltsam, denn die Datei ist vorhanden und lässt sich auch mit less & co lesen. Auch ldd ist keine große Hilfe – statisch gelinkt.
Lösung ist aber in der selben Richtung: Tatsächlich müssen die 32-Bit-Libraries installiert sein. Für Debian/Ubuntu/Mint hilft ein
sudo apt-get install ia32-libs
Nach einem Absturz konnte Eclipse nicht mehr auf den zuletzt geöffneten Workspace zugreifen. Um den Workspace wieder freizugeben muss im zugehörigen Verzeichnis die Datei .metadata/.lock gelöscht werden. Natürlich sollte man vorher mit ps o.Ä. sicherstellen, dass tatsächlich kein Eclipse mehr läuft, andernfalls könnten simultane Zugriffe zu Datenverlust führen.
„Mal schnell“ eine GUI über SSH aufrufen – normal kein Problem: Wenn auf dem Server X11Forwarding in der Datei /etc/ssh/sshd_config auf yes steht lässt sich mit ssh -vCXY user@host eine Verbindung starten, welche GUI-Aufrufe auf dem lokalen Rechner darstellt.
Heute leider nicht: GUI-Aufrufe verabschiedeten sich mit folgender Meldung:
X11 connection rejected because of wrong authentication.
An der SSH-Verbindung konnte man nichts sehen, diese Endete mit
debug1: Requesting X11 forwarding with authentication spoofing.
, also ohne Fehler.
Das Problem ist mal wieder aus der Kategorie „so einfach, dass man es übersieht“: Die Platte war voll…
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 29G 28G 0 100% /
Nachdem wieder etwas Platz verfügbar war ging auch x11 per SSH wieder fehlerfrei.
Nur „mal kurz“ updaten – „pacman -Syu“, paar mal Enter und schon ist das notwenige Übel von der Todo-Liste verschwunden. Nunja, üblicherweise. Auf einem System trat heute nach dem Download folgender Fehler auf:
Fehler: key "B02854ED753E0F1F" could not be looked up remotely
Fehler: Erforderlicher Schlüssel fehlt im Schlüsselbund
Fehler: Konnte den Vorgang nicht durchführen (Unerwarteter Fehler)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
Ursache ist ja schon recht gut beschrieben: Ein Paket ist offenbar mit einem Key signiert, den das System noch nicht kennt. Üblicherweise versucht pacman dann diesen von den Arch-Servern(?) nachzuladen. In meinem Fall erfolglos – der Rechner hat keinen direkten Internetzugang und kommt nur per HTTP-Proxy nach draußen.
Um den Fehler zu beheben sollte man vor dem Systemupdate das Paket archlinux-keyring neu installieren. Dieses bringt alle aktuellen Schlüssel mit und aktualisiert die lokale Datenbank, danach sollten auch die restlichen Aktualisierungen problemlos laufen.