Schlagwort-Archive: Bug

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.

Arch Linux Bug: “cron for user root job sys-hourly”-Mails

Durch einen Fehler in pacman kommt es seit einigen Wochen zu einem Fehler während der Arch Linux Systemupdates. Unter anderem wird ein Script zum synchronisieren der Systemuhr aus den stündlichen Cronjobs entfernt – dummerweise ist dann das Verzeichnis /etc/cron.hourly leer und Pacman hat die Angewohnheit leere Verzeichnisse zu löschen. Entsprechend kann Cron das Verzeichnis nicht mehr finden und quittiert das ganze stündlich mit einer Email “cron for user root job sys-hourly”.

Als Workarround reicht ein simples “mkdir /etc/cron.hourly” als root – die Rechte sollten mit root:root OK sein.

Käferjagd – MySQL, Roundcube und die Zeichenkodierung

Schei? Encoding

Das trifft meine Beschäftigung in den letzten Tagen ganz gut. Ich habe bereits länger auf meinem Mailserver sieve im Zusammenspiel mit Dovecot im Einsatz. Als Frontend ist nach vim und dem ThunderbirdPlugin schlussendlich ein (inzwischen integriertes) Plugin für meinen Webmailer Roundcube zum Einsatz gekommen. Im Gegensatz zu den vorherigen Lösungen ist es hier über eine GUI möglich sich einfache Regeln, wie aus vielen Mailprogrammen bekannt, zusammen zu klicken. Inzwischen gibt es eine Weiterentwicklung, welche einige lang erwartete Features mitbringt. Leider verlief mein Test nicht ganz wie geplant.

Erste Beobachtung: Immer wenn man ein Sonderzeichen verwendet ist der Webmailer nicht mehr nutzbar. Die aktuelle Sitzung wird beendet, versucht man sich neu einzuloggen kann man Mails lesen, ein Klick auf die Filterseite führt aber zu einem neuen Absturz. Einzige Lösung: Das Filterscript mit einem anderen Editor löschen. Nicht ganz was ich wollte, aber eine Nachfrage beim Entwickler verheißt nichts Gutes: Kein Fehler in der Richtung bekannt. So weit so schlecht.

Sinnvollste Möglichkeit: Testserver hochziehen (LVM-Snapshots ftw) und Problem einschränken. Schnell war klar: Es muss wohl an der Config liegen. Auf einem frischen Server ließ sich die aktuelle Roundcube mit Plugin nutzen, auf der Kopie des Produktivservers tritt immer wieder der Fehler auf. Etwas hin und her – ratlosigkeit. Der Testserver konnte auf dem Filterserver des Testservers problemlos arbeiten, also kann es nicht am Mail-/Filterserver. Auch die Kopie des Programmverzeichnisses vom Produktiv auf den frischen Testserver arbeitete dort problemlos. Doch die Konfiguration? Also nahezu das komplette /etc vom frischen Testserver auf die Produktivkopie gezogen, PHP-FCGI auf mod_apache, etc, etc – nada. Einziger Unterschied, der mir auffiel war 64< ->32Bit – das wirds ja wohl kaum sein.

Hilft nichts – der Holzhammer muss her: Das komplette Plugin mit echos durchsetzt und huh – der Abbruch passiert beim Speichern der Session. OK, generell würde ich ja sagen nicht korrekt escaped, aber warum tritt es dann nur auf einem Server auf?!

Stunden später war mir dann meine eigene Blindheit auch klar: Ich hatte zwar alle Daten kopiert, aber nicht die Datenbank. Die hatte ich zwar kurz verglichen, aber ein kleines aber verhängnisvolles habe ich übersehen. Roundcube nutzte in den ersten Versionen ASCII als Zeichencodierung für die in MySQL gespeicherte Session-Table. Dies wurde irgendwann auf UTF8 umgestellt, jedoch nur in den Scripten für Neuinstallationen – die Update-Datei enthält keine entsprechende Konvertierung. Da mein RC schon lange läuft hing die Tabelle entsprechend auf ASCII und machte bei UTF8-Zeichen in der Session die Fliege. 3 Tage gebastel und ein ALTER TABLE später funktioniert nun alles – so kann man sich auch beschäftigen…

Einwohnermeldeämter sorgen für unfreiwillige Transparenz

Nachdenken, dass kann man nur einigen Admins empfehlen, wenn die Angaben des ARD-Magazins Report München stimmen: Die browserbasierte Software der Einwohnermeldeämter wird nach deren Angaben mit einem Standardpasswort ausgeliefert – jeder normale Mensch würde dies wohl ändern, aber knapp 200 Gemeinden war das anscheinend zu Aufwändig. Die Eindringlinge freuten sich, denn dieses Standardkennwort wurde auch auf der Onlinedemo des Herstellers verwendet. Hersteller und Gemeinden suchen nun nach den Sündenbock und spielen mit unterschiedlichen Zahlen der betroffenen Anwender… (via Heise, Golem, Gulli, etc)