Debian Woody auf dem Asus P4P-800
Weil der mit Woody mitgelieferte Kernel 2.4.18 keinen SATA-Treiber enthält, ist die Installation auf einer per SATA am Asus P4P800 angeschlossenen Platte nicht ohne weiteres möglich. Aber es geht.
Bei der Installation bin ich vor allem auf zwei Probleme gestoßen:
- das auf Intels ICH5R basierende RAID läßt sich nach aktuellem Stand nicht nutzen (dennoch läßt sich – einen aktuellen Kernel vorausgesetzt, zumindest SATA auf Umwegen in Betrieb nehmen)
- die auf dem Board integrierte 3Com Netzwerkkarte 3c940 funktioniert mit dem bei Asus erhältlichen Treiber vom August 2003 nicht sauber, denn einzelne Seiten (bspw. www.google.com, www.amazon.com, www.intel.com) lassen sich nicht ansurfen. Ausserdem berichten Anwender von Problemen bei SSH und VNC.
Die gleichfalls auf dem Board integrierte Soundkarte habe ich nicht in Betrieb genommen, weshalb Sie in diesem Dokument nicht berücksichtigt wird.
Sicherlich finden erfahrenere Anwender elegantere Alternativen zu den im folgenden vorgestellten Lösungen. Aber zumindest habe ich so ein lauffähiges System hinbekommen.
Im Prinzip beruht alles darauf, dass man zunächst eine IDE-Festplatte anklemmt und auf dieser installiert. Dort wird ein Kernel gebaut, der über SATA-Treiber verfügt und der im zweiten Schritt auf eine Installation auf der SATA-Platte übertragen wird.
System
- P4P800 (BIOS 1014) mit P4 2,6 GHZ HT
- 2*Maxtor SATA-Platte 120 GB
- IDE-DVD-Laufwerk als Master am sekundären IDE
- zur Installation ausserdem temporär eine IDE-HD als Master am primären IDE
Zunächst schaltet man im Bios die SATA-Platten ab (der Eintrag findet sich auf der ersten Bios Seite und hieß glaube ich “IDE Configuration” o.ä.)
Die Installation beginnt mit der 1. Woody-CD, wobei über den Parameter “bf24″ direkt mit Kernel 2.4.18 auf /dev/hda, also die IDE-Platte installiert wird. Die Partitionierung kann nach Belieben erfolgen und muss noch nicht mit der für das eigentliche System übereinstimmen.
Nachdem die Installation vollendet ist übernimmt man die CD als Quelle für die weitere Installation und zieht per apt-get install einige Pakete nach. Auf einer anderen Seite fand ich folgende Liste, an der ich mich orientiert habe:
- gcc, libc5-dev/libc6-dev, binutils, make, (for x86)bin86
- bzip2, libncurses5-dev
Zusätzlich habe ich die Kernel-Sourcen für den 2.4.18er Kernel (apt-get install kernel-source-2.4.18) und das Kernel-Package (via dselect) installiert.
Außerdem besorgt man sich den 3Com-Treiber von der Asus-Website. Der funktioniert zwar nicht richtig. Aber er läßt sich mit dem 2.4.18er Kernel kompilieren und dient dazu, weitere Packages und Updates per apt-get install herunteralden zu können, die sich nicht auf der CD finden.
Des weiteren benötigt man noch den Netzwerkkarten-Treiber, den Syskonnekt, der Hersteller des Chips produziert, auf dem die 3com Netzwerkkarte basiert (“Kernel 2.4.13 and above”).
Die beiden Treiber-Pakete packt man bspw. nach /usr/src aus. Dort findet sich auch das bz2-File in dem die Kernel-Sourcen enthalten sind. Man entpackt es ebenfalls (und auch das darin enthaltene .tar) und erzeugt einen symbolischen Link namens “linux” unter /usr/src, der auf das Verzeichnis zeigt.
Was mir noch etwas schleierhaft blieb: unterhalb von /usr/src/include/linux scheinen dem 3Com-Treiber Dateien zu fehlen (insbesondere die version.h), die diesen am Kompilieren hindern. Ich hatte dann versucht, den Syskonnekt-Treiber zu bauern. Dieser bemängelt fehlende Symbole im 2.4.18er Kernel und bricht ab, nicht ohne allerdings vorher die fehlenden Dateien selbst zu erzeugen. Mein Fazit: erst die erfolglose Installation von Syskonnekt starten, anschließend kompiliert der 3Com-Treiber sauber durch. Sollte der anschließende insmod 3c2000 mit der Meldung fehlschlagen, dass das Modul für einen anderen Kernel (2.4.18 statt 2.4.18-bf24) gebaut wurde, dann ändert man einfach den entsprechenden String in der version.h.
Ist das Modul sauber geladen, dann muss unter /etc/network/interfaces ein Eintrag für die neue Netzwerkkarte erzeugt werden. Zunächst mit
ifconfig -a
überprüfen, ob die Karte als eth0 oder eth1 erzeugt wurde. Dann zugehörig einen Eintrag in der interfaces-Datei erzeugen, bspw.
auto eth0
iface eth0 inet dhcp
Die mit “auto” beginnende Zeile sagt Debian, dass die Karte schon beim Booten des Systems konfiguriert werden soll. In der zweiten Zeile steht, dass die Karte mit TCP/IP betrieben (“inet”) und via DHCP konfiguriert wird.
Nun “ifup eth0″ bzw. eth1 eingeben und die Karte sollte starten. Wer mag kann nun sein Debian via Internet aktualisieren. Eine passende sources.list findet sich im auch ansonsten sehr lesenswerten “Apt-Pinning for beginners”.
Deutlich länger hat es gedauert, bis ich einen ordentlichen Kernel laufen hatte. Nach mehreren Versuchen mit den Sourcen des 2.4.22 aus dem Debian-Repository habe ich einen 2.4.22 direkt von ftp.kernel.org gezogen und diesen mit zwei Patches, darunter der sata-treiber, gepatched:
http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.22.tar.bz2
http://ftp.linux.hr/pub/linux/kernel/people/jgarzik/libata/2.4.22-bk53-libata1.patch.bz2
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/snapshots/old/patch-2.4.22-bk53.bz2
Man entpackt die Kernel-Sourcen wieder unterhalb von /usr/src und setzt anschließend den linux-Link entsprechend. Dann wechselt man in das Verzeichnis und patched die ebenfalls ausgepackten Patches mit
patch -p1 < patchname
wobei zuerst der bk53 eingepflegt wird.
Anschließend konfiguriert man den Kernel mit
make menuconfig
(oder dem schlichteren make config)
Dabei nicht vergessen, SATA (bei der SCSI-Unterstützung) zu aktivieren. Was ich im Moment nicht mehr klären kann ist das Schicksal der Netzwerkkarte. Im Laufe meiner Basteileien hab ich mitten in der Nacht ziemlich oft neu kompiliert und weiß nicht mehr, ob der Netzwerkkarten-Treiber nun direkt zum Kernel gehört oder ob die entsprechende Option irgendwann dadurch in den Kernel-Configs landete, weil ich noch mal das install.sh des Skykonnekt-Treibers aktivierte. Auf jeden Fall sollte Skykonnekt unter dem in der Doku zum Treiber angegebenen Namen (fing mit “M” an, bin aber gerade zu faul zum raussuchen) als mögliches Modul auftauchen und direkt mit dem Kernel zusammen kompiliert werden.
Das Kompilieren des Kernels habe ich analog der verlinkten Anleitung vorgenommen, also nacheinander
make dep
make clean
make bzImage
make modules
make modules_install
absetzen, was je nach Rechnergeschwindigkeit unterschiedlich viel Zeit in Anspruch nimmt. Anschließend kopiert man das bzImage von /usr/src/linux/arch/i386/boot/ nach /boot/vmlinuz-2.4.22 und die System.map von /usr/src/linux nach /boot/System.map-2.4.22.
Den bereits im Root-Laufwerk liegenden Link vmlinuz verschiebt man nach vmlinuz.old und passt den Bootloader lilo an. Der bisherige Boot-Eintrag zeigt auf die vmlinuz.old und zusätzlich fügt man einen neuen Abschnitt ein der das neue Kernel-Image startet. man lilo hilft im Zweifel über alle Fragen hinweg. Nicht vergessen, dass man nach dem Bearbeiten der lilo.conf noch mal “lilo” starten muss um die Änderungen auf die Platte zu schreiben.
Man startet neu und stellt bei dieser Gelegenheit das Bios um. Das Bios kennt zwei verschiedene Möglichkeiten, den Enhanced Mode und den Compatibility Mode. Interessanterweise werden dann alle Laufwerke (sowohl die beiden SATAs wie auch die IDE-Laufwerke an beiden Controllern) erkannt, wenn man auf “Enhanced Mode” und “SATA only” stellt.
Nun schaut man sich die Ausgaben von dmesg und /var/log/daemon.log an. Fehlermeldungen googelt man am besten um zu erfahren, ob sie ggf. aus fehlenden Kernel-Bestandteilen o.ä. bestehen. Auch sollte man mal überprüfen, ob die Netzwerkkarte wieder angesprungen ist.
Als nächstes geht es an die Einrichtung des Systems auf der SATA-Platte. Dazu besorgt man sich mit
apt-get install debootstrap
das genannte Programm. Außerdem partitioniert man die SATA-Platte mit fdisk und legt mit mkfs.ext3, mkswap etc. anschließend die Dateisysteme auf den Partitionen an.
Unter /mnt/target erzeugt man einen Mountpoint für die auf der SATA-Platte erzeugte Root-Partition und mountet diese dort hin. Mit
debootstrap --arch i386 woody /mnt/target http://http.us.debian.org/debian
landet ein taufrischer Woody auf der SATA-Platte.
Mit
chroot /mnt/target /bin/bash
macht man das neue Root-Laufwerk temporär zum Root und legt unterhalb von /etc/fstab (relativ zum Hostsystem liegt diese Datei natürlich unter /mnt/target/etc/fstab) eine neue fstab-Datei an und trägt die zuvor auf der SATA-Platte erzeugten Partitionen, Floppy, DVD-Laufwerk etc. manuell ein. man fstab und ein Blick in die fstab auf dem Hostsystem (über eine zweite Konsole) helfen bei Problemen. Viel Ärger hatte es mir erspart, wenn ich auch gleich an den Eintrag für das /proc-Verzeichnis gedacht hätte.
Per
mount -a
hängt man die in der fstab-Datei eingetragenen Partitionen ein und ruft /usr/sbin/base-config auf um die Grundkonfiguration vorzunehmen. Außerdem wollen auch /etc/network/interfaces, /etc/resolv.conf, /etc/hosts und /etc/hostname angepasst sein. Ggf. übernimmt man sie einfach aus dem Host-System. Genauso bin ich auch mit /etc/apt/sources.list verfahren.
Schließlich habe ich das Verzeichnis mit den bereits konfigurierten Kernel-Sourcen und den zugehörigen linux-Link vom Host-System aus nach /mnt/target/usr/src kopiert, sowie das bzImage und die SystemMap nach /mnt/target/boot und die lilo.conf nach /mnt/target/etc.
Das Anpassen der lilo.conf war recht zeitintensiv und nach langem ausprobieren (war schon spät in der Nacht bzw. früh am Morgen) kann ich mir nicht recht erklären warum es jetzt so funktioniert wie es funktioniert. Bei Problemen sucht man am besten mal nach “lilo mapping”, bevor ich hier mit Vermutungen und falschen Erklärungen was verbeutele 
Upgedated wird lilo mit /sbin/lilo.
Beim anschließenden Neustart stellt man im Bios als erstes Boot-Laufwerk die SATA-Platte ein und kann das temporär angeklemmte IDE-Laufwerk entfernen. Ich habe noch einige Zeit verbracht, bis das neue System ohne Fehlermeldungen startet (proc-Eintrag in der fstab hatte gefehlt, pcmcia-cardservices suchten nach im selbst gebauten Kernel nicht vorhandenen Modulen etc.). Aber seither läufts recht gut.