Tag Archives: Debian

Xen: Debian Squeeze DomU in Debian Lenny Dom0

Aus der Reihe »Sonntag nachmittag für Frustrationstolerante« heute Folge 137 aus der Reihe »Virtualisierte Maschinen und freie Betriebssysteme«. Folgende Ausgangssituation: Server mit installiertem Debian Lenny als Xen Host (Dom0), es laufen diverse virtuelle Maschinen (DomU), unter anderem welche mit Debian Etch, eisfair-1, eisfair-2 und eben auch eine mit Debian Squeeze, dem aktuellen Testing-Zweig der Debian-Distribution. Bis auf die DomU mit eisfair-1 liefen alle virtuellen Maschinen bis dato mit dem Kernel 2.6.26-2-xen-686, der auch auf dem Host zum Einsatz kommt.

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. :-)

Coffee Connection: Netzwerkverbindungen mit Java im Debian Sid

Ein länglicher Titel für ein ärgerliches Problem mit kurzer Lösung:

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-)

LaTeX zurück an den Start bringen

Neuer Tag, neue Geschichte, die ich einrichten muss. Heute ist LaTeX auf dem System dran. Wir reden immernoch von Debian Squeeze.

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*

HowTo: Windows booten mit Debian und GRUB 2

Bei Debian wurde vor einigen Wochen das neue GRUB 2 in Debian Testing (Squeeze) gespült, das alte GRUB, welches das jetzt offiziell »GRUB Legacy« heißen soll, ablöst. Bei Ubuntu ist das übrigens auch für das nächste Release (Karmic) geplant, das in wenigen Tagen rauskommen wird. Wer diese Systeme als einzige auf einem 08/15-PC einsetzt, wird von dem Wechsel vermutlich kaum etwas mitbekommen.

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.

Einheitliches Verhalten des Compose Key unter Debian

Ich bin gerade dabei mein neues Netbook (Samsung NC10) einzurichten. Ein Problem, das ich auch schon beim alten Notebook hatte: das Verhalten des Compose Key, den ich übrigens gern auf Caps Lock lege, ist in Gnome bzw. GTK-Anwendungen nicht deckungsgleich mit anderen Anwendungen in X wie beispielsweise Qt-Anwendungen. Man findet dann im Netz häufig den Tipp, man müsse die Umgebungsvariable GTK_IM_MODULE="xim" setzen. Nur wird immer nicht so recht klar, wo genau. Ich hab die Zeile unter Debian Squeeze jetzt in $HOME/.xsessionrc eingetragen bzw. die Datei extra dafür angelegt. Das funktioniert jetzt so und beim nächsten Mal, wenn ich das Problem hab, schlage ich hier nach anstatt ewig zu probieren und zu suchen…

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:

Keyboard Layout Samsung NC10

IT-Projekte 2009

Das Jahr ist zwar schon etwas fortgeschritten, trotzdem habe ich mir vorgenommen, bis zum Ende des Jahres in meiner Freizeit ein paar IT-Projekte voranzubringen. Aus der doch recht großen Auswahl der Projekte, die mich interessieren, habe ich die folgenden herausgepickt:

  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.

Debian und ausgelagerte Firmware in Linux 2.6.29

Mein Notebook arbeitet wie so viele andere mit einem Chipsatz von Intel, d.h. LAN und WLAN läuft beides mit Intel Chips:

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-ipw2x00 und firmware-linux.

Scrollbalken im Midnight Commander

Ein interessantes, wenn auch eher unwichtiges Problem kam kürzlich in einem Chat des fli4l/eisfair-Teams auf. Der Entwicklungsserver wurde umgebaut und das System neu aufgesetzt. Mit dem Upgrade auf Debian Lenny hielt auch UTF-8 Einzug und sorgte natürlich für allgemeine Verwirrung. Viele Nutzer arbeiten mit PuTTY auf der Maschine. Dort muss man nicht nur das Locale des Servers richtig einstellen, sondern auch die Line Drawing Character auf Unicode stellen und eine passende Schrift auswählen. Dass dies nicht so einfach ist, habe ich letztens erst ausführlich beschrieben.

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. ;-)

GRUB Error 2

Manchmal findet man seltsame Sachen heraus. Wusste hier jemand, dass nicht alle Versionen von GRUB alle Versionen von ext3 lesen können? Ok, klingt erstmal logisch, dass das für ziemlich alte Versionen von GRUB und für ziemlich neue Versionen von ext3 gilt. Gut da fragt man sich erstmal, wie es denn überhaupt Versionen bei ext3 geben kann, aber egal, vielleicht fang ich die Geschichte doch besser vorn an.

Letze Woche hat sich eine meiner alten Festplatten verabschiedet, wo zu Testzwecken ein Debian Sid installiert war. Gestern bekam ich von Tux Ersatz und heut dachte ich mir, schiebst Du »mal eben kurz« wieder das System drauf. Die Installation verlief auch zügig und glatt. Den Bootloader ließ ich in den MBR von /dev/hdc schreiben und laden wollte ich das ganze wie üblich, nämlich über folgenden Eintrag im GRUB von /dev/hda (das zu nem Ubuntu gehört):

title       hdc: Debian Sid
configfile  (hd2,0)/boot/grub/menu.lst

Das funktioniert üblicherweise wunderbar. Man gelangt zunächst in das Bootmenü vom GRUB auf /dev/hda und von dort über obigen Eintrag in das Menü von /dev/hdc. So können die Systeme auf jeder der Platten ihre eigenen Bootloader eigenständig verwalten und kommen sich auch bei Kernelupdates nicht ins Gehege. Heute führte das allerdings zum Error 2. Das Handbuch von GRUB sagt dazu lapidar:

2 : Bad file or directory type
This error is returned if a file requested is not a regular file, but something like a symbolic link, directory, or FIFO.

Die Recherche nach der Lösung zu solchen Fehlern gestaltet sich natürlich schwierig. Ich hatte ein wenig Glück und fand diesen Thread im Ubuntu-Forum. Dort näherte man sich Stück für Stück einem ähnlichen Problem. Ich konnte ebenfalls mit der GRUB-Shell verifizieren, dass das GRUB aus dem MBR meiner /dev/hda nicht in der Lage war das Filesystem auf /dev/hdc1 zu lesen, obwohl letzteres ein sauberes (fsck von GRML drüberlaufenlassen) ext3 war. Mit anderen ext3 kam das bis dahin ja auch klar. Recht weit unten in dem Thread schreibt dann jemand:

Did you upgrade to Hardy from an earlier version of Ubuntu? Then you might of have older version of grub which cannot read ext3 partition with 256 inodes.

Da hab ich nicht schlecht geschaut. Das heißt einerseits wie eingangs angedeutet, dass es vorher (dieses mysteriöse »früher«) ext3 nur mit weniger inodes gab und ältere Versionen von GRUB mit so vielen nicht umgehen können. Das GRUB ist tatsächlich ein wenig älter, das Ubuntu ist ungefähr 2005 auf die Kiste gekommen, also wahrscheinlich ursprünglich als Dapper Drake oder vielleicht sogar noch Breezy Badger. Na und der aktuelle Installer von Debian Lenny scheint derart neue ext3-Formatierungen zu schreiben. Einfaches Neuschreiben des Bootloaders mit dem aktuellen GRUB von Intrepid Ibex hat dann jedenfalls im Handumdrehen das Problem behoben. Ich sag ja, seltsame Sachen gibt’s.

Vorsicht Kunde!

Ich bin ein Freund freier Software und ich verwende diese sehr gern auf alten Rechnern. Das ökologische Bewusstsein lässt mich vom Kauf neuer Hardware stets zurückschrecken, wenn die alte noch funktioniert. In einem dieser Rechner ist (bis auf den im Notebook) mein einziger DVD-Brenner eingebaut, ein mittlerweile etwas älteres Teil von LG (GSA-4163A), das auch DVD-RAM brennen kann. Auf dem Rechner ist »nur« Debian installiert und das Brennen mit k3b funktioniert tadellos.

Nun hatte ich letzte Woche nach längerer Zeit mal wieder neue DVD-Rohlinge gekauft, weil mir die alten ausgegangen waren. Ich dachte, es könne nicht schaden, mal nach neuer Firmware für den DVD-Brenner zu schauen, die Hersteller optimieren ja doch die Brennrezepte und packen das in neue Firmware.

Leider war es mir mit Firefox/Iceweasel auf dem Debian nicht möglich auf der Webseite von LG die entsprechende Firmware zu finden. Auf dem Windows-Notebook mit Firefox und Opera sah das dann genauso aus, also machte ich meinem Ärger beim Kundenservice Luft:

Sehr geehrte Damen und Herren,

mir ist es leider mit drei verschiedenen Browser nicht gelungen eine aktuelle Firmware für meinen DVD-Brenner von Ihrer Website zu laden. Entweder wurde überhaupt keine Suchfunktion angezeigt oder es wurden keine Ergebnisse gefunden. Einfache Listen ohne Javascript und Flash, wo man schnell und einfach findet was man sucht, wären wesentlich kundenfreundlicher. :-(

Mit freundlichem Gruß
Alexander Dahl

Im Anschluss daran fand ich noch die »richtige« Supportseite und die aktuelle Firmware. Das hätte mich allerdings keinen Schritt weiter gebracht, denn dort heißt es:

1.verbinden Sie das Laufwerk als Master mit dem secondary IDE-Controller
setzen Sie den Jumper auf der Rückseite des Laufwerkes auf Master. Verbinden
Sie kein anderes Gerät an diesem IDE-Kabel.

Abgesehen von dieser widersinnigen Bastelei hätte mir aber noch etwas anderes einen Strich durch die Rechnung gemacht:

Diese Firmware ist nur für den Gebrauch an PC`s mit den Betriebssystemen:
Windows XP, Windows 2000, Windows Millennium Edition (ME), und
Windows 98SE.

Das ist so natürlich Unsinn. Richtig ist, dass die Software zum Firmware-Upgrade nur unter den oben genannten Betriebssystemen läuft. Alle anderen sind außen vor. Glücklicherweise ist die »neueste« Firmware für das Gerät schon älter. Ein kurzer Check verriet mir, dass diese bereits installiert war.

Damit hätte die Geschichte abgeschlossen sein können, das war wie gesagt alles letzte Woche. Der Kracher kommt aber noch, nämlich die Antwort auf meine Anfrage beim Support:

Sehr geehrter Herr Dahl,

herzlichen Dank, dass Sie mit LG Electronics Deutschland GmbH Kontakt aufgenommen haben.

Wahrscheinlich benutzen Sie den Browser Mozilla Firefox. Da unsere Seite fuer den Internetexplorer optimiert ist, moechten wir Sie bitten diesen zu verwenden.
Dann haben Sie auch bei der Suchoption den gewuenschten Erfolg.

Bei Rueckfragen senden Sie bitte den gesamten Mailverkehr als Anhang mit.

Wenn Sie noch weitere Fragen oder Anregungen haben sollten, können Sie sich jederzeit wieder an uns wenden.

Mit freundlichen Gruessen

Fragen hätte ich keine, aber eine Anregung an LG: Gestalten Sie doch bitte Ihre Webseiten so, dass nicht nur Nutzer des Internet Explorer alle gewünschten Informationen erhalten und ermöglichen Sie Nutzern freier Betriebssysteme auch ein Firmware-Upgrade, zur Not über irgendeine Bootdiskette oder -CD!

Nachtrag: Ich dachte mir, dass LG das hier wohl nicht lesen würde, also antwortete ich per Mail:

Sehr geehrte Damen und Herren,

Sie boten in der Antwort auf meine Anfrage an, mich mit weiteren
Anregungen an Sie zu wenden – gern.

Ich würde es zunächst begrüßen, wenn Sie Ihre Webseiten nicht nur auf
einen einzigen Browser optimieren würden, sondern der wachsenden Zahl
von Nutzern alternativer Browser und Betriebssysteme ebenso ermöglichen,
an die gewünschten Informationen zu gelangen.

Desweiteren empfinde ich es als klare Einschränkung, Firmware-Upgrades
nur unter den teuren Betriebssystemen von Microsoft durchführen zu
können. Nutzer von Linux, BSD oder Solaris sind praktisch nicht in der
Lage Ihre Hardware sinnvoll einzusetzen, weil Ihnen Firmware-Upgrades
verwehrt bleiben. Wie wäre es stattdessen Images für Boot-Disketten oder
-CDs bereitzustellen, von denen das Firmware-Upgrade
betriebssystemunabhängig möglich ist?

Mit freundlichem Gruß
Alexander Dahl

Was kommt zurück?

I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The Symantec Mail Security program

: host 156.147.51.142[156.147.51.142] said: 550 gsfs@lge.com…
No such user (in reply to RCPT TO command)

Gut, wer nicht will, der hat schon – dann halt nicht.