HomeMapIndexSearchNewsArchivesLinksabout LF
[Top Bar]
[Bottom Bar]
[Photo of the Author]
Serge Winitzki

Inhalt

GNU/Linux auf einem Fujitsu 635T Laptop

[Ilustration]

Zusammenfassung:

Dieser Artikel beschreibt die Neuinstallation des GNU/Linux Betriebssystems auf einem Laptop. Er möge als Informationsquelle für alle dienen, die Linux auf einem ähnlichen Laptop oder sogar auf einem Desktoprechner installieren wollen. Möglicherweise ist er auch für die Entwickler von Linux Distributionen nützlich. Dies ist eine sehr technische Beschreibung, der Leser sollte deshalb einigermaßen mit dem UNIX Betriebssystem vertraut oder aber zumindest bereit sein, etwas darüber zu lernen.


Einführung

Dies war das zweite Mal, daß ich Linux auf einem Laptop installierte. Die ersten Erfahrungen sammelte ich mit einem LapNote P150, eine weitergehende Beschreibung darüber ist hier zu finden. Als Informationsquellen nutzte ich verschiendene HOWTOs und die Linux Installation Guide version 3.2 von den Slackware 3.5 CD Roms. Nicht zuletzt half mir auch die Linux on Laptops web page. Die folgenden Beschreibungen beziehen sich speziell auf die Installation der Slackware 3.5 auf dem Fujitsu 635T Laptop. Es werden keine WWW Verweise in Bezug auf irgendwelche speziellen Programme genannt, ich gehe davon aus, daß der interessierte Leser in der Lage sein wird, sie mittels der unten angegebenen WWW Seiten zu finden.

Erste Schritte in Richtung Installation

Ich kaufte mir einen gebrauchten Laptop, einen Fujitsu 635T, via E-Mail. Wie erwartet war das sogenannte Betriebssystem "Windows" in der Version "95 OSR 2" installiert. Möglicherweise war diese Installation eine Neuinstallation, durchgeführt von dem früheren Besitzers des Laptops, bevor er es an mich weiterverkaufte. Die Soundkarte war nicht erkannt worden, genausowenig wie das komplette PCMCIA System. Ich kann mich jetzt nicht mehr daran erinnern, ob die True-Color Darstellung eingeschaltet war. Ebensowenig wagte ich es, die "Suspend to disk" Option zu testen, da keine entsprechende Partition auf der Festplatte existierte und ich davon ausging, daß es nicht funktionieren würde und stattdessen die existierende Partition beschädigt werden könnte (Meine Befürchtungen waren unbegründet: das BIOS erkannte, daß eine Suspend-to-disk Partition fehlte und gab eine entsprechende Warnung aus, sobald ich versuchte, die Option einzuschalten).

Mir war klar, daß es nicht klug wäre, der Versuchung zu erliegen und "Windows" sofort zu löschen. Vielmehr brauchte ich es, um einige Informationen zu erhalten. Zuerst installierte ich den Druckertreiber für einen Standard Textdrucker und druckte über die Systemeinstellungen alle Einstellungen in einer Datei aus. Diese Daten würden später möglicherweise nützlich sein. Diese Datei mag das einzig Nützliche sein, was man diesem sogenannten Betriebssystem abgewinnen kann, vor allem, da der Rechner ohne Handbücher mitkam. Eigentlich sollten alle notwendigen Informationen in der Dokumentation der Hardware zu finden sein, allerdings ist es heutzutage gängige Marketingpraxis, davon auszugehen, daß die Installation von "Windows" gleichwertig mit irgendeiner Art Hardwaredokumentation sei. In der Hauptsache bekommt man eine wahrscheinlich sauber installierte Version von "Windows". Diese dient dann dazu, Informationen über das System zu erlangen.

Nachdem die Datei mit den Hardwareinformationen auf Diskette überspielt worden war, bootete ich neu und ging in das BIOS Setup. Das BIOS war recht ansprechend und erlaubte die Kontrolle
Ich beschloß schließlich, nicht mehr mit diesem sogenannten Betriebssystem herumzuspielen
über eine Reihe interessanter Einstellungen, wie zum Beispiel Port Adressen und Interrupts der seriellen Schnittstellen und der Soundkarte sowie des Parallelportes, des Power Managements und mehr.
Außerdem gab es zwei Betriebsmodi des PCMCIA Systemes: der "CardBus" und der sogenannten "PCIC compatible" Modus..."Windows" erkannte das PCMCIA System im "PCIC", jedoch nicht im "CardBus" Modus (wie ich später herausfand, werden beide Modi gleich gut von Linux unterstützt). Das Power Management wurde ebenso nicht von "Windows" unterstützt, der "Undock" Button, laut Dokumentation der Dockingstation sollte er sichtbar sein, konnte auch nicht gefunden werden. Danach beschloß ich, nicht weiter mit diesem sogenannten Betriebssystem herumzuspielen. Jedoch konnte ich es noch nicht löschen, da ich es noch für das Erstellen der Bootdiskette brauchte, um Linux zu booten.

Der erste Schritt bestand also darin herauszufinden, wie die Linux Bootdisketten erstellt wurden. Ich hatte bereits die Slackware Linux 3.5 Distribution heruntergeladen und die Dateien README, INSTALL, usw. durchgelesen. Entsprechend der vorgeschlagenen Vorgehensweise benutzte ich das DOS Programm rawrite.exe, das mit Slackware mitkommt und gebraucht wird, um die Images für die Bootdisketten auf die Datenträger zu überspielen. Der Befehl lautet so ähnlich wie: rawrite.exe bare.i a:, ausgeführt im Verzeichnis bootdsks.144 der Slackware CD Rom. Daduch wird eine Bootdiskette mit dem einfachsten (bare) Kernel erzeugt. Der Befehl rawrite.exe color.gz a: im Verzeichnis rootdisk erzeugt die "rootdisk" Diskette, die ebenso für den Start der Slackware Installation notwendig ist. Später fand ich dann heraus, daß ich die bareapm.i Startdiskette hätte nehmen sollen, da der Laptop über Stromsparfunktionen ("Advance Power Management", APM) verfügt und ich sie direkt bei der ersten Installation hätte nutzen können, zum Beispiel hätte ich der Laptop mitten in der Installation herunterfahren und später dann die Installation fortsetzen können. Allerdings wollte ich am Anfang nur den einfachsten Kernel benutzen. Leider stürtzte einen Kernel ohne APM merkwürdigerweise manchmal ab, wenn ich den Laptop für eine Stunde allein ließ und er automatisch herunterfuhr. Typischerweise weigerten sich die unterschiedlichsten Programme, zu starten und lieferten eine "Division durch Null" ("zero divide") CPU Fehlermeldung, wobei die Prozessorregister ausgegeben wurden. Diese Probleme verschwanden, sobald ich den APM unterstützenden Kernel benutzte.

Linux total

Nachdem die beiden Disketten erstellt worden waren, bootete ich den Rechner neu und bekam ein Linux System, in das ich mich als "root" (ohne Passwort) einloggen konnte. Danach wurde ich informiert, daß ich nun einige Festplattenpartitionen für Linux erstellen und danach das setup Programm ausführen müßte. Selbige Nachricht erläuterte mir, daß ich entweder fdisk oder cfdisk für die Partitionierung benutzen könne. Da ich schon wußte, daß fdisk nicht allzu komfortabel in der Benutzung ist, entschied ich mich, cfdisk auszuprobieren und war angenehm überrascht, wie einfach und intuitiv das textbasierte Progamm war. Ich löschte die einzelne 1,35 Gigabyte große FAT Partition (adios, "Windows"!), legte eine 64 MB Swap Partition und zwei (300 MB und 1 GB) Linuxpartitionen vom Typ ext2 an. Die Idee war, die kleinere Partition für Systemdateien und die große Partition für Benutzerdateien und Programme zu verwenden, sodaß ich nicht alles wieder löschen müßte, falls ich mich später entscheiden würde, Linux neu zu installieren.

Nachdem ich cfdisk beendet hatte, rief ich das setup Programm auf. Die ersten Schritte des Installationsprogrammes waren klar: Änderung der Tastaturbelegung (wollte ich nicht), Auswahl des Swap Speichers, sowie der Quell- und Zielverzeichnisse. Ich wählte die kleinere Partition als root Partition aus (/), die große Partition sollte als /usr eingebunden werden. Das erste Problem tauchte bei dem Quellverzeichnis auf: Ich besaß keine original Slackware CD Rom, sondern hatte alle Dateien runtergeladen und unter "Windows" auf CD gebrannt. Trotz mehrmaliger Versuche fand setup die Verzeichnisse nicht,
Um dieses Problem zu lösen, drückte ich Ctrl-Alt-F2
die ich als Verzeichnisse angegeben hatte, die die Slackware Distribution beinhalteten. Das Problem war, daß ich diese Dateien unter einem DOS Dateisystem anlegte, welches die Dateinamen irregulär erweitert hatte, z.B. "README." statt "readme". Dadurch hatte setup offensichtlich Probleme (solche Probleme hatte ich nicht mit der richtigen Slackware 3.5 CD Rom, die ich ein paar Tage später per Post bekam). Um das Problem zu lösen, drückte ich Ctrl-Alt-F2. Wie mir schon durch frühere Erfahrungen mit Linux bekannt war, wird mit Ctrl-Alt-F1 bis F6 im Textmodus zwischen den virtuellen Konsolen gewechselt. Ich bekam so eine andere Eingabeaufforderung und loggte mich wieder als root ohne Passwort ein. Eine zweite Konsole zu haben, war ein echter Segen: praktische Programme wie mount, ls, and cat waren über diese Eingabeaufforderung verfügbar und ich konnte so die CD mounten (durch die Bootinformationen der Slackware wußte ich, daß das CD Rom Laufwerk auf /dev/hdc lag, deswegen sah die Abfolge der Befehle zum Einbinden des Laufwerkes wie folgt aus: mkdir /cdrom; mount /dev/hdc /cdrom), die Slackware Dateien von CD auf eine der Linux Paatitionen kopieren und die Dateien, die mit einem Punkt endeten, umbenennen (Eine andere Möeglichkeit wäre gewesen, das ZIP Laufwerk für den Zugriff auf die Installationsdateien zu nutzen, jedoch wird es nicht vom bare Kernel unterstützt. Außerdem fand ich später heraus, daß die Treiber für die ZIP Laufwerke am Parallelport nicht auf meinem Rechner laufen, dazu nachher mehr). Danach wies ich das Setup Programm an, die Dateien eines bereits eingebunden Verzeichnisses zu benutzen. Nun war Slackware in der Lage, die Installationsdateien zu finden. Durch die Möglichkeit, die Konsolen zu wechseln, konnte ich ebenfalls die Slackware CD mit  den Dateien zur Dokumentation mounten und die verschiedenen README und HOWTO Dateien, sowie natürlich auch den Installation Guide während der Installation lesen. Es war wirklich hilfreich, Probleme mit dem System während seiner Installation direkt beheben zu können. Ich konnte jederzeit sehen, welche Dateisysteme eingebunden waren (cat /etc/mtab), sie mounten oder unmounten, wenn es notwendig war (z.B. mount -t ext2 /dev/hda3 /mnt/usr), oder beliebige Änderungen an der Lage von Dateien vornehmen. Ich konnte mich ebenso parallel einloggen und Änderungen am System, sowie den Fortschritt während der Installation beobachten. Alles in allem wurde so die Installation wesentlich komfortabler, da ich nicht total der Gnade des Installationsskriptes ausgeliefert war.

Als nächstes mußten die Softwarepakete, die installiert werden sollten, ausgewählt werden. Ich entschied mich für alle Pakete, außer den Spielen, der X Server Entwicklungssoftware und der Dokumentation, die ja sowieso auf CD Rom war. Danach konnte ich durch das Setup Programm die Festplatte mittels des Lilo Boot Managers bootfähig machen. Ich wählte die automatische Lilo Installation aus, wobei der bareapm.i Kernel benutzt wurde. Die Netzwerk Konfiguration ließ ich aus, verzichtete auf die Wahl einer anderen Schriftart, teilte dem System mit, daß mein Modem auf COM2 lag und die Maus ein PS/2 Gerät war und suchte mir für die Zeitzone die von Amsterdam aus (Warum funktionierte eigentlich PageDown nicht? Man hätte so schneller durch die recht große Liste von Zeitzonen durchscrollen können...). Zum Schluß bootete ich den Rechner neu, das System fuhr erfolgreich hoch. Ich loggte mich wieder als root ohne Passwort ein und war bereit für alle Schandtaten, mit der Rechnerleistung von ca. 53 "BogoMips". Dieser Wert stimmt ungefähr für einen Pentium 133 Mhz (wie in der "BogoMips mini-HowTo" nachzulesen ist).

Einziger Wermutstropfen bisher war die fehlende Unterstützung für das ZIP Laufwerk am Parallelport. Der Treiber (ppa, parallel port adapter) meldete im Endeffekt, daß
Der neue Treiber, "Curtain" Version 1.42, fand automatisch alles über den Parallelport heraus und nutzte den schnelleren Zugriffsmodus meines ECP Parallelportes.
kein Parallelport unter Adresse 0x278 zu finden war (Die eigentliche Meldung war jedoch etwas schwer verständlich, modprobe ppa meldete etwas in der Art von "init_module: device or resource busy" als erste Zeile der Fehlermeldung). Ich bootete neu und ging in das BIOS Setup: Der Parallelport bekam hier die Adresse 0x378 zugewiesen. Hm, vielleicht wollte Linux den Port ja unbedingt auf 0x278 haben? Also änderte ich die Adresse auf 0x278, setzte für alle Fälle den Betriebsmodus des Parallelportes auf einfach bi-direktional und bootete neu. Diesmal jedoch meldete ppa, daß er mein ZIP Laufwerk nicht unter Adresse 0x378 finden könne. Langsam schien sich das Ganze zu einem Katz-und-Maus Spiel zu entwickeln. Warum wurde der Port nicht korrekt erkannt ? Das Problem verschwand jedoch, nachdem ich eine neuere Version des Treibers für das Parallelport ZIP kompiliert hatte (für weitere Informationen sollte man einen Blick auf die Linux Laptop web page werfen). Der neue Treiber, "Curtin" Version 1.42, fand automatisch alles über den Parallelport heraus und nutzte den schnelleren Zugriffsmodus meines ECP Parallelportes.

Weiter gings. Zuerst modifizierte ich die Lilo Konfigurationsdatei per Hand, fand allerdings später heraus, daß liloconfig narrensicherer war, vorallem, da ich im allgemeinen vergesse, lilo aufzurufen, nachdem ich die Konfigurationsdatei geändert habe.

Noch zu erwähnen wären die Fehlermeldungen, die manchmal nach der Durchführung einiger Funktionen des Setup Programmes auftraten. Dummerweise verschwanden sie sofort wieder, sobald der nächste Bildschirm angezeigt wurde. Es wäre wünschenswert, daß diese Fehlermeldungen weiterhin verfügbar sind, damit man überprüfen kann, ob die Operationen des Setup Programmes erfolgreich waren oder scheiterten. Dies würde wohl mehr Aufwand für die Shellskripte bedeuteten, der sich aber in Grenzen halten dürfte. Zumindest die Ausgabe der aufgerufenen Befehle könnte umgeleitet und später bei Bedarf angezeigt werden. Hallo, Herr Volkerding, können sich mich hören ?

Die Grafikkonfiguration

Erste größere Probleme tauchten bei der Konfiguration des X Window Systemes und dem Versuch es mit meiner Grafikkarte und dem 800x600 LCD Bildschirm zum Laufen zu bewegen auf. Allerdings war die Aktion selbst weniger nervenaufreibend, praktisch funktionierte es auf Anhieb, lediglich die Truecolor Darstellung erforderte einige Kniffe.

Mit der Slackware Linux Distribution kommt XFree86 mit, ein kostenloser, qualitativ hochwertiger X Server, von dem es hieß, er unterstützte meinen Grafikchip komplett. Ich überlegte mir, Accelerated X zu installieren, entschied ich mich dann jedoch dagegen, da XFree86 besser zu konfigurieren ist und ich schon vorher gute Erfahrungen mit diesem Server auf einem weniger gut unterstützten Laptop gemacht hatte. Es gab prinzipiell zwei Möglichkeiten, XFree86 zu konfigurieren: das X basierte Setup Programm und das textbasierte Konfigurationsprogramm. Da die einzige Maus, die ich hatte, das etwas abgenutzte und unhandliche Touchpad war, entschied ich mich für die Konfiguration im Textmodus (Das Programm sah nicht gerade umwerfend aus, war aber geradlinig). Später fand ich dann heraus, daß das grafische Setup Programm sowieso nicht zu diesem Zeitpunkt funktioniert hätte, da es nicht mit gpm, dem Maustreiber für den Textmodus, den ich installiert und aktiviert hatte, zusammenarbeitete. Mittels gpm -k den Treiber zu deaktivieren hätte zwar geholfen, jedoch ist das grafische Konfigurationsprogramm nicht wirklich hilfreich und es benötigt eine Maus.

Die Grafikkarte, eine C&T 65550 mit 2MB RAM, war in der Liste der bekannten Karten zu finden. Ich wählte den 800x600 Darstellungsmodus in allen Farbtiefen aus. Der einzige Schönheitsfehler trat auf dem halben Weg durch das Setup auf, als mir angeboten wurde, X mit der Option -probeonly laufen zu lassen, damit die möglichen Bildschirmmodi herausgefunden werden könnten. Allerdings scheiterte dies, da zu diesem Zeitpunkt noch Daten in der Konfigurationsdatei fehlten. Deswegen übersprang ich diesen Schritt und fuhr mit den folgenden Punkten fort. Ich lies die Eingabemöglichkeit der spezifischen Monitordaten (wie z.B. horizontale und vertikale Bildwiederholfrequenzen) links liegen. Frühere Erfahrungen lehrten mich, daß diese Informationen weder notwendig noch für eine erfolgreiche Konfiguration ausreichend sind.
Meist findet man in dieser Datei (XF86Config) viel Müll, der automatisch durch das Konfigurationsprogramm erzeugt wird.
Ich entschied mich einfach für den allgemeinen SVGA Multisync Monitor (warum waren keine Laptop Bildschirme aufgeführt?).

Nachdem alles konfiguriert worden war, warf ich einen Blick auf die Konfigurationsdatei für die Grafikhardware, /etc/X11/XF86Config. Meist findet man in dieser Datei viel Müll, der automatisch durch das Konfigurationsprogramm erzeugt wird. Am wichtigsten in Bezug auf die Hardware sind die sogenannten "Modelines". Jeder dieser Einträge beschreibt einen bestimmten Bildschirmmodus mit der jeweiligen Auflösung, Wiederholfrequenzen und mehr. Jeder Modus hat eine eigene Bezeichnung. Diese wird später für die Identifikation der vom Server tatsächlich benutzten Modi gebraucht. In dem Screen Abschnitt der Datei wird angegeben, welcher Modus mit welcher Farbtiefe laufen soll. Haben verschiedene Modi die gleiche Bezeichnung, so wählt der Server denjenigen mit der "besten" Bildwiederholfrequenz und somit besten Bildqualität aus. Durch meine früheren Erfahrungen mit der Konfiguration des XFree86 Servers kannte ich bereits das Hauptproblem der automatischen Konfiguration: Es werden vielzuviele Einträge mit derselben Auflösung und demselben Namen (wie z.B. 640x480 oder 800x600) in die Datei geschrieben, der Server darf sich dann die "beste" Modeline für den gegebenen Monitor heraussuchen. Allerdings konnnten nur einige Modi mit der Bezeichnung 800x600 wirklich laufen. Was nun praktisch passiert, ist, daß der Server sich den besten Eintrag heraussucht. Sollte dieser aber aus irgendeinem Grund nicht funktonieren, ist der Benutzer aufgeschmissen. Deswegen ist es besser, den Modi unterschiedliche Namen zu geben, wie 800x600a, 800x600b und so fort, Dadurch benutzt der Server sie alle. Der Benutzer kann dann unter X mittels Ctrl Alt + und Ctrl Alt - zwischen allen verfügbaren Modi wechseln und sich denjenigen aussuchen, der ihm am besten gefällt.

Ich löschte also alle Einträge bis auf die 800x600er, gab ihnen andere Namen und fügte sie alle in die Screen Sektion der Datei ein. Dann tippte ich startx für den Start des X Window Systems ein. Die beste Modeline war:

# 800x600 @ 60 Hz, 37.8 kHz hsync
Modeline "800x600a" 40 800 840 968 1056 600 601 605 628 +hsync +vsync
Ein ähnlicher Modus lief mit 56 Hz und lieferte fast die gleiche Bildqualität. Ich bekam direkt ein recht gutes Bild in voller Auflösung. Allerdings war kein Windowmanager sichtbar. Auch funktionierte der Truecolor Bildschirmmodus überhaupt nicht (Der Modus wird mit startx -- -bpp 24 aufgerufen, da der richtige Truecolor Modus bei diesem Chip mit 24 Bit, und nicht mit 32 Bit pro Pixel läuft. Die X Konfiguration ignoriert korrekterweise die 32 Bit Einstellungen im Screen Abschnitt und benutzt zugleich eine standardmäßige Farbtiefe von 8 Bit). Ich startete X, wobei die Ausgabe umgeleitet wurde (startx >& /tmp/startx-output) und schaute mir dann das Ergebnis in der Datei an. Diese Technik ist recht hilfreich bei der Untersuchung von Problemen bei der X Konfiguration, da normalerweise die Meldungen zu schnell durchscrollen.
Daß der Windowmananger nicht sichtbar war, lag an der Tatsache, daß die DISPLAY Variable nicht gesetzt war, warum ist allerdings unklar.

Daß der Windowmanager nicht sichtbar war, lag an der Tatsache, daß die DISPLAY Variable nicht gesetzt worden war, warum ist allerdings unklar. Diese Umgebungsvariable wird von allen X basierten Programmen benötigt, damit diese wissen, wo sie ihre Fenster anzeigen sollen. Ich behob das Problem, indem ich das startx Skript entsprechend änderte (mehr dazu weiter unten).

Das Problem mit dem Truecolor Modus war, daß X sich mit "pixel clock being too high" über einen zu hohen Pixeltakt beschwerte. Offensichtlich ist dies eine echte hardwareseitige Einschränkung des Pixeltaktes. Eine Weile hielt ich es für unmöglich, den Truecolor Modus nutzen zu können. Dann jedoch sah ich mir die Modelines andere Besizter von C&T Grafikkarten an (reichlich Informatinen sind auf der Linux on Laptops web page zu finden) und entdeckte den folgenden Eintrag mit geringerer Taktfrequenz:

#800x600 @ 49.5 Hz vsync, 30 kHz hsync, yucky and flickery even on LCD
ModeLine "800x600b" 28.3 800 816 856 920 600 603 605 618
Dieser Modus hat eine recht geringe Wiederholrate und bescheidene Bildqualität. Sobald ich ihn aktivierte, summte der Monitor hörbar und ich bekam tränende Augen. Auch wenn LCD Bildschirme eine bessere Bildqualität als Röhrengeräte haben und oft das Bild noch bei 56 Hz annehmbar ist (auf einem 14 Zoll Röhrenmonitor eine Qual für die Augen), waren 49 Hz definitiv nicht ausreichend. Auch wenn ich nicht genau wußte, was ich tat, so erhöhte ich einfach die Taktfrequenz von 28.3 auf 35.1, während ich die anderen Werte unverändert ließ. Nun war der Modus schon wesentlich akzeptabler. Daraufhin ersetzte ich die Taktfrequenz in der alten Modeline durch die untere Grenze von 35.4 und siehe da, es funktionierte ebenfalls! Während ich dies hier tippe, benutze ich eben diesen Modus (in Truecolor). Desweiteren fügte ich die Zeile DefaultColorDepth 24 in den Screen Abschnitt des XF86Config ein, sodaß der Truecolor Modus als Standardmodus gewählt wurde. Ich konnte mich noch daran erinnern, daß es einen Weg gab, eine bestimte Farbtiefe standardmäßig zu setzen, allerdings mußte ich die Dokumentation von X durchsuchen, um eben "DefaultColorDepth" zu finden, da das X Konfigurationsskript keine Beispieleinstellung für die Farbtiefe gesetzt hatte.

Damit der zu testende 28.3 Modus für den X Server akzeptabel werden konnte, mußte ich die erlaubten Frequenzspektren des Monitors anpassen. Das Konfigurationsprogramm hatte die folgenden Wertebereiche gesetzt:

HorizSync 31.5 - 37.9
VertRefresh 50 - 90
So wollte der neue 28.3 Modus jedoch nicht hochfahren, da für ihn die Frequenzen zu niedrig gewesen waren. Ein Blick in die Datei /tmp/startx-output und ich wußte, daß X sich über ungültige Frequenzspektren beschwerte. Ich senkte also HorizSync auf 30 statt den 31.5 und VertRefresh auf 48 statt 50. Wie auch immer, diese beiden Einstellungen, vor allem die unteren Grenzen, sind nicht absolut notwendig, da die letztlich benutzten Taktfrequenzen gänzlich über die Modeline bestimmt werden. Prinzipiell sind diese Einstellungen dazu da, den Monitor vor Schäden durch zu hohe Frequenzen zu schützen. Der X Server berechnet die Frequenzen aller Modelines und verwirft alle, deren Frequenzen außerhalb der angegebenen Spektren liegen. In der Praxis allerdings war es mir allerdings niemals möglich, präzise Daten über die Fähigkeiten des Monitors zu bekommen. Auch war es im allgemeinen notwendig, die Grenzen der Spektren ein wenig anzupassen, damit der X Server brauchbare Bildschirmmodi akzeptierte.

Zwei Dinge mußten zum Schluß noch getan werden: Ich fügte TextClockFreq 40 in die Datei XF86Config ein, sodaß die richtigen Frequenzen beim Wechseln von einer X Session zurück zu einer Textkonsole wiederhergestellt wurden. Außerdem änderte ich das startx Skript (/usr/X11R6/bin/startx), sodaß einerseits die virtuellen Konsolen weiterhin zugänglich waren, andererseits die DISPLAY Variable gesetzt wurde (die Variable, die eigentlich von dem Windowmanager, fwvm2 , verwaltet werden sollte, allerdings offensichtlich nicht wurde). Am Ende des Skriptes stand nun:

export DISPLAY=":0.0"
exec xinit $clientargs -- $serverargs >& /tmp/xinit.out &
Die zweite Zeile leitet jegliche Ausgabe der X Konsole in eine temporäre Datei und läßt den X Window Prozess im Hintergrund laufen, sodaß er bei Bedarf überwacht werden kann.

Vielfältigkeit ist die Linuxwürze

Das System war installiert, allerdings hatte ich den Eindruck, daß mir irgendwie der ganze Spaß entging: Ich hatte hier zwei der neuesten halbkommerziellen Linux Distributionen, nämlich RedHat 5.1 und SuSE 5.2, beide versprechen beispiellosen Komfort bei der Installation und Konfiguration, und stattdessen benutzte ich Slackware, die magere Hacker Distribution. Also entschied ich mich, in die Alternativen hineinzuschnuppern.
Das System war installiert, allerdings hatte ich den Eindruck, daß mir irgendwie der ganze Spaß entging.

SuSE 5.2 war trotz aller angepriesener Fähigkeiten nicht in der Lage, auf meinem Laptop zu booten. Ich bereitete die Bootdisketten vor, wobei ich die laufende Slackware Installation dafür benutzte, mittels des Kommandos dd if=/cdrom/disks/eide01 of=/dev/fd0. Keiner der IDE Bootdisketten (eide01 bis eide03) kamen beim Laden weiter, als bis zur Ausgabe der Meldung: "Loading Linux..." (mit drei Punkten), möglicherweise aufgrund eines Speicherkonfliktes oder ähnlichem. Es gibt Leute, die meinen, daß manchmal Bootdisketten abstürzten und es dann notwendig ist, ein wenig mit dem Speichercache herumzuspielen oder einen anderen Kernel zu probieren. Aber erstens funktionierte keiner der Kernel und das BIOS ließ mich nicht an den Einstellungen für den Cache herumdrehen, und zweitens: Warum sollte ich mich damit rumärgern, wenn doch die Slackware Bootdisketten einwandfrei funktionierten? Also ließ ich von der SuSE ab. Nebenbei möchte ich erwähnen, auch wenn Englisch nicht meine Muttersprache ist, daß ich das Gefühl hatte, daß die (englischen) Meldungen der SuSE Distribution mehr recht als schlecht aus dem Deutschen übersetzt worden sind.
SuSE 5.2 war trotz aller angepriesener Fähigkeiten nicht in der Lage, auf meinem Laptop zu booten.

Nun wendete ich mich der RedHat 5.1 zu. Ich war wirklich gespannt, da meine letzten Linux Erfahrungen von der RedHat 4.2 stammten und ich gehört hatte, daß sich seitdem einiges getan haben sollte. Das Installationskript war glänzend, ich mußte nur eine Bootdiskette erstellen, die einwandfrei funktionierte und glitt förmlich durch den Installationsproseß. Das parallele ZIP Laufwerk wurde erfolgreich als "/dev/sda" gefunden. Allerdings hatte ich kein Medium eingelegt, so daß sich fdisk mit der Meldung "unable to access the default device /dev/sda" (kein Zugriff auf das Gerät /dev/sda) beschwerte. Während der Installation hatte ich parallel eine weitere freie Konsole, in der bereits die Bash Shell lief, sowie zwei Konsolen für etwaige Fehlermeldungen und einen Überblick über den gegenwärtigen Zustand der Installation (Ctrl Alt F3 und F4). Bei der Auswahl der einzelnen Pakete, die installiert werden sollten, wurde immer angezeigt, wieviel freien Speicher die jeweilige Software benötigte, ganz im Gegensatz zur Slackware. Das war aber damals nicht weiter tragisch, da die insgesamt benötigte Menge an Speicherplatz unter 400 MB lag und die /usr Partition mehr als doppelt so groß war.

Nun ging es weiter mit der Konfiguration von X, was mehr oder weniger schmerzlos vonstatten ging. Die Datei /etc/X11/XF86Config, die aus der Konfiguration resultierte, war eher weniger für meine Hardware zu gebrauchen, da der benötigte 24 Bit Truecolor Modus nicht eingerichtet wurde. Stattdessen hätte es den 32 Bit Modus ignorieren sollen. Allerdings wußte ich ja schon, welche Modi funktionierten und alles in allem war es gar nicht so schlimm. Die Grafikkarte (C&T) war korrekt erkannt worden. Ich konnte X ohne Probleme hochfahren (bis auf den Punkt, daß die X Terminals weisse Schrift auf schwarzem Hintergrund benutzten, was ich nicht sonderlich mochte) und probierte, nur so zum warm werden, das großartige rpm aus ("RedHat Package Manager", das Werkzeug, welches für die Software Installation und Deinstallation benutzt wird), um die neue Ghostscript Version 5.10 aus dem Verzeichnis redhat/contrib zu installieren. Sollte eigentlich ganz einfach sein, dachte ich, man gibt nur schlicht und ergreifend das intuitive Kommando rpm -i packagename.rpm statt des langwierigen und kryptischen tar zxf packagename.tgz ein und das wars, oder ? Hoppla, rpm teilte mir mit, daß ein weiteres Paket für die Installation von Ghostscript benötigt werden würde, und zwar ein Paket namens "ghostscript-fonts-standard" oder so ähnlich und daß dieses Paket nirgends gefunden werden könnte. Es gab andere Ghostscript Font Pakete, aber eben dieses genau nicht. Dies kam mir bekannt vor: Ich erinnerte mich daran, daß rpm mir mal mitteilte (unter RedHat 4.2), daß das Paket /bin/sh nicht installiert wäre. /bin/sh ist die Shell...wie sollte ich denn ohne Shell irgendein Kommando eingeben können ? Ich erwartete schon fast von rpm zu hören, daß das Mainboard fehlen würde. Typische Macke von rpm dachte ich mir, und ließ es bleiben. Insgesamt schien das System langsamer als unter der Slackware, bei gleicher installierter Software.
.. linuxconf, ein Werkzeug für die Systemkonfiguration, angepriesen als der beste Freund des Systemadministrators.
Als nächstes probierte ich linuxconf, ein Werkzeug für die Systemkonfiguration, angepriesen als der beste Freund des Systemadministrators. Unglücklicherweise war mir nicht klar, wozu die ganzen verschiedenen Widgets gut waren und was sie im System änderten; einige war offensichtlich, andere hingegen total kryptisch. Für mich ist das Wichtigste, das System zu verstehen und mit Hilfe dieses Wissens, Probleme zu beheben. Ich unterstelle mal, daß RedHat und andere Anhänger der "Macht es bloß einfach" Doktrie versuchen, die Verwaltung des Systemes nicht durch das Verbergen von trivialen Details "einfach" machen wollen, sondern durch die Benutzung bestimmter angebotener Software und dem Vermeiden von Konfigurationen per Hand.

Ein andere Kritikpunkt betraf die Unterstützung des ZIP Laufwerkes: Obwohl es gefunden wurde, war der Zugriff furchtbar langsam, da der benutzte Treiber eine uralte Beta Version war, die nur den langsamsten Zugriffsmodus unterstützte. Dadurch mußte ich den Treiber (und möglicherweise auch den Kernel) neu kompilieren. Einige andere Probleme tauchten bei der Installation der Kernel Quellen auf, ich weiss aber nicht mehr, was für welches es waren. Diese Punkte und die Angst vor den "rpm Spinnereien" ließen mich wieder zur guten alten Slackware wechseln. Ich bootete mit den Slackware Disketten, die ich immernoch hatte, wiederholte die Installation unter Berücksichtigung der bekannten Eigenheiten und bald war das System installiert und lief.

Den Kernel neu kompilieren

Im Zentrum jedes Linux Systems befindet sich der Kernel und mir war bekannt, daß er die Unterstützung für all die verschiedenen Geräte, die mit dem System verbunden sind, beinhalten mußte, von der Maus bis zur Soundkarte, vom parallelen ZIP Laufwerk bis zum externen SCSI CD Rom. Ebenfalls wußte ich, daß der Kernel dies auch in modularer Form zuläßt, also die Treiber bei Bedarf geladen und auch wieder aus dem System entfernt werden. Dadurch wird der Kernel kleiner und flexibler, da ich prinzipiell Treiber für ansich nicht kompatible Geräte laden und entfernen kann, wenn es notwendig wird. Zum Beispiel kann es sein, daß der Druckertreiber nicht mit dem Treiber für das parallele ZIP kompatibel ist, weswegen immer nur einer der Treiber gleichzeitig geladen werden kann.
Es ist besser, den Kernel neu zu kompilieren, sodaß genau die Hardware unterstützt wird, auf der er läuft.
Der mit der Standard Linux Distribution mitgelieferte Kernel unterstützt einige grundlegende Geräte, unter anderem solche, die ich niemals haben werde. Die Treiber für diese Geräte verbrauchen sinnlos Speicher. Deswegen ist es besser, den Kernel neu zu kompilieren, sodaß genau die Hardware unterstützt wird, auf der er läuft.

Dies war meine Motivation, den Kernel neu für meinen Rechner zu konfigurieren und kompilieren. Da ich bei der Konfiguration der Slackware bereits die kompletten Kernelquellen (Version 2.0.34) installiert hatte, wurde das kompilieren des Kernel recht einfach. Ich wechselte in das Verzeichnis /usr/src/linux und gab make menuconfig ein, wodurch das textbasierte Konfigurationsskript des Kernels gestartet wurde. Nach kurzer Zeit präsentierte sich ein hübsches Dialogfenster mit verschiedenen Optionen für den Kernel. Jede Option ist gut dokumentiert und ich verstand sie in recht kurzer Zeit. Ich wählte alles aus, was ich konnte, bis hin zu der Soundkarte (ein ESS "AudioDrive"), die zwar nicht aufgeführt war, von der ich jedoch aus den READMEs erfuhr, daß sie ein SoundBlaster Klon war (obwohl sie nicht explizit als solcher aufgeführt war, wie es sein sollte). Ich kompilierte die Treiber für alle Peripheriegeräte als Module, darunter waren die Stromsparfunktionen ("APM"), die SoundBlaster kompatible Soundkarte, die PS/2 Maus, serielle Ports, Diskettenlaufwerk, CD Rom, und SCSI Unterstützung (für mein ZIP, obwohl es immer gut ist, sie zu haben). Ebenso erstellt ich Module für diverse netzwerkbezogene Dinge, wie SLIP und PPP, sowie für die verschiendenen Formate von ausführbare Dateien (a.out, ELF und JAVA), für den Fall, daß ich sie brauchen sollte. Daneben kompilierte ich die Module für das Macintosh Dateisystem (hfs), welches ich für SGI-kompatible ZIP Disketten benötigte, und spielte dann eine neuere Version der Unterstützung für parallele ZIP Laufwerke auf (kommen nicht mit dem Standardkernel mit, ich brauchte sie aber). Ebenso lud ich die neueste Version des PCMCIA Paketes herunter (pcmcia-cs-3.0.4) und kompilierte die Treiber für den SCSI Controller und die Netzwerkkarte als Module.

Danach führte ich make dep; make zlilo; make modules; make modules_install aus und mußte ca. 15 Minuten warten. Danach war der Kernel und die Module kompiliert und ich installierte sie in die richtigen Verzeichnisse. Ich überprüfte, ob die Kerneldatei /vmlinuz neuer und kleiner, als die in /vmlinu.old gesicherte ältere Version war, und bootete neu...nur, um herauszufinden, daß das System nicht mehr startete und stoppte, bevor irgendein Dateisystem eingebunden worden war. Die übliche Abfolge der Nachrichten während des Bootens stoppte bei VFS: mounted root (ext2 filesystem) readonly. Kein Dateisystem wurde unter read-write eingebunden, und keines der Systemskripte zur Initialisierung (durch INIT gestartet) wurde ausgeführt. Ops.

Nachdem ich von der Slackware Bootdiskette mit dem alten Kernel gebootet hatte, bekam ich mein System zurück, wiederholte die Kernelkonfiguration und überlegt mir, was mit dem neuen Kernel falsch sein mochte. Bald fand ich den fatalen Fehler: Ich war so auf die Idee fixiert, alles zu modularisieren, daß ich den dummen Fehler machte und die Kernelunterstützung für alle Formate von ausführbaren Dateien (a.out, ELF und JAVA) ebenfalls modular kompilierte. Der Kernel und alle anderen Programme sind im ELF Format kompiliert worden. Wenn der Kernel also gestartet worden war, konnte er kein anderes Programm ausführen, solange das Modul für die ELF Unterstützung nicht geladen wurde. Dafür allerdings hätte das Programm insmod aufgerufen werden müssen, welches im ELF Format vorlag. Hier biß sich die Katze in den Schwanz. Die einzige Möglichkeit, dies zu vermeiden, war natürlich, die ELF Unterstützung fest, und nicht als Modul, in den Kernel einzubinden. Dies ist eigentlich sowieso angebracht, da heutzutage die meisten Programme im ELF Format kompiliert werden. Nachdem ich den Kernel mit dieser Änderung neu übersetzt hatte, konnte ich ohne Probleme neu booten.

Dann löschte ich im Verzeichnis /lib/modules alle Module, die älter als die gerade kompilierten waren. Dadurch verschwanden die Fehlermeldungen zur Bootzeit, die sich auf inkompatible Module bezogen. Auch modifizierte ich das Initialisierungsskript des Systems /etc/rc.d/rc.S so, daß kerneld, der "Daemon", der automatisch Module lädt und entfernt, gestartet wurde. Dadurch wurde es nicht mehr nötig, dies per Hand mittels insmod und rmmod zu tun, ob wohl es natürlich weiterhin möglich war. Mit dem Befehl lsmod werden alle Module, die gerade in den Kernel geladen sind, angezeigt.
Ich mußte die Zeile alias scsi_hostadapter ppa in die Datei /etc/conf.modules eintragen, wodurch der Treiber für den Parallelport automatisch geladen wurde, sobald ich versuchte, auf das ZIP Laufwerk (/dev/sda) zuzugreifen.
kerneld arbeitete einwandfrei, Module wurde bei Bedarf geladen und, nachdem sie eine gewisse Zeit lang nicht mehr benutzt worden waren, wieder entfernt. Ich mußte wohl die Zeile alias scsi_hostadapter ppa in die Datei /etc/conf.modules eintragen, wodurch der Treiber für den Parallelport automatisch geladen wurde, sobald ich versuchte, auf das ZIP Laufwerk (/dev/sda) zuzugreifen. Wahrscheinlich werde ich dies wieder ändern müssen, wenn ich einen SCSI Controller statt des Parallelportes benutzen werde.

Schritt für Schritt, die Glocke zum läuten bringen

Nachdem der Kernel neu übersetzt worden war, konnten einige nette Dinge konfiguriert werden, wie der Zugriff auf externe Massenspeicher (momentan Diskettenlaufwerk, CD Rom und ZIP), Unterstützung für zwei Mäuse gleichzeitig, Russisch als Sprache und der Konfiguration des fvwm2 Windowmanagers.

Durch das Slackware Installationsskript wurde das Verzeichnis /mnt angelegt, in welchem die Unterverzeichnisse /mnt/floppy und /mnt/cdrom zu finden waren, mit denen externe Dateisysteme von Disketten und CD Roms eingebunden wurden. Zuerst fand ich diese Verzeichnisstruktur ein wenig unpassend und legte statt ihrer /floppy und /cdrom an. Später jedoch wurde mir klar, daß weitere Verzeichnisse ich für das Mounten von Geräten mit verschiedenen Optionen benötigte und griff dann wieder auf die /mnt Hierarchie zurück, anstatt alle Verzeichnisse im Wurzelverzeichnis anzulegen.

Desweiteren änderte ich die Optionen in /etc/fstab, die das Einbinden der Geräte beeinflußte. Während der Installation waren ansich brauchbare Standardwerte in der Datei eingetragen worden. Diese waren für meine Bedürfnisse jedoch nicht ausreichend. Zuerst erstellte ich die Einträge für das Diskettenlaufwerk, das CD Rom und das ZIP Laufwerk. Diese sollten nicht automatisch gemountet werden. Darüberhinaus sollten alle Benutzer in der Lage sein, sie einzubinden (über die Option user):

/dev/fd0   /mnt/floppy  vfat    user,noauto,noexec,nonumtail  0 0
/dev/sda4  /mnt/zip     vfat    user,noauto,noexec,nonumtail  0 0
/dev/hdc  /mnt/cdrom    iso9660 user,noauto,noexec            0 0
Man achte auf die noexec Option für die DOS-kompatiblen Dateisysteme: durch sie können auf diesen Dateisystemen keine Dateien ausgeführt werden, was sicherlich recht vernünftig ist. nonumtail als Option unterbindet die Generierung von häßlichen Dateinamen: Die Datei longname.file wird in longname.fil statt in longna~1.fil umbenannt, solange es zu keinen Konflikten bei der Namensgebung kommt. Das vfat Dateisystem unterstützt lange Dateinamen auf einer DOS-kompatiblen Art und Weise, im Gegensatz zum älteren msdos Dateisystem, also warum sollte man dies nicht nutzen ?

Das mtools Paket machte einige Schwierigkeiten: Entweder es bekam Schreib/Lese Rechte auf /dev/fd0 (Diskettenlaufwerk) oder der Superuser war als Einziger in der Lage, diese Aktionen auf Disketten auszuführen. Auch das Setzen des setuid Bit für die mtools brachte keine Verbesserung. Ich entschloß mich schließlich, daß ich Disketten lieber per Hand mounten würde.

Die Aktion mit den Mäusen war relativ einfach. Ich hatte schon bei der Konfiguration meines letzten Laptops herausgefunden, wie dies funktionierte. Das Laptop hatte ein eingebautes Touchpad (welches technisch gesehen eine PS/2 Maus ist), zusätzlich wollte ich noch eine externe Maus an den seriellen Port anschließen. Beide Mäuse konnten am einfachsten durch die Benutzung von gpm ("General Purpose Mouse") gleichzeitig unterstützt werden. Das Programm dient zwei Zwecken: Erstens erlaubt es im Textmodus, die Maus als Zeiger zu benutzen (innerhalb von Programmen, die dies unterstützen) und bietet
Beide Mäuse können am einfachsten durch die Benutzung von gpm ("General Purpose Mouse") gleichzeitig unterstützt werden

Cut-and-Paste Funktionalität. Zweitens kann gpm zwei verschiedene Mäuse (egal, welcher Typ, z.B. Bus Mouse, PS/2, serielle Maus,...) in einem logischen Zeigergerät vereinigen. Alles, was dafür notwendig ist, ist eine bestimmte Befehlszeile. Die Syntax ist ein wenig unhandlich, aber die Man Page (man gpm) erklärt sehr genau die Benutzung und liefert einige anschauliche Beispiele. gpm wurde im Initialisierungsskript /etc/rc.d/rc.local gestartet, da ich es ja bei der Installation der Slackware ausgewählt und aktiviert hatte. Ich modifizierte die gpm Zeile wie folgt:

gpm -t ps2 -m /dev/psaux -2 -M -t mman -m /dev/cua0 -3 -R
Dies kann wiefolgt entziffert werden: Die erste Maus ist eine Zweitasten Maus vom Typ PS/2 am "Auxiliary" Port. Die zweite Mause (-M) is eine Dreitasten Maus vom Typ {Logitech] MouseMan und angeschlossen am ersten seriellen Port (/dev/cua0). Die Option -R bedeutet, daß beide Mäuse als eine einzige Maus unter  dem X Window System laufen sollten (die Option braucht nicht mehr ab gpm Version 1.14 oder höher angegeben werden). Nachdem die Zeile so eingegeben worden war, beendete ich gpm, um es danach wieder neu zu starten (gpm -k; /etc/rc.d/rc.local). Daraufhin liefen sofort beide Mäuse problemlos. Ich konnte sogar die serielle Maus während des Betriebes von X anschließen und voila, sie funktioniert tadellos, etwas, was unter dem sogenannten Betriebssystem mit den Fenstern nicht möglich war. Vielmehr ließ es den Benutzer den Rechner neu booten, damit die "neue Hardware" funktionieren konnte.

Als nächstes widmete ich mich der Unterstützung von kyrillischen Zeichen. Diese brauchte ich, um russische Texte lesen und eventuell schreiben zu können. Ich installierte die Unterstützung für das Kyrillische nur unter X. Dafür mußten zwei Dinge erledigt werden: es mußte ein kyrillischer Zeichensatz und eine  entsprechende Tastaturbelegung eingerichtet werden. Eine ganze Anzahl von Seiten im Netz beschäftigen sich mit den Details der "Kyrillisierung von Unix". Ein Satz von KOI-8 Zeichensätzen wird von der Slackware angeboten.  Die "Cyrillic HowTo" verweist auf die Sammlung genannt VakuFonts, die von Serge Vakulenko (vak@kiae.su) geschaffen worden ist. Sie kann von der Seite cyrillic stuff for the X Window System bezogen werden. Ich lud zwei Zeichensatzpakete herunter, welche die gleichen Zeichensätze in der KOI-8 und der CP-1251 (oder auch "Windows") Kodierung enthielten, entpackte die Zeichensatzdateien (*.pcf.gz) in die Unterverzeichnisse koi8-r und x-cp1251 im Hauptverzeichnis für Zeichensätze des X Window Systemes /usr/X11R6/lib/X11R6/fonts (auf das Verzeichnis kann unter meinem Slackware System einfacher über den Link /etc/X11/fonts zugegriffen werden) und installierte die Zeichensätze, indem ich die beiden neuen Unterverzeichnisse den Pfaden des Eintrages "FontPath" in der Datei /etc/X11/XF86Config hinzufügte. Danach startete ich X erneut  und alle Zeichesätze waren verfügbar, sodaß ich Netscape (ich benutzte Version 4.05) so einstellen konnte, daß es automatisch diese Zeichensätze für die entsprechenden "Kodierungen" koi8-r und  x-cp1251 verwendete.

Nun brauchte ich noch einen Treiber für die russische Tastatur. Ich benutzte hierfür das einfache und unaufällige Programm xrus, das ich von Moshkow's Library, the page on Cyrillization herunterlud. Nachdem ich seine Ressourcendatei /etc/X11/app-defautls/Xrus geändert und das Tastaturlayout, meines Wissens nach, der russischen Schreibmaschine :) angepaßt hatte, konnte ich bequem in Russisch tippen.

Als Letztes blieb noch, ein Programm für die Konvertierung von Dateien, von einer russischen Kodierungen in die andere, zu installieren. Dafür benutzte ich ein selbstgeschriebenes Skript, das ich 323 nannte. Es ist in der Lage, zwischen CP866 ("DOS" oder "Alternativ"), KOI-8, CP-1251 ("Windows") und Macintosh Kodierungen zu konvertieren. Ich legte einige Hard Links auf 323 namens koi2win, alt2mac, usw.  (ln 323 koi2win usw.) an, das Skript konnte automatisch anhand des benutzten Namens herausfinden, was es tun sollte. Mit diesem Skript und den installierten Zeichensätzen kann man die meisten russichen Texte lesen.
Nun brauchte ich noch einen Treiber für die russische Tastatur.

Alles war für das X Window System ordentlich konfiguriert, bis auf den Windowmanager fvwm2. Alle Einstellungen für ihn werden in der Datei ~/.fvwmrc oder, falls diese Datei nicht existieren sollte, in der systemweiten Datei /etc/X11/fvwm2/system.fvwm2rc verwaltet. Ich war der Meinung, daß in der Ressourcedatei, die von der Slackware installiert worden war, zuviele Dinge standen waren, die ohnehin nicht zu gebrauchen wurden oder gar nicht erst funktionierten. Also entfernte ich einen nicht geringen Teil dieser "Features". Hauptsächlich wollte ich, daß der Windowmanager folgende Funktionen erfüllte: es sollten einige Buttons für das schnelle Aufrufen einer kleinen Anzahl der nützlichsten Programme existieren, desweiteren sollte er auf Maus und Tastatur im Hinblick auf Fensteroperationen wie Bewegung oder Positionierung reagieren. Außerdem sollten einige häufige Aktionen über die Knöpfe der Titelzeile jedes Fensters durchgeführt werden können. Und es sollte ein Menü mit allen installierten X Programmen angezeigt werden. Dies alles sollte idealerweise noch von der Tastatur aus, also ohne die Maus zu benutzen, möglich sein.

Ich überarbeitete die Konfigurationsdatei viele Male, und arbeitete mich durch die lange und recht üppige Man Page (man fvwm2), um herauszufinden, wie die jeweiligen Funktionen aufgerufen werden und fügte so im zunehmenden Maße Änderungen der ursprünglichen Datei hinzu. Speziell war ich daran interessiert, die "Windows 95" Tasten für verschiedene Fensteroperationen einzusetzen. Das Ergebnis ist hier (fvwm2rc.html) zu finden,
ich hoffe, es ist ausreichend dokumentiert, sodaß man alles versteht.

Vernetzung über einen Einwahlzugang auf GNU Art

Ich war überrascht, wie schnell der Einwahlzugang zu meinem lokalen PPP Netzwerkanbieter eingerichtet und funktionsfähig war. Nachdem ich komplizierte und offensichtlich veraltete Dokumentation über die Einrichtung von PPP gelesen hatte, inklusive der "Installationsanleitung", war ich der Meinung, daß es recht nervenaufreibend werden würde, PPP zu installieren. Jedoch fand ich beim Ausprobieren der Befehle, deren Namen mit ppp anfingen, heraus, daß Slackware ein Skript namens pppsetup mitlieferte, welches mir genau die richtigen Fragen nach meinem Modem und PPP Anbieter stellte. Allerdings wußte ich gar nichts darüber: zum Beispiel, ob das Authentifizierungsprotokoll "PAP", "CHAP" oder "CHAP-Microsoft" war. Ich wählte (zufällig) "CHAP" aus und setzte die Konfigurierung fort. Bald war alles getan und ich wurde aufgefordert, mit zwei sich selbst erklärenden Befehle für den Betrieb der PPP Verbindung zu arbeiten, ppp-go und ppp-off,. Außerdem gab es einen recht ausführlichen Text, /etc/ppp/pppsetup.txt, der beschrieb, was während der Benutzung von pppsetup am System geändert wurde. Diese Anleitung hielt mich an, ifconfig zu benutzen, damit ich den erfolgreichen Aufbau der PPP Verbindung überprüfen konnte. Desweiteren verwies mich der Text an die Logdateien /var/log/messages und /var/log/debug, falls es zu Problemen kommen sollte (da die Option debug in der Datei /etc/ppp/options standardmäßig gesetzt war. Dies änderte ich später, da die debug Datei zumeist mit nun unwichtigen Meldungen von pppd überschwemmt wurde).

Alles sah prima aus, allerdings schien ppp-go, keine Verbindung aufzubauen, nachdem ich das Modem an die Telefonleitung anschloß. Die Datei /var/log/debug enthielt viele Einträge. Am Ende der Datei fand ich den erfolglosen Informationsaustausch zwischen pppd und der Gegenstelle. Einer der Nachrichten der anderen Seite lautete <auth pap>. Also hätte ich "PAP" statt der "CHAP" Authentifizierung auswählen müssen. Ich durchlief nochmals pppsetup und die PPP Verbindung stand daraufhin binnen kurzer Zeit. Es scheint übrigens im pppsetup einige Funktionen zu geben, die die Logdatei des Systems grep'pen und dann Nachrichten der Art "Es scheint, daß PAP erwartet wird..." usw. erzeugen, allerdings sind diese Funktionen aus irgendeinem Grund auskommentiert. Gibt es eine bessere Version von pppsetup, war vielleicht die Entwicklung des Programmes noch nicht beendet ?
Eines Tages werde ich ein einfacheres Programm installieren oder Perl/Tk erlernen und mir meine eigenen Hilfsmittel für die Vernetzung über Einwahlzugänge schreiben. Oder ich werde ganz auf RedHat umsteigen, sobald GNOME als objektorientierter Dektopmanager nicht mehr in den Kinderschuhen steckt.

Obwohl PPP nun großartig läuft und ich ohne Probleme fetchmail, ncftp, Pine, netscape und andere tolle Programme benutzen kann, bin ich mit dem Setup noch nicht ganz zufrieden. Ich wünschte mir, daß der Einwahlvorgang besser kontrolliert werden könnte und Fehlermeldungen (falls es welche gibt) für den Benutzer sichtbar wären. Falls eine PPP Verbindung unterbrochen werden sollte, sollte es möglich sein, dies ohne das Einloggen als "root" und das Durchsuchen der Logdateien zu bemerken. Möglicherweise werden die kommerzielleren Linux Distributionen Werkzeuge zur Verfügung stellen, die PPP für den Benutzer einfacher zu handhaben machen (vielleicht gppp?), allerdings fürchte ich, daß solche Werkzeuge weit mehr auf zusätzlicher Software aufbauen, die installiert sein muß, oder daß sie nicht ohne ihre "natürliche" Umgebung funktionieren. Eines Tages werde ich ein einfacheres Programm installieren oder Perl/Tk erlernen und mir meine eigenen Hilfsmittel für die Vernetzung über Einwahlzugänge schreiben. Oder ich werde ganz auf RedHat umsteigen, sobald GNOME als objektorientierter Desktopmanager nicht mehr in den Kinderschuhen steckt.

Ein weiterer Punkt bei PPP war, daß das ppp-go Skript von "root" gestartet werden mußte. Zuerst dachte ich, ich könnte "Einwahl bei Bedarf" einstellen, allerdings beinhaltete der Kernel aus irgendeinem Grund keine Version des PPP Treibers (2.3), die diese Options unterstützte. Dann fand ich aber ein sehr kurzes C Programm im Netz, "ppp für Sterbliche", welches hauptsächlich die Funktion setuid(0) aufruft, um "root" zu werden und dann das ppp-go Skript ausführte. Ich kompilierte und installierte es mit dem setuid Bit auf 1 gesetzt (chmod 4755 ppp_for_mortals). Hiernach konnte ich das Programm als einfacher Benutzer einsetzen, um die PPP Verbindung auf- oder abzubauen.

Anhang: Informationen über die Hardware

Systeminformationen:
Pentium CPU, 133MHz
16MB RAM erweiterbar bis auf 48MB
1.3GB Festplatte, EIDE Schnittstelle
12" TFT LCD Bildschirm, 800x600 Auflösung, manuelle Helligkeiteinstellung
Chips&Technologies 65550 Grafikkarte mit 2MB RAM, Truecolor bis zu einer Auflösung von 800x600
Peripheriegeräte:
Eingebautes Touchpad mit 2 Tasten
2 PCMCIA-II Erweiterungsslots
Eingebautes Modem (28.8 kbps), teilt sich COM2 mit der IRDA Schnittstelle
eingebautes ESS AudioDrive, eine 16 bit "Soundblaster kompatible" Soundkarte
Docking Station mit CD Rom und Diskettenlaufwerk (kein Diskettenlaufwerk am Laptop selbst)
CDROM: IDE/ATAPI, 8 fach Laufwerk, am sekundären IDE Controller angeschlossen
Linux Konfiguration:
Linux Kernel version 2.0.34
Distribution: Slackware Linux 3.5 (von Patrick Volkerding)
Vertrieb: Cheapbytes (www.cheapbytes.com)
Gegenwärtige Unerstützung der Peripheriegeräte:
eingebaute PS/2 Maus zusammen mit einer externen seriellen oder PS/2 Maus, wird voll unterstützt
eingebaute Soundkarte: funktioniert, auch wenn es bei etwas höherer Lautstärke zu Rückkopplungen kommt
eingebautes Modem: funktioniert, mit Minicom ausprobiert
Grafikkarte: voll unterstützt in 640x480, 800x600 und 1024x768 Modi (Bild bei letzteren Modi nur teilweise auf dem Schirm) in 8, 16 and 24 Bit Farbtiefe, mit 60Hz, 56Hz und 52Hz vertikaler Wiederholrate (auf einem TFT LCD Bildschirm ausreichend), mit Beschleunigung.
CDROM and Diskettenlaufwerk der Docking Station: werden voll unterstützt
Stromsparfunktionen (APM): werden voll unterstützt


Literaturhinweise


Übersetzung:Harald Radke
Web pages maintained by Miguel Ángel Sepúlveda
© Serge Winitzki 1998
LinuxFocus 1998