Problem des Tages: Einen Systemstart nach dem letzten Update funktionierten Bluetooth-Tastatur und -Maus von Logitech nicht mehr, in meinem Fall konkret das Dinovo-Set.

Ich habe häufiger Ärger mit Logitech unter Linux, meistens ließ sich das aber mit einem Reset des Bluetooth-Dongles¹ beheben. Dieses Mal nicht, der Fehler war persistent.
dmesg, logs und Modulliste waren soweit korrekt, es war alles da, was für die Geräte gebraucht würde und es wurde laut lsusb auch alles erkannt. Nur funktionierte einfach nichts. $SUCHMASCHINE lieferte dafür auch keine weiteren Ergebnisse.

Letztendlich habe ich das Problem in den udev-Regeln², speziell der Datei 70-hid2hci.rules gefunden. Dort steht in Zeile 15:

RUN+="hid2hci --method=logitech-hid --devpath=%p"

Ein kurzer Blick auf die Manpage zeigt, dass der Aufruf nicht korrekt ist. Ich habe die Zeile so abgeändert:

RUN+="hid2hci --method=logitech --mode=hid --devpath=%p"

Seit dem funktionieren Tastatur und Maus wieder einwandfrei.

Die Regel deckt einen großen Bereich von Logitech-Produkten ab, das Problem tritt also wohl auch dort auf. Debian-Bugreport kommt dann später noch.

1. Abziehen und wieder dranstecken. ;)
2. zu finden unter /lib/udev/rules.d/

Grund genug für meinen Mitbewohner, den Kanal unseres WLAN-Access-Points mal in eine bisher wenig genutzte Region zu verschieben: Kanal 13. Nachtigall ick hör Dir trapsen, war da nicht mal was, mit Kanälen, die in den USA verboten sind, in Europa aber nicht? Muss wohl so sein, und da Debian ja fürsorglich ist, ist die Einstellung für USA default – obwohl, wenn man sich die Lösung ansieht, kann man Debian vermutlich nicht mal die Schuld in die Schuhe schieben.

Was also, wenn das Notebook jetzt nur Netze bis Kanal 11 anzeigt? Dann legt man unter Debian eine Datei in /etc/modprobe.d/ an. Wie die heißt, ist nicht so wichtig, bei mir heißt die wlan_EU.conf, auf .conf sollte sie wohl enden. Drin steht bei mir folgendes:

options cfg80211 ieee80211_regdom=EU

Eine Zeile, reicht aus. Die übergibt dem Kernelmodul cfg80211 beim Laden die passende Option und dann sind alle Kanäle sichtbar. An einigen Stellen im Weltnetz steht das “EU” noch in Anführungszeichen, also wenn’s ohne nicht klappt, dann vielleicht mit.

Vor einigen Tagen nun gab es in Debian Squeeze ein Update von udev 149 auf 150. Das Paket verweigerte dann aber die Installation mit dem Hinweis, dass der verwendete Kernel zu alt sei. Das war durchaus nervig, weil dadurch auch die Updates anderer Pakete nicht mehr eingespielt wurden, also hieß es: Kernel-Update.

Einfach mal schnell Kernel-Update gestaltete sich dann leider nicht so einfach. Debian hat Xen quasi aus der Distribution rausgeworfen bzw. bietet keine dedizierten Xen-Kernel mehr an. Gut, das ließ sich noch relativ problemlos lösen. Die Wahl fiel auf linux-image-2.6.30-bpo.2-686-bigmem von backports.org, denn dort heißt es:

This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation.

Also fix den Kernel in der Dom0 installiert. DomU runtergefahren, Config angepasst, Kernelmodule ins Dateisystem der DomU kopiert, DomU gestartet und dann – nichts. Beim Hochfahren blieb die virtuelle Maschine einfach hängen, und zwar schon so früh im Bootprozess, dass ich keine Ahnung hatte, woran das lag.

Der nächste Schritt bestand dann darin eine weitere VM zum Testen aufzusetzen und die Suchmaschine der Wahl zu befragen. Ich weiß nicht, wo ich überall gelesen habe und was ich alles probiert habe. Am Ende funktionierte der Kernel, es waren nur Anpassungen an der Xen-Config notwendig, daher erstmal hier die Config und dann noch ein paar Kommentare dazu:

kernel  = '/boot/vmlinuz-2.6.30-bpo.2-686-bigmem'
ramdisk = '/boot/initrd.img-2.6.30-bpo.2-686-bigmem'
memory  = '128'
root    = '/dev/xvda1 ro'
disk    = [ 'phy:heaven/falbala_root,xvda1,w',
            'phy:heaven/falbala_swap,xvda2,w' ]
name    = 'falbala'
vif  = [ 'mac=00:16:3e:7d:4b:a2, bridge=eth0' ]
extra = 'xencons=hvc0 console=hvc0'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Wie man sieht, sind die Block-Devices, die in die VM gereicht werden, LVM Logical Volumes. Hier musste ich die Durchgereichten von /dev/sda* auf /dev/xvda* wechseln. Das hat definitiv mit dem verwendeten Kernel zu tun, der die Blockdevices nur noch dort ähm findet, oder so. Ich denke das war die entscheidende Änderung. In der mit »extra« beginnenden Zeile, habe ich die Angaben für die Xen-Konsole noch angepasst, irgendwo hatte ich gelesen, dass das jetzt hvc0 und nicht mehr xvc0 heißen muss. Die entsprechenden Änderungen an /etc/fstab und /etc/inittab innerhalb der virtuellen Maschine mussten natürlich auch noch vorgenommen werden, aber danach lief die DomU wieder und auch das Update von udev ließ sich problemlos einspielen. :-)

Seit einigen Tagen mag sich Eclipse unter Debian Sid auf meinem Arbeitsnotebook nicht mehr mit dem Internet verbinden. Die Fehlermeldungen sind, je nach Modul, verschieden, laufen letztendlich aber immer auf etwas in der Form “Network noch reachable” hinaus. Erst dann fällt auch auf, wie oft ich doch bei der Entwicklung auf das Internet zugreife: Subversion und Maven funktionieren nicht mehr, Updates und das Einspielen von Plugins ist unmöglich und irgendwann – ein wichtiger Hinweis auf die Fehlerursache – stellte sich heraus, dass gar keine Java-Anwendung mehr Zugang zum Netzwerk hat.

Nachdem ich zunächst nach Fehlern bei Eclipse gesucht habe, war die Lösung nun recht nahe: Ein Blick in die Fehlerberichte für das Paket sun-java6-jdk zeigt den Bug #560044, der genau mein Problem beschreibt. Offenbar hält SUNs Java sich nicht an die Konventionen für den Umgang mit IPv4- und IPv6-Verbindungen, so dass IPv4 gar nicht mehr funktioniert.

Der Fehlerbericht enthält am Ende auch einen Workaround, der bei mir funktioniert: In der Datei /etc/sysctl.d/bindv6only.conf die Variable net.ipv6.bindv6only von 1 auf 0 setzen, und schon dürfen IPv6-Sockets auch IPv4-Pakete empfangen. [Update: Mit dem Aufruf invoke-rc.d procps restart muss die Konfiguration dann noch neu geladen werden.] Problem solved.

Nun muss dieser Bug nur noch unter dem Google-Query “Debian Eclipse network connection error” erscheinen, dann wäre er auch keinen Blogeintrag mehr wert. 8-)

Erster Schritt:

aptitude install texlive-full vim-latexsuite

Ja ich weiß, das ist das Rundum-Sorglos-Paket, was mir auch sehr viel Kram auf die Platte spült, was ich nie nutzen werde. Macht nichts, so ist das halt mit Rundum-Sorglos-Paketen. vim-latexsuite will noch aktiviert werden – wie, musste ich auch erst im Netz wiederfinden. Sehr hilfreich:

man vim-addons

Soweit so gut, als nächstes habe ich dann den Ordner ~/texmf aus meinem Backup zurückgespielt. Einfach mal `texhash` eingeben hat dann allerdings noch nicht dazu geführt, dass das System da was mit anfangen wollte, also wieder Doku wälzen. Ergebnis:

mktexlsr ~/texmf

Führte erstmal dazu, dass ich das gewünschte Dokument kompilieren konnte, aber ich bekam noch Warnungen, dass was mit den Fonts nicht stimmte:

LaTeX Font Info:    Try loading font information for OMS+lmss on input line 110
.
LaTeX Font Info:    No file OMSlmss.fd. on input line 110.

LaTeX Font Warning: Font shape `OMS/lmss/m/n' undefined
(Font)              using `OMS/cmsy/m/n' instead on input line 110.

LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <10> on input line 110.
LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <7> on input line 110.
LaTeX Font Info:    External font `lmex10' loaded for size
(Font)              <5> on input line 110.

Die Suche, wie man das beheben kann, war nicht so super aufschlussreich. Ich hab das dann wie folgt beheben können, wo bei ich nicht weiß, ob das jetzt die eleganteste Lösung ist:

\usepackage{textcomp}

Alles in allem, ich schau grad mal auf die Uhr, über eine Stunde, um den Kram zusammenzusuchen, um dann festzustellen, dass ich auch noch das Dokument übersetzen muss, weil es in Englisch geschrieben ist. *sigh*

Auf meinem neuen Netbook ist nun Windows XP Home vorinstalliert gewesen. Ich hab das mitbezahlen müssen und ich gebe zu, dass ich es draufgelassen habe, einfach um ab und zu nochmal Diablo II spielen zu können, ohne da im Linux große Verrenkungen anstellen zu müssen mit Installation, Spiele-3D-Grafik oder gar Wine. Nun ist es drauf und ich will es auch booten können. Der Installer von Debian Stable (Lenny) hatte das seinerzeit korrekt erkannt und in der Konfiguration von GRUB Legacy eingetragen.

Beim Upgrade auf GRUB 2 hat Debian diesen Eintrag nun schlichtweg ignoriert. Es hat auch keine neue Suche nach alternativen Betriebssystemen angestrengt, obwohl man vermutlich nur ein bisschen Code aus dem Installer hätte nutzen müssen. In der Liste der zum Boot möglichen Systeme tauchte Windows jedenfalls nicht auf.

Wie das nun bei dicken Rewrites so ist, die noch während des Beta-Stadiums ohne richtige Dokumentation auf die Nutzer losgelassen werden: man steht erstmal im Regen. Dazu kommt, dass der Distributor sich dann noch was ausdenkt, um das sauber in sein System zu integrieren. Bei der Suche, wo ich das nun eintragen müsste, hab ich dann folgendes herausgefunden:

Die neue Config-Datei von GRUB 2 ist /boot/grub/grub.cfg. Das erste was bei Debian drin steht:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

Soviel Hilfe hätte ich gar nicht erwartet. In /etc/default/grub kann man zunächst mal ein paar Optionen für den Kernel zum Laden setzen. Sowas wie quiet oder vga=789 oder ähnliches. Die Syntax ist selbsterklärend.

In /etc/grub.d liegen dann verschiedene Skripte:

-rwxr-xr-x 1 root root 3223 12. Sep 18:08 00_header
-rwxr-xr-x 1 root root 1152 12. Sep 17:56 05_debian_theme
-rwxr-xr-x 1 root root 3221 10. Aug 19:49 10_linux
-rwxr-xr-x 1 root root 4418 12. Sep 18:08 30_os-prober
-rwxr-xr-x 1 root root  281  7. Okt 23:07 40_custom
-rw-r--r-- 1 root root  483 10. Aug 19:49 README

Die sollte man auch alle brav in Ruhe lassen, wenn man sich nicht wirklich gut mit Shell-Scripting auskennt. Allerdings ist 40_custom genau der richtige Ort für unseren Eintrag um Windows zu booten. Dieser Eintrag sieht dann ungefähr so aus, bzw. gleich mal die ganze Datei, damit das klar wird:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows XP" {
    set root=(hd0,2)
    chainloader +1
}

Auch dies ist nur ein Shell-Script, das irgendwann im Update-Prozess für die Konfigurationsdatei von GRUB 2 ausgeführt wird. Bei der Angabe der Partitionsnummer aufpassen, da gab es eine Verschiebung um +1 gegenüber GRUB Legacy. Jetzt also noch den abschließenden Debian-spezifischen Befehl ausführen, um die neue grub.cfg zu schreiben und schon kann man wieder Windows booten:

update-grub

Update: Seit dem Update von heute, 24.01.2010, erkennt Debian Squeeze die Windows-Installation wieder automatisch. D.h. man kann den Inhalt aus /etc/grub.d/40_custom wieder rausnehmen. Einmal update-grub aufrufen sollte danach genügen, um Einträge für Windows in die Liste zu zaubern.

Update: Die Option vga=789 ist übrigens keine gute Wahl mehr. Spätestens seit Kernel 2.6.32-3 ist KMS, also Kernel Based Mode Setting, aktiv und funktioniert auch und wenn man dann vga setzt, kommt man aus dem X nicht mehr per Strg+Alt+F2 auf die »normale« Konsole.

Nachtrag: Um die Frage aus den Kommentaren noch aufzugreifen, ich habe natürlich keine dedizierte Compose-Taste, so wie in der Wikipedia auf den Bildern zu sehen. Vielmehr kann man unter Linux andere Tasten mit dieser Funktion belegen. Ich verwende dazu die ansonsten nutzlose Taste Caps Lock. Die Verwendung des Compose Key ist dann simpel. Einmal Compose Key drücken und dann eine meist intuitive Sequenz von anderen Tasten danach. So gibt beispielsweise Compose + T + M das hier: ™. Praktisch ist das auch, wenn man oft ausländische Buchstaben hat. Das norwegische ‘ö’ gebe ich ein, indem ich Compose + / + o drücke: ø. Viele dieser Kombinationen sind wirklich intuitiv und man erreicht so auf einfache Weise eine große Vielzahl von Unicode-Zeichen, die man sonst nur schwierig einfügen kann. :-) Hier nun noch ein Foto von der deutschen Tastatur des Samsung NC10:

1. IMPULS: Dieses Projekt hat inzwischen doch schon ein paar Jahre hinter sich und es gab diverse Situationen, in denen ich es gebraucht hätte. Bis Ende des Jahres sollten hier ein lauffähiger Daemon (aber auf Java-Basis) und ein paar Clients sowie mindestens ein Reader stehen.
2. Antiblau: Den Server haben wir seit Ende 2005, aber noch immer sind ein paar Funktionen nicht verfügbar und auch die vorhandene Administrations-Infrastruktur kann mal modernisiert werden.
3. Debian: Entwickler werde ich wohl in diesem Jahr nicht, aber ein paar Pakete aus eigenen Sachen möchte ich bauen und wenigstens soweit in die Community reinschauen, dass ich sicher entscheiden kann, ob ich überhaupt Entwickler werden will.
4. QCaff: Eine grafische (Qt-basierte) Variante von CAFF, die sowohl unter Windows als auch unter Linux laufen soll und das Management von GPG-Keys für Jedermann ermöglichen soll. Insbesondere bei der Nachbereitung von Keysigning-Parties besteht hier offenbar Softwarebedarf. Wenn alles klappt, ist das aber trotzdem ein recht überschaubares Tool. Sofern vorhanden, werde ich bestehende Lösungen weiterverwenden.

Weiterhin warten auch bei UniMentor interessante Programmieraufgaben und der FaRaFIN kann ebenfalls mit einem interessanten Projekt aufwarten. Anfang 2010 werden wir sehen, was davon ich umsetzen konnte.

lassy:~# lspci | grep 'Network\|Ethernet'
02:07.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81)

Nun kam heute früh der neue Linux Kernel 2.6.29 in Debian unstable an. Bei der Installation wunderte ich mich schon, dass das Update der initramfs nicht 100% glatt lief und folgende Meldungen kamen:

W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

Beheben ließ sich das in meiner Debian-Installation dann einfach durch die Installation der Pakete firmware-ipw2×00 und firmware-linux.

Im konkreten Fall hatte einer der Entwickler PuTTY korrekt eingerichtet und als Schrift die Courier New ausgewählt. Das Problem: der Midnight Commander stellt alles korrekt dar, bis auf die Scrollbalken, wo nur hässliche Kästchen erscheinen. Das Problem ließ sich relativ leicht verifizieren. Auf einem Debian Lenny, sieht das mit Courier New tatsächlich so aus, bei einer Verbindung zu einem Debian Etch sieht man mit Courier New hingegen korrekt dargestellte Pfeile. Ein Umschalten auf die von mir bevorzugte DejaVu Sans Mono bewirkte in beiden Sessions eine korrekte Darstellung. Wenn man genau hinsah, zeigten sich aber subtile Unterschiede.

Ich hab dann die entsprechenden Zeichen kopiert und im Hex-Editor unter die Lupe genommen. Auf dem Rechner mit Etch gab ein `mc --version` (gekürzt) folgendes:

GNU Midnight Commander 4.6.1

Mit dem Wissen aus meinem früheren Beitrag »Wie funktioniert UTF-8?« sah meine Analyse der Zeichen dann so aus:

▲ – E296B2h – 11100010 10010110 10110010 – 00010010110110010b – 9650 – U+25B2
● – E2978Fh – 11100010 10010111 10001111 – 00010010111001111b – 9679 – U+25CF
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▼ – E296BCh – 11100010 10010110 10111100 – 00010010110111100b – 9660 – U+25BC

In den letzten beiden Spalten stehen die Unicode-Nummern der Zeichen in dezimal und hexadezimal. Auf decodeunicode.org findet man raus, dass diese alle zur Gruppe »Geometric Shapes« gehören und korrekt encodiert sind. Diese Zeichen werden mit Courier New wie bereits erwähnt korrekt dargestellt. Bei Lenny gibt es eine neuere Version des Midnight Commander:

GNU Midnight Commander 4.6.2-pre1

Bei dieser Version sehen die Scrollbalken dann so aus:

▴ – E296B4h – 11100010 10010110 10110100 – 00010010110110100b – 9652 – U+25B4
◈ – E29788h – 11100010 10010111 10001000 – 00010010111001000b – 9672 – U+25C8
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▾ – E296BEh – 11100010 10010110 10111110 – 00010010110111110b – 9662 – U+25BE

Auch diese Zeichen gehören zur Unicode-Untergruppe »Geometric Shapes« und sind absolut korrekt encodiert, aber sie sind leider nicht in Courier New enthalten. Davon kann man sich unter Windows XP überzeugen, indem man im Startmenü unter Zubehör und Systemprogramme die Zeichentabelle öffnet. Als Schriftart dann Courier New wählen, erweiterte Ansicht auswählen, als Zeichensatz Unicode, Gruppieren nach Unicode-Unterbereich und dort dann Block-/geometr. Elemente. Die dicken Pfeile vom mc 4.6.1 sind drin, die kleineren nicht.

Diese unscheinbare Änderung lässt sich tatsächlich auf den Midnight Commander zurückführen. Wenn man sich mal den UTF-8 Patch im Downloadbereich auf midnight-commander.org ansieht, dann findet man an entsprechender Stelle im Quellcode genau diese Zeichen.

Simple Lösung: eine andere Schrift als Courier New auswählen. Das gilt übrigens auch für den Browser, falls in obigem Beispiel anstelle der Pfeile auch nur komische Zeichen zu sehen sind. ;-)