Schlagwort-Archive: Bug

Linux/Sane: Segfault mit Panasonic/Matsushita KVS-50xx-Scanner

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.

 

Upstream: #315625

Arch Linux / Arduino: libtinfo.so.5 fehlt

Bei der Nutzung der Arduino-IDE kommt es zur Zeit unter Arch Linux zu Problemen in Zusammenhang mit AVR-Boards. Ursache ist, dass Arduino seit einigen Versionen nicht mehr die Tools des System nutzt, sondern auf vorkompilierte Binärdateien setzt. Diese Alles-dabei-Conteiner versprechen auf den ersten Blick eine Vereinfachung, fliegt aktuell leider etwas auseinander: Die beigelegten Programme sind an vielen Stellen gegen überholte Bibliotheken gebaut. Dies verschafft zwar Kompatibilität mit trägen Systemen wie z.B. Debian, macht eine Nutzung mit aktuellen Systemen umständlich.

Schaut man sich die Fehlermeldung genauer an findet man schnell heraus, dass der beigelegte avrdude die Probleme auslöst:

Libtinfo wurde zwischenzeitlich wohl in Ncurses übernommen, zudem benötigt Arduino/avrdude eine ältere, normalerweise nicht mehr installierte API der ncurses-Library.

Wer die Libraries passend haben möchte muss zuerst ncurses5-compat-libs installieren um die alten API-Versionen nachzurüsten, im Anschluss sorgt das Dummy-Paket libtinfo dafür die alten Dateinamen auf ncurses umzubiegen.

Amdroid/CM: Eingehende SMS werden nicht angezeigt

Die Älteren unter euch können sich eventuell erinnern: SMS. Ein System um Textnachrichten an Mobiltelefone zu senden. Begrenzte Textlänge, hohe Gebühren und nicht verschlüsselt. Eigentlich heute Obsolet, aber einige Anbieter denken immer noch, dass dieses Verfahren modern sei – auch wenn es seit fast 7 Jahren als unsicher eingestuft wird. Hallo Banken. Es kam wie es kommen musste: Ich sah mich genötigt ein Produkt über eine dieser Gesellschaften zu bezahlen und – nichts. Während die Webseite freudig vermeldete, dass ich eine passende TAN erhalten hätte machte mein Handy keinen Mucks. Toll, ich hab ein Zahlungsziel. Aber auch nichts ungewöhnliches – im Telefonica-Netz kommt es ja nicht unbedingt selten zu Störungen, also warten wir halt.

Einige Stunden später noch immer nichts, also müssen wir wohl selbst Hand anlegen. Erste Anlaufstelle: Test-SMS senden. Gar nicht so einfach, denn SMS-Funktion hab ich eigentlich auf keinem anderen Gerät mehr installiert. Glücklicherweise habe ich noch einen „echten“ Telefonanschluss ohne VoIP und konnte daher per Modem ein SMS-Gateway erreichen. Allerdings ohne Erfolg. Also machen wir mal ein altes Handy fit und versuchen es da – woho, SMS. Es muss also an meinem Endgerät liegen.

Per ADB zeigt sich nach einigem (teuren) Geteste folgender Fehler:

Das kommt mir doch irgendwie bekannt vor… Schade, dass der Fehler nicht in der GUI erscheint und man so vermutet, dass alles ohne Störung funktionieren würde. Also löschen wir auch hier die kaputte Datenbank. Leider nicht ganz so einfach, denn zu dieser Meldung schweigen sich die Suchmaschinen aus und auch im Log wird der Dateiname der betroffenen Datenbank leider nicht erwähnt. Abhilfe schafft „Self Rubber Ducking“ , welcher augenscheinlich sehr von Migrationscode angetan ist. Fündig wurde ich dann im Ordner, welcher sich auch schon bei der Telefonie als Verursacher zeigte – hätte man drauf kommen können. Meh.

Also – leicht angepasst:

Nach einem Reboot kann dann auch der Fintechler wieder mit mir kommunizieren. Ich wäre ja dafür langsam mal offene Standards für sowas zu schaffen – sowas wie U2F mit angezeigten Transaktionsdaten…

Amdroid/CM: com.android.phone force-close nach Update

Ja, schmutzig ist praktisch – zumindest wenn es um Updates geht. Obwohl die meisten Entwickler empfehlen möglichst bei jedem Update mit einem frischen System zu beginnen versuche ich meine Daten so lange wie möglich mitzuschleifen („Dirty Flash“) – leider gibt es noch immer unzählige Apps, welche keine brauchbare Backup-Funktion bieten und auch systembasierte Lösungen wie Titanium Backup sind leider nicht unfehlbar.

Zuletzt war ich etwas nachlässig – mein Handy war noch auf Version 2, aktuell Version 9 meiner aktuellen ROM. Zeit zum Aktalisieren, vor allem da Dirty Cow gerade bekannt wurde.

Also, Sideload drüber und – narf. „Telefon reagiert nicht mehr“. Gemeint ist hierbei die Telefon-App, also jene, welche Sprachtelefonie ermöglicht. Brauch ich zwar normal nicht, aber die Popups nerven doch etwas.

Über ADB ließ sich folgendes im Log erspähen:

Dankenswerterweise gibt es einen passenden Post von Daan, welcher die Ursache genau beschreibt und einen passenden Befehl zum zurücksetzen der defekten Datenbank anbietet. Hierbei gehen ggf. Einstellungen verloren, diese muss man ggf. später von seiner Datensicherung wieder einspielen.

Nach dem Befehl war dann Ruhe und sogar das telefonieren funktioniert wieder. Fein.

policyd-weight: warning: child: err: Undefined subroutine &main::dn_expand called

Örks – nach dem letzten Neustart hatte einer meiner Mailserver etwas Schluckauf an den Tag gelegt: Mails wurden nicht mehr angenommen, im Log zeigte sich policyd-weight als Verursacher:

Ursache ist offenbar ein veralteter Aufruf der Library Net::DNS dieses Perl-Monsters. Ein passender Patch ist bei Debian zu finden, mit 3 geänderten Zeilen ist der Fehler erledigt und die Software wieder lauffähig.

 

wget 1.14 & Perl 5.18.x: Expected text after =item, not a number

Beim Kompilieren eines OpenWRT machte eben wget-ssl dicke Backen: „Expected text after =item, not a number“ im Dokumentationsordner ließ die letzte Meldung verlauten. Grund sind striktere Syntaxchecks in Perl ab Version 5.18. Im Wget-Upstream ist das Problem bereits erledigt (0102e0e7e503c4fcd70a14eba4ffe357c84de3bb), für 1.14 gibts einen passenden Patch von Javier Vasquez, bei OpenWRT schwirrt auch etwas passendes von Jonathan McCrohan herum, hat es aber noch nicht in den Trunk geschafft.

Wer dem ganzen Problem ausweichen möchte: Seit Januar ist wget 1.15 verfügbar, hierzu einfach in feeds/packages/net/wget/Makefile folgende Änderungen vornehmen:


11c11
< PKG_VERSION:=1.14 --- > PKG_VERSION:=1.15
16c16
< PKG_MD5SUM:=316f6f59292c9098ad81fd54f658c579 --- > PKG_MD5SUM:=7a279d5ac5594919124d5526e7143e28

Linux auf Acer Aspire One ZG5: Kernel-Panic durch SD-Leser

Offenbar gibt es eine Regression in den letzten Linux-Kerneln(vermutlich 3.12.x): Auf oben genannten System kam es alle paar Minuten zu unerklärlichen Kernel-Panics. Im Trace war öfter die Rede vom sdhci-Modul, welches für die SD-Leser zuständig ist. Auslöser ist höchstwahrscheinlich der Slot an der linken Seite – die rechte Seite nutzt PCI-Hotplug und ist ohne Karte dem System nicht bekannt. Betroffen sind vermutlich beide Seiten, zwar ist der rechte durch PCI-Hotplug ohne Karte von System getrennt, jedoch werden beide Controller als „JMicron Technology Corp. Standard SD Host Controller“ erkannt.

Als Workaround kann man – bis der Fehler behoben ist – den SD-Card-Leser abschalten, hierzu wird folgendes Kernel-Argument genutzt:

modprobe.blacklist=sdhci,sdhci_pci

Im Fall von Grub2 auf Archlinux kann es z.B. in /etc/defaults/grub als GRUB_CMDLINE_LINUX hinterlegt werden. Logischerweise lassen sich bis der Fehler behoben ist keine SD-Karten im Gerät nutzen.

top: write error

Nutzt man unter Linux „top“ kombiniert mit einer Pipe kommt es in einigen Fällen derzeit zu einem Fehler, z.B.

top -bn1 | head -n 10
top: write error

Schuld ist offenbar ein Bug in einer top-Version. Der Fehler tritt auf wenn die Pipe vor top beendet wird, also z.B. bei „head“ – in diesem Fall erhält top ein SIGPIPE und wirft die Meldung. Betroffen ist 3.3.6 (Gentoo) und einige 3.3.7 (Fedora). Unter Fedora sollte >=3.3.7-6.fc19 aus Stable Abhilfe schaffen, unter Gentoo ist der Fehler auch in der aktuellen Testing (3.3.8) vorhanden, hier muss manuell der zugehörige 1-Zeilen-Patch aus dem Upstream eingespielt werden. Gentoo-Bug mit genauerer Beschreibung existiert jetzt, ich vermute mal der Einzeiler sollte es recht schnell schaffen.

—Update—

Status: CONFIRMED -> RESOLVED
Resolution: FIXED

*procps-3.3.8-r1 (25 Oct 2013)

25 Oct 2013; Lars Wendler +procps-3.3.8-r1.ebuild:
Fixed write error when using top with pipes. Thanks to Florian Knodt for reporting this in bug #485952.

Linux LVM: „Hängende“ Snapshots entfernen

Was ein Murks: Einer meiner Server brauchte dank Problem des Festplattentreibers einen Neustart. Nach dem Boot fiel mir auf, dass im LVM-System einige alte Snapshots von Systemtests liegen geblieben sind. Schnell mal aufräumen – oder auch nicht, denn dummerweise wollte LVM da nicht mitspielen. Erst mal eine kleine Übersicht des Systems:

root@rescue:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md2 storage lvm2 a-- 2.70t 1.57t
root@rescue:~# vgs
VG #PV #LV #SN Attr VSize VFree
storage 1 32 9 wz--n- 2.70t 1.57t
root@rescue:~# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
[...]
test-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test-www4-data storage swi-a-s- 70.00g www4-data 38.39
test-www4-root storage swi-a-s- 20.00g www4-root 63.09
test2-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test2-www4-data storage swi-a-s- 70.00g www4-data 37.31
test2-www4-root storage swi-a-s- 20.00g www4-root 59.58
www4-boot storage owi-a-s- 512.00m
www4-data storage owi-a-s- 73.24g
www4-root storage owi-a-s- 20.00g
[...]

Man sieht die mit „test“ beginnenden Snapshots welche entfernt werden sollen. Üblicherweise reicht hier ein lvremove welches folgende Ausgabe brachte:

Do you really want to remove active logical volume test-www4-root? [y/n]: y
/sbin/dmeventd: stat failed: No such file or directory
/sbin/dmeventd: stat failed: No such file or directory
Unable to deactivate open storage-test--www4--root-cow (253:2)
Failed to resume test-www4-root.
libdevmapper exiting with 3 device(s) still suspended.

Ab diesem Punkt ist die LVM-Verwaltung faktisch tot. Kommandos wie z.B. lvs hängen sich auf und geben keine Ausgabe. Erst nach einem Reboot ist die Verwaltung wieder möglich, dann taucht der soeben gelöschte test-www4-root wieder auf, ist allerdings kein Snapshot mehr und lässt sich nun auch fehlerfrei entfernen. Keine schöne Lösung, denn ich habe viele Snapshots und dazu eine Abneigung gegen Reboots. Mit strace findet man im hängenden Zustand folgendes:

ioctl(3, DM_TABLE_STATUS, 0x81b5a40) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, BLKGETSIZE64, 0xffcc33a8) = 0
close(5) = 0
close(4) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, BLKGETSIZE64, 0xffcc3378) = 0
close(4) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
ioctl(4, BLKBSZGET, 0x8174458) = 0
_llseek(4, 21474770944, [21474770944], SEEK_SET) = 0
read(4,

Der Auslöser scheint also die Snapshotquelle zu sein, nicht der Snapshot selbst. Eine Suche brachte mich zur Debian-ML auf der das Problem beschieben wird – dankenswerterweise funktionierte der Workarround auch in meiner Situation:

– Der lvremove-Befehl wird in einer Shell abgesetzt und hängt sich auf
– Auf einer zweiten Shell setzt man die Snapshotquelle manuell mit folgenden Befehl wieder in Gang: „dmsetup resume /dev/storage/www4.root“
– Die erste Shell reagiert wieder, der Snapshot sollte verschwunden sein
– Ggf. zurückgebliebene Laufwerksleichen werden mit „dmsetup remove /dev/storage/xxx“ entfernt

Gentoo: net-misc/bridge-utils lässt sich nicht installieren

Dafuq? Während einer Gentoo-Installation ließ sich plötzlich eine 802.1d Ethernet-Bridge nicht mehr korrekt ansprechen. Ein „brctl“ zeigt lediglich „Command not found“. Kann doch nicht sein – net-misc/bridge-utils habe ich eben noch emerged und es gab keine Fehler. Ein „equery files bridge-utils“ zeigt ebenfalls seltsames:

equery files bridge-utils
* Searching for bridge-utils ...
* Contents of net-misc/bridge-utils-1.4:
/usr
/usr/share
/usr/share/doc
/usr/share/doc/bridge-utils-1.4
/usr/share/doc/bridge-utils-1.4/AUTHORS.bz2
/usr/share/doc/bridge-utils-1.4/ChangeLog.bz2
/usr/share/doc/bridge-utils-1.4/FAQ.bz2
/usr/share/doc/bridge-utils-1.4/FIREWALL.bz2
/usr/share/doc/bridge-utils-1.4/HOWTO.bz2
/usr/share/doc/bridge-utils-1.4/PROJECTS.bz2
/usr/share/doc/bridge-utils-1.4/README.bz2
/usr/share/doc/bridge-utils-1.4/RPM-GPG-KEY.bz2
/usr/share/doc/bridge-utils-1.4/SMPNOTES.bz2
/usr/share/doc/bridge-utils-1.4/THANKS.bz2
/usr/share/doc/bridge-utils-1.4/TODO.bz2
/usr/share/doc/bridge-utils-1.4/WISHLIST.bz2
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/brctl.8.bz2

Die Binary fehlt?!

Ein neues emerge unter Aufsicht zeigt auch warum:

[...]
error: field 'ip6' has incomplete type
make[1]: *** [libbridge_if.o] Error 1
make[1]: *** [libbridge_init.o] Error 1
make[1]: *** [libbridge_devif.o] Error 1
[...]

Das kompilieren bricht wegen modifizierter Header-Dateien bei Kerneln => 3.8 ab, das ebuild registriert dies jedoch nicht und meldet eine erfolgreiche Installation. Die Lösung sollte inzwischen bereits verfügbar sein: Mit der seit einigen Tagen stabilen Version net-misc/bridge-utils-1.5 sollte das Problem behoben sein.