![[Top Bar]](../../common/images/Topbar-en.gif){kind=small}
![[Bottom Bar]](../../common/images/Bottombar-en.gif){kind=small}
![[Ilustration]](../../common/images/illustration16.gif)
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.
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
|
|
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.
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,
|
|
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ß
|
|
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
?
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.
|
|
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 +vsyncEin ä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 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 618Dieser 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 - 90So 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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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 0Man 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
|
|
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 -RDies 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 ([email protected]) 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.
|
|
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.
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 ?
|
|
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.
| Web pages maintained
by Miguel Ángel Sepúlveda
© Serge Winitzki 1998 LinuxFocus 1998 |
![[Photo of the Author]](../../common/images/Who.gif)