Die Dokumentation man interfaces(5) und die Beispiele in /usr/share/doc/ifupdown/examples sind
korrekt, die »map«-Zeilen-Syntax von mapping stanzas ist aber verwirrend. Die Semantik der mapping
stanza ist wie folgt:

• Eine mapping stanza wird durch das Schlüsselwort »mapping« eingeleitet.
• Hinter »mapping« wird mit einem »pattern in shell glob syntax« angegeben, für welche (physischen oder logischen) Devices dieses Mapping gelten soll. Beim Mapping eines Devices wird die erste mapping stanza verwendet, deren Pattern auf das zu mappende Device passt.
• Passt eine mapping stanza, wird das durch »script« angegebene Script ausgeführt. Es erhält den Namen des zu mappenden Devices in der Standardeingabe.
• Das Script muss den Namen des logischen Devices, auf den das physische Device gemappt werden soll, auf die Standardausgabe ausgeben.
• Das Script erhält zusätzlich über stdin alle Zeichenketten aus mit »map« beginnenden Zeilen der mapping stanza, jedoch ohne vorangestelltes map. Das kann als zusätzliche Konfigurationsmöglichkeit verwendet werden, »map« ist jedoch kein Befehl wie »bilde etwas auf etwas anderes ab« wie in der alten Version des Systems, sondern nur eine Kennzeichnung des Zeilenbeginns. Üblicherweise werden die map-Zeilen jedoch nach Art eines solchen map-Befehls vom Script ausgewertet: das erste Wort gibt ein Charakteristikum des per Argument 1 übergebenen Devices an, das zweite Wort gibt an auf welches logische Device es gemappt werden soll wenn es dieses Charakteristikum hat.
• Das eigentliche Mapping wird also durch das Script, nicht durch /etc/network/interfaces durchgeführt.
• Es werden soviele Mappings hintereinander ausgeführt, bis kein Pattern irgendeiner mapping stanza mehr auf den aktuellen Devicenamen passt. Dann wird eine iface stanza zu diesem Devicenamen gesucht.

Es könnte das Paket g++-3.2 installiert sein, das nur das Programm g++-3.2 enthält, aber keinen Befehl g++. Dieser wird als symbolischer Link auf g++-3.3 vom Paket g++-3.3 (»Default«-Version) zur Verfügung gestellt. Man installiere deshalb einfach das Debian-Paket g++, es installiert automatisch durch die entsprechende Paketabhängigkeit die Default-Version mit dem Programm g++ (Paket g++-3.3).

Bisher unbekannt. Mehrmaliges Auswerfen und wieder Einstecken löst das Problem.

Man bringe den Drucker in den Laserjet2-Kompatibilitätsmodus und verwende den Treiber »EPSON :: EPSON EPL-7100 laserjet«. Alternativ möglich ist es, den Treiber »laserjet« direkt zu verwenden (ursprünglich gedacht für HP Laserjet 1) oder den Treiber »Laserjet II series«. Letzterer liegt jedoch den Treibern im Paket foomatic-db nicht mehr bei.

Man verwende das KDE-Kontrollzentrum kcontrol. Standardmäßig sind jedoch möglicherweise noch nicht die richtigen Druckertreiber installiert (z.B. dann, wenn man nur die Hersteller ESP und POSTSCRIPT sieht). Dann installiere man (bei Debian-Linux) alle Pakete, die mit »foomatic« beginnen. Beim nächsten Start von kcontrol wird dann die Treiberdatenbank neu gelesen und man sieht die neuen Treiber.

Es gibt ein OpenSource-Projekt mit Treibern unter linux-lc100020.sourceforge.net/ . Hier wird die Installation des Treibers ZD1201 Driver 0.3 (Experimental) in der Version vom 2004-06-12 beschrieben, für das dadurch unterstützte Gerät »Zyxel ZyAir B-220 USB« unter Debian Linux sarge.

Der Treiber basiert auf dem Treiberpaket linux-wlan-ng. Der ZD1201 Driver 0.3 z.B. besteht zum Hauptteil aus den modifizierten Quellen von linux-wlan-ng 0.2.1pre21, dazu aus einem 2.6.x Kernel Patch. (Dieser Patch ist nur notwendig, wenn das USB-Device nicht korrekt erkannt wird). Die Haupt-README-Datei ist damit Zydas1201-README.txt; die Datei README dagegen gehört zum Paket linux-wlan-ng. Hier eine kommentierte, knappe Version der Installationsanleitung aus diesen beiden README-Dateien:

1. Die Quellen für den Kernel, mit dem man den »Linux Zydas 1201 Driver 0.3« einsetzen will, als Debian-Paket installieren (apt-get oder synaptic verwenden).
2. make menuconfig um den Kernel zu konfigurieren.
3. Den Kernel aus diesen Quellen ein erstes mal kompilieren. Um das Debian-Paketmanagement nicht zu stören, verwende man: »make-kpkg kernel-image. Dabei wird z.B. die Datei ./include/linux/version.h (ausgehend vom root-Verzeichnis der Kernel-Quellen) erzeugt. Sie wird vom Script »Configure« (bei make config ausgeführt) erwartet; ist sie nicht vorhanden, erscheint die Fehlermeldung »Linux source tree [...] is incomplete or missing!«. Selbst bei installierten Kernelquellen und korrekt in make config angegebenem Pfad.
   Tipp für die Zukunft: »make-kpkg buildpackage« ist äquivalent zu »make-kpkg clean binary«, wiederum äquivalent zu »make-kpkg clean kernel_source kernel_headers kernel_doc kernel_image«. Also Vorsicht: durch das Target »clean« wird also die Arbeit aller bisherigen Compiliervorgänge zunichte gemacht.
4. In /usr/src/ ist dann der Kernel als Debian-Paket vorhanden (.deb), zum Beispiel: »/usr/src/kernel-image-2.6.8_10.00.Custom_i_386.deb«. Installieren mit (wieder am Beispiel): »dpkg -i kernel-image-2.6.8_10.00.Custom_i_386.deb«.
5. Das Treiberpaket »Zydas1201-LinuxDriver-0.3.tar.gz« entpacken.
6. In der obersten Ebene des entstehenden Verzeichnisbaums ausführen: make config; make all. Selbstkompilieren ist notwendig, da es zwar von linux-wlan-ng, aber nicht von »Linux Zydas 1201 Driver 0.3« vorkompilierte Binärpakete für verschiedene Distributionen gibt.
7. Debian-Pakete für die Module des »Linux Zydas 1201 Driver 0.3« erstellen. checkinstall -D –pkgname=Zydas1201 –pkgversion=0.3 –pkgarch=i386 –pakdir=/var/cache/apt-build/repository/ –backup=yes make install Information: folgendes funktioniert nicht: »make-kpkg modules_image –added-modules /usr/local/src/Zydas1201-LinuxDriver-0.3/src/prism2/driver«
   Das angegebene Modul wurde im letzten Schritt ja schon konfiguriert und kompiliert, entsprechend den Vorgaben aus den Makefiles der höheren Ebenen des Verzeichnisbaums des Treibers. Compilieraufgaben bestehen jetzt also nicht mehr, das Modul sollte problemlos zu einem Debian-Paket verpackt werden.
   Beachten: Das Argument »–added-modules« bzw. »–added-modules« ist nur möglich bei den Aufrufen »make-kpkg modules«, »make-kpkg modules_config«, »make-kpkg modules_image« und »make-kpkg modules_clean«. Das wird in der Dokumentation (»man make-kpkg«, zum Argument »–added-modules foo«) leider ziemlich unverständlich geschrieben als »The argument should be a comma separated list of add-on modules (not in the main kernel tree) that you wish to build when you invoke the modules_blah targets.«.
   Das oben genannte Kommando schlägt fehl, weil das Modul kein Modul aus einem Debian-Paket ist. Es enthält deshalb nicht ein Verzeichnis ./debian/rules, was jedoch von make-kpkg erwartet wird.
   Es hilft auch nichts »Linux Zydas 1201 Driver 0.3« manuell im Verzeichnisbaum mit dem kompilierten Kernel und seinen Modulen zu installieren - es würde von make-kpkg nicht mit in das Kernel-Paket aufgenommen, da es keine Regel »install« für dieses Modul in irgendeiner Make-Datei des Kernels gibt. Das Modul ist ja kein Patch, der sich nur auf bestehende Dateien des Kernels auswirkt (und mit diesen zusammen installiert würde), sondern fügt neue Dateien hinzu.
   Man könnte also aus dem Quellcode von »Linux Zydas 1201 Driver 0.3« ein Modul im Debian-Format machen und »make-kpkg modules_image –added-modules [...]« verwenden. Das ist jedoch gegenüber der oben vorgeschlagenen Lösung die weitaus aufwändigere Variante.
8. checkinstall erstellt die neuen Pakete im aktuellen Verzeichnis. Sie können auch mit dpkg -i <paketname>.deb installiert werden, wenn die Installation innerhalb von checkinstall fehlschlägt. Evtl. ist eine nachträgliche Installation aber auch unnötig: man prüfe, ob die Module in /lib/modules/<kernelversion>/linux-wlan-ng/ installiert wurden. Bei der Kernelversion werden dabei auch die Debian Paketrevision (»-1«) und die Architektur (»-386«) mitgerechnet, wenn vorhanden.
9. Die Module einfügen: sie liegen in einem Verzeichnis passend zur Kernelversion des Kernel source tree, mit dem man »Linux Zydas 1201 Driver 0.3« kompiliert hat. Also im Verzeichnis /lib/modules/<kernelversion>/linux-wlan-ng/. Einfügen mit: depmod -a; insmod p80211.ko; insmod prism2_usb.ko;.
   Eine Fehlermeldung wie »-1 Invalid module format« entsteht dann, wenn die aktuell gebootete Kernelversion nicht zu der Kernelversion des Kernel-Sourcetrees passt, für den der Treiber kompiliert wurde. Diskrepanz in Versionen besteht schon dann, wenn Zusätze zur Kernelversion wie die Debian Revision (»-1«) oder die Architektur (»-386«) sich unterscheiden. So können Module, die für den 2.6.8 source tree kompliert wurden nicht in einen laufenden Kernel 2.6.8-1-386 eingefügt werden - es kommt dann die Fehlermeldung »-1 Invalid module format«. Parallel steht dazu in /var/log/messages: »p80211: disagrees about version of symbol struct_module; prism2_usb: disagrees about version of symbol struct_module«.
   Immer wenn in der Ausgabe von »make config« für »Linux Zydas 1201 Driver 0.3« etwas erscheint wie »The kernel source tree is version 2.6.8. [...] WARNING: the current running kernel is actually version 2.6.8-1-386«, besteht dieses Problem. »make config« kann zwar überlistet werden, indem man die Konstante in ./include/linux/version.h aus dem Kernel source tree auf die aktuell laufende Kernelversion ändert. Dieser Hack ändert jedoch nichts am eigentlichen Problem, das nicht in »make config«, sondern in den erstellten Modulen besteht (diese erfahren ihre Kernelversion nicht aus version.h!).
   Also genau den Kernel booten, für dessen source tree man »Linux Zydas 1201 Driver 0.3« kompiliert hat. Wenn man vor »make config« und nach einer Änderung der Kernelversion des installierten Kernels kein »make clean« (besser: »make mrproper«) ausgeführt hat, können diese Probleme weiterhin bestehen, da während »make config« vermerkt wird, für welche Kernelversion die Treibermodule von »Linux Zydas 1201 Driver 0.3« kompiliert werden.
   Und wenn auch jetzt nich die Fehlermeldung »-1 Invalid module format« auftritt, jedoch nicht mehr mit dem Zusatz in /var/log/messages?
   Welche Versionskonflikte hier genau bestehen, kann man in der Ausgabe von dmesg nachlesen. Hier zum Beispiel wird immer nach »insmod p80211.ko« die folgende Meldung angefügt: p80211: version magic '2.6.8 preempt 386 gcc-3.3' should be '2.6.8 586 gcc-3.3'
   »cat /proc/kmsg« während »insmod p80211.ko« zeigt, dass keine weiteren Meldungen auf niedrigeren Prioritätsstufen geschrieben werden. Die obige Meldung bedeutet: der Kernel hat Version »2.6.8 preempt 386 gcc-3.3«, das Modul erfordert aber die Version »2.6.8 586 gcc-3.3«. Achtung: dies trat auf, als die Module kompiliert wurden während der Kernel des betreffenden Kernel source trees gerade lief!
   Diese unwesentlichen Unterschiede können übergangen werden, indem man »modprobe -f <modulname>« verwendet. Das führt dann zur Meldung »p80211: no version magic, tainting kernel.« als Information.
   Das nächste Problem ist die folgende Meldung in dmesg: »p80211: Unknown symbol capable«
   Verfahren nach www.linuxforum.com/linux-kernel-modules/basekerncompat.html : Der erste Schritt ist zu bestätigen, dass das Symbol tatsächlich nicht in /proc/kallsyms vorhanden ist. Das ist hier für das Symbol »capable« der Fall. Vermutung: Der experimentelle »Module versioning support« (CONFIG_MODVERSIONS) des Kernels ist an diesem Problem schuld, weil er fälschlicherweise eine Versionierung einführt, die das Symbol »capable« für das Modul unsichtbar sein lässt. Dazu muss sowohl der Kernel als auch die Module neu kompiliert werden (also vorher make clean), denn sonst kommen für alle Module Fehlermeldungen wie »version magic: [...] should be [...]« und »Invalid module format«.
   Wenn das nicht hilft, liegt es möglicherweise daran, dass »Linux Zydas 1201 Driver 0.3« für Kernel 2.6.8 nicht geeignet ist: das Symbol »capable« gab es einmal, jetzt aber nicht mehr. In diesem Fall sollte man in den Sourcen des Moduls p80211 nach der Verwendung des Namens »capable« suchen und diese durch etwas äquivalentes, funktionierendes ersetzen. Vgl. auch sourceforge.net/forum/forum.php?thread_id=1125136&forum_id=326770 .
   Achtung: p80211.ko ist wohl ddie Basis für den Zydas-Treiber, der Treiber selbst ist jedoch nicht prism2_usb.ko, sondern zd1201.ko. Siehe sourceforge.net/forum/forum.php?thread_id=1125136&forum_id=326770 ; es kann sein, dass dieser Treiber nicht kompiliert wird und man muss ausführen:
   1. make -C /lib/modules/2.6.4/build/ SUBDIRS=/root/zd12011-0.8 modules make -C /lib/modules/2.6.4/build/ SUBDIRS=/root/zd12011-0.8 modules_install ksymoops 2.4.9 on i686 2.6.7.  Options used -v /home/pq/linux/linux-2.6.7/vmlinux (specified) -k ksyms (specified) -l proc_modules (specified) -o /lib/modules/2.6.7serial/kernel/crypto/blowfish.ko

   Diese Lösung u.a. nach: www.linuxquestions.org/questions/history/184459 .

Hilfreiche Dokumentation:

• man make-kpkg
• vi $(which make-kpkg); (es ist ein Perl-Script)

Man verwende das Howto: www.matthew.ath.cx/debian-kernel/ , um einen Kernel nach dem Vorbild der funktionierenden Debian-Kernel zu erstellen. Das oben geschilderte Problem liegt daran, dass der Kernel nicht die Funktionalität zur Verfügung hat, um auf das root Dateisystem zugreifen zu können. Im Debian-Kernel, wie er in obigem Howto erstellt wird, wird das gelöst durch eine initial Ramdisk (initrd).

Es könnte durch die GRUB-Konfigurtion (/boot/grub/menu.lst) beeinflusst sein. Anmerkung: Änderungen an dieser Datei wirken sich sofort, ohne weitere Kommandos, korrekt aus; anders als bei lilo.) Ein fehlender Parameter »initrd« dort für einen selbstkompilierten Kernel ist jedoch kein Fehler, denn üblicherweise wird die »initial ramdisk« für die zusätzlichen Module in binär verteilten Kernels verwendet. Ein selbstkompilierter Kernel braucht keine »inital ram disk«, muss dann aber alle zum Startup benötigten Modul im Kernel selbst einkompiliert haben. Module können in der ersten Startup-Phase ja nicht nachgeladen werden. Vgl. kris.koehntopp.de/inkomploehntopp/00710.html . Um den Fehler zu beheben, muss die folgende Funktionalität fest in den Kernel einkompiliert werden und darf nicht als Modul kompiliert werden:

• CONFIG_BLK_DEV_IDE
• CONFIG_BLK_DEV_IDEDISK
• CONFIG_IDE_GENERIC
• CONDIG_BLK_DEV_IDEPCI
• CONFIG_BLK_DEV_GENERIC
• CONFIG_BLK_DEV_VIA82CXXX
• CONFIG_EXT2_FS
• CONFIG_EXT3_FS
• CONFIG_DEVFS_FS
• CONFIG_DEVFS_MOUNT

Die Liste der geladenen Module eines funktionierenden Kernels mit initrd, direkt nach Systemstart, informiert darüber, welche Dinge in einem eigenen Kernel ohne initrd nicht als Modul kompiliert werden dürfen.

sd_mod ?
ata_piix ?
libata ?
capability ?
commoncap ?

Wenn der Fehler weiterhin besteht:
Wenn man in /boot/grub/menu.lst den Parameter »root=/dev/hda2« entfernt, ändert sich die Fehlermeldung von

in

unknown-block(*,*) scheint damit ein Bezeichner für ein Block-Device mit Major- und Minor-Nummern zu sein. Man erstelle eine RAMDDISK (initrd-Image) mit mkinitrd. Alles, was dem Kernel an einkompilierten Modulen fehlt, sollte er nun nachladen können.
Der Fehler scheint also an einem falschen »root=« Parameter zu liegen. Es ist auch möglich, diesen Parameter als Major- und Minor-Nummern anzugeben, etwa »root=0302« (Major 3, Minor 2). Diese Nummern erfährt man über ls -all /dev/[...], hier zum Beispiel:

Das könnte den Fehler beheben. Ansonsten wird zumindest die Fehlermeldung anders:

Man sollte ausprobieren, ob der Fehler verschwindet, wenn man (bei i386-Architektur) die Default-Konfigurationsdatei für diese Architektur verwendet, die dem Kernel Source Tree beiliegt: ./arch/i386/defconfig. Man kann auch verschiedene Konfigurationsdateien aus dem Internet probieren: in einem Beitrag zum Thread seclists.org/lists/linux-kernel/2004/Sep/0063.html werden zwei als Attachments angeboten.
In diesem Fall funktionierte der standardmäßig von Debian installierte Kernel (aus der binary-Distribution). Damit sollte es möglich sein, einfach die Konfiguration dieses Kernels zu übernehmen. Sie liegt in /boot/config-<version>.
Zusätzlich muss natürlich ein initrd-image generiert werden. Dazu kann man das initrd-image des laufenden Kernels mounten und prüfen, welche Module dort enthalten sind:

Die so gefundenen Module trägt man dann ein in /etc/mkinitrd/modules. Evtl. ist das bei weitem nicht ausreichend, weil das initrd-Image des laufenden Kernels noch Bibliotheken und weitere Dinge enthält. Stattdessen geht man dann einen anderen Weg:
Eventuell ist es auch möglich, das vorhandene initrd-Image des laufenden Kernels wiederzuverwenden. Dazu ist es nötig, dass der neu kompilierte Kernel genau dieselbe Version hat. Das kann gewährleistet werden, indem man in ./Makefile im Kernel source tree unter »EXTRAVERSION =« die entsprechenden Versionszusätze (z.B. »-1-386«) des laufenden Kernels einträgt. Außerdem muss eine Zeile mit diesen Zusätzen in ./debian/changelog (im Kernel source tree) als oberste Zeile eingefügt werden. Weiterhin muss unter dieser Zeile ein Dummy-Eintrag entsprechend den anderen Einträgen im changelog eingefügt werden, ansonsten schlägt make-kpkg fehl. Weiterhin müssen in ./debian/control (im Kernel source tree) entsprechende Einträge für die neue Kernelversion erzeugt werden. So kann tatsächlich ein .deb-Paket mit dem Kernel in der entsprechenden Version erzeugt werden. Versionsdiskrepanzen führen dazu, dass Module wiederum nicht eingefügt werden können. Bevor man den Kernel deinstalliert, den man durch den selbstkompilierten Kernel ersetzen will, kopiert man sich dann noch dessen initrd-Image, so dass es nicht mit gelöscht wird: /boot/initrd.img-2.6.8-1-386 .
Nun muss zusätzlich in /boot/grub/menu.lst eingetragen werden, dass der neue Kernel das initrd-Image auch verwenden soll (die Debian-Kernel-Installation weiß ja nichts von einem initrd-Image, das man zusätzlich bereitstellen will!).

Mit diesem Verfahren kommt man zwar soweit, dass die initial Ramdisk verwendet wird. Jedoch werden dort die Module nicht gefunden, denn der Kernel meint selbst noch, er sei »2.6.8«, nicht »2.6.8-1-386«. Also: die initial Ramdisk ändern. Mit

ist das jedoch nicht möglich, da man in ein per loopback gemountetes Image anscheinend nicht schreiben kann. Andernfalls hätte man das Image ja problemlos auch auf jede beliebige selbstkompilierte Kernelversion anpassen können, auch auf »2.6.8«, und es wäre gar nicht notwendig gewesen, zu versuchen, einen Kernel »2.6.8-1-386« zu kompilieren.

Änderungen werden grundsätzlich nur bei einem Neustart des X-Servers übernommen. »Beenden« in KDE führt nicht zu einem solchen Neustart, wenn danach wieder die Aufforderung zum grafischen Login erscheint. Ein Neustart des X-Servers kann jedoch mit Strg+Alt+Backspace erzwungen werden.

1. Auf das gewünschte Release von Debian wechseln.
2. Gewünschtes Paket mit den Kernel-Quellen herunterladen.
3. Die Patches, wenn sie nicht als deb kommen, normal einspielen mit dem patch Programm (z.b. cd
   linux; patch -p1 -i ../patch.diff).
4. Mit make menuconfig die korrekten Optionen für den Kernel setzen.
5. Den neuen Kernel bauen mit »make-kpkg kernel-image«.
6. In /usr/src/ ist dann der Kernel als Debian-Paket vorhanden (.deb), installieren mit
   »dpkg -i kernelname.deb«.

Üblicherweise werden etwa 6GB für Programme benötigt; 10GB reichen also gut aus. Wenn man VMware nutzt sollte man 4-5 GB zus. einplanen pro virtueller Maschine.