f e r r u g o

Linux From Scratch auf dem COMPAQ LTE 5300

Gliederung

Das Ziel

Mein Notebook (Compaq LTE 5300, 133 MHz, 80 MB RAM, 6fach CD-R, 40 GB HDD) soll mit Linux From Scratch ein kleines, flinkes und verständliches Linux bekommen, mit dem ich OpenOffice und Firefox benutzen kann, ins Internet komme, Musik hören (vielleicht sogar aufnehmen) und programmieren kann.
Was ich wohl nicht oder kaum schaffen werde, ist, die großen Distributionen besser zu verstehen. Denn das, was die so kompliziert macht, will ich mir ja vom Hals halten.

Meine Erfahrungen mit Linux From Scratch

Dieses Installationstagebuch stellt erst in zweiter Linie eine technische Dokumentation dar, auch wenn es eine Reihe technischer Details enthält. In erster Linie ist es als eine Machbarkeitsstudie gedacht, die zwei Fragen beantworten soll: Kann man erstens auf der Basis weniger Grundkenntnisse und mit Hilfe der LFS-Anleitung ein Linuxsystem von grundauf selbst installieren? Und was kann man zweitens dabei lernen?

«Wenige Grundkenntnisse» ist nicht gerade ein selbsterklärender Begriff. In meinem Fall bedeutet das: Ich habe schon fünf oder sechs mal ein Linux installiert, aber insgesamt wohl nicht einmal fünf oder sechs Wochen wirklich damit gearbeitet. Allerdings komme ich mit der Kommandozeile gut klar, weil ich die noch vom DOS gewöhnt bin. Außerdem habe ich schon ein paar kleinere Programme geschrieben, was mir vor allem deshalb nützlich erscheint, weil es mir die Ehrfurcht vor dem Quelltext genommen hat.

Bei all den vielen Dingen, die ich nicht weiß, ist mir das Buch «Linux in a Nutshell» aus dem O'Reilly-Verlag eine ernorme Hilfe.

Zusammenfassung

Phase 1: Vorbereitung

Ich habe mich für die Installation über die LFS LiveCD 6.3 entschieden, da ich kein aktuelles Linux auf meinem Rechner habe und keine Geduld, die Pakete einzeln aus dem Netz zu laden. Die LiveCD machte anfänglich zwar etwas Schwierigkeiten, die aber beseitigt werden konnten.
Die Einrichtung der Arbeitsumgebung (Kapitel 4 des LFS-Buches) lief ohne Probleme.
[Phase 1 im Installationstagebuch]

Phase 2: Erstellung des temporären Systems

Diese Phase entspricht dem Kapitel 5 des LFS-Buches. Die tool chain wird erstellt. Probleme sind nicht aufgetreten. Die Testsuites habe ich allerdings auch nicht durchlaufen lassen.
[Phase 2 im Installationstagebuch]

Phase 3: Aufbau des LFS-Systems

Diese Phase entspricht dem Kapitel 6 des LFS-Buches. Mit Hilfe der tool chain wird das neue System erstellt. Zwei kleine Fehler, die ich in Phase 2 in die tool chain eingebaut hatte, konnte ich korrigieren. Einen schwerer wiegenden nicht – also musste die tool chain erneut erstellt werden.
Mit der neuen tool chain konnten alle Pakete kompiliert werden. Probleme traten nur bei den Testsuites von Glibc und Gcc auf. Dabei handelte es sich vor allem um Timeout-Fehler aufgrund der langsamen Hardware. Die Timeout-Probleme konnten durch Übergabe geeigneter Parameter und Anpassung der Konfigurationsdateien gelöst werden. Einige andere Fehler aus der Gcc-Testsuite habe ich ignoriert, weil diese vermutlich auf Unzulänglichkeiten der Testsuite zurückgehen.
Abweichend vom LFS-Buch habe ich im Kapitel 6.12.1 nebem dem C- und dem C++-Compiler auch den Java-Compiler installiert.
[Phase 3 im Installationstagebuch]

Phase 4: LFS wird startklar gemacht

Diese Phase entspricht den Kapiteln 7 und 8 des LFS-Buches. Die Bootskripte werden eingerichtet und der Kernel und Grub installiert. Die Einrichtung der Bootskripte geht schnell, setzt aber einiges Vorwissen voraus, über das ich nicht verfüge. Deshalb habe ich die Skripte erst einmal provisorisch eingerichtet und werde sie in der Testphase noch weiter anpassen.
Die Konfiguration des Kernels erwies sich als recht aufwendig und kompliziert, aber nicht unmöglich.
Schließlich konnte das neue LFS sauber gestartet werden.
[Phase 4 im Installationstagebuch]

Phase 5: Test und Einrichtung des LFS

Hier wird das LFS an die Hardware angepasst. Das betrifft vor allem die Einrichtung des Netzwerks und die Verbesserung der Kernelkonfiguration.
Leider stellte sich in dieser Phase heraus, dass mein Computer den Anforderungen moderner Anwendungen nicht gewachsen ist, sodass ich ein neues LFS auf einem schnelleren Rechner bauen werde, um dann mit der Einrichtung der ersten Anwendungen weiterzumachen. Diese Seite ist damit abgeschlossen. [Phase 5 im Installationstagebuch]

LFS-Logo, found at http://www.linuxfromscratch.org/blfs/artwork/. Thanks.

Phase 1: Vorbereitung

20.08.07
Ich habe gestern die Live-CD der Version 6.2-5 heruntergeladen und den Rechner probeweise damit hochfahren lassen: Die Partitionen werden nicht so erkannt, wie ich das gerne hätte. Mein Rechner ist fast 10 Jahre alt (Compaq LTE 5300) und ich habe Anfang des Jahres eine 40-GB-Platte nachgerüstet. Linux hätte damit zwar kein Problem, aber auf der Platte befinden sich noch ein «Enhanced DR DOS» und ein «MS Windows 98 SE» und die brauchen bei dieser Kombination aus altem BIOS und großer Platte einen Disk Manager – in meinem Fall «Ontrack» (Ver. 10.42.04).
Wie ich im Large-Disk-HOWTO herausgefunden habe, wird der Disk Manager aber nur bis zum Kernel 2.5.70 automatisch unterstützt. Danach sollte der Bootparameter hda=remap63 das Problem beheben. Bei der LFS-Live-CD funktioniert das nicht. Das HOWTO ist vom 01.11.04. Die letzte LFS-Version, die mit einem Kernel kleiner als 2.5.70 herauskam, ist 5.1.1 mit dem Kernel 2.4.26.
Macht es Sinn, auf so einem alten Rechner das neueste Linux installieren zu wollen? Macht ihn das nicht unnötig langsam? Eine 5.1.1-Live-CD habe ich noch nicht gefunden. Vielleicht besorge ich mir die Pakete dann einzeln. Vielleicht muss ich einfach einen anderen Bootparameter übergeben und dann läuft auch das 6.2er LFS.

21.08.07
Erst einmal werde ich in alle Richtungen weiterforschen. Ich habe an die LFS-Live-CD-Mailingliste geschrieben und gleichzeitig begonnen, mir die Pakete für die Version 5.1.1 zusammenzusuchen. Bei nächster Gelegenheit (wahrscheinlich Anfang September) werde ich mir die 6.0er Live-CD besorgen. Vielleicht reagiert die ja auf hda=remap63.

22.08.07
Die Antwort aus der Mailingliste ist da. Der Parameter soll als linux hda=remap63 eingegeben werden und außerdem möge ich doch bitte zur 6.3 Live-CD wechseln und berichten, ob es da auch funktioniert, denn die 6.2 sei tot.
Jedenfalls wird mit diesem Parameter der Disk Manager erkannt und ich kann mit der 6.2er weitermachen. Jetzt brauche ich nur noch etwas freie Zeit und dann geht es los.
[Nachtrag vom 07.09.07: Das linux muss vor den Parameter, damit der richtige Kernel geladen wird. Es gibt nämlich noch einen 64-bit-Kernel (linux64).]

29.08.07
Es gibt auf den LFS-Seiten einige Informationen darüber, wie man die Fragen an die Mailinglisten am besten formuliert, wenn man nützliche Antworten erhalten möchte. Die Ansprüche sind – verglichen mit dem, was einem das Internet sonst so abverlangt – recht hoch und schrecken sicher manchen ab. Das wirft bei mir vor allem zwei Fragen auf: Legen die Linux-Spezialisten auch in anderen Bereichen Wert auf Qualität, wo sie keine Spezialisten sind, so wie sie von Linux-Anfängern Qualität im Linux-Bereich erwarten? Und wie sähe die Welt aus, wenn dieses Niveau überall Standard wäre?

03.09.07
Am 01.09. habe ich mir die 6.3er LiveCD besorgt und getestet. Ich hatte gehofft, das sei schnell erledigt, aber anders als erwartet funktionierte linux hda=remap63 hier nicht. Die CD hing sich sogar beim Booten auf. Aus der Mailingliste kamen Vorschläge, wie das Problem zu lösen sei.
* Mit linux load=ide-generic funktionierte der Start dann, aber der Diskmanager wurde nicht erkannt, selbst wenn ich mein hda=remap63 oder weitere Parameter dranhängte.
* Dann probierte ich, die heruntergeladene 6.3-LiveCD-ISO-Datei direkt zu starten. Dazu musste der Bootmanager (GRUB) entsprechend dem README auf der LiveCD modifiziert werden. Ich habe den Start per ISO zwar hinbekommen, aber der Rechner hing wieder während des Bootvorgangs. Die Übergabe entsprechender Bootparameter (s.o.) hat hier nichts bewirkt.
* Der dritte Test betrifft das erste Megabyte der Festplatte in dem auch der Diskmanager sitzt. Diese Daten wurden in eine extra Datei exportiert, die ich dann zur Analyse hochgeladen habe.

Neu gelernt:
* lspci gibt Informationen über die PCI-Schnittstellen aus.
* Mit dd kann man ganz einfach Rohdaten kopieren wobei Outputfile und Inputfile sehr dehnbare Begriffe sind.
* Bei GRUB wird die RAMDisk dem Kernel mit initrd=(Partition-in-GRUB-Nomenklatur)/Pfad-zur-RAMDisk-auf-der-Partion/RAMDisk-Dateiname bekannt gegeben (z.B. initrd=(hd0,7)/boot/INITRAMFS_DATA_CPIO.GZ).
* Auch wenn ein Diskmanager nicht erkannt wird, kann man einzelne Partitionen mounten, wenn man weiß, wo sie liegen, z.B. hat mount -t vfat -o loop,offset=64512 /dev/hda /mnt die Partition gemountet, die beim Diskmanager als erste primäre Partition eingetragen ist. (Jetzt muss ich nur noch herausfinden, was ein loop device ist.) [Nachtrag vom 08.10.07: Unter einem loop device versteht man bei Linux üblicherweise eine Datei, die das Abbild eines Gerätes enthält, zum Beispiel das ISO einer CD. Das loop device kann in das Dateisystem eingehängt werden wie jedes andere Gerät.]

04.09.07
Die Analyse des ersten MB der Festplatte ergab, dass die Ursache des Problems nicht bei der Festplatte liegt, sondern an der mangelnden Zusammenarbeit des neuen Kernels mit dem Computertyp. Wenn ich es richtig verstanden habe, weil der IDE-Controler nicht auf dem PCI aufsetzt. Aus diesem Grund half load=ide-generic auch beim Booten der CD.

07.09.07
Die Ursache ist mit Hilfe zweier Testkernel aus der Mailingliste nun lokalisiert: Der Kernel der 6.3er LiveCD hat eine eingebaute IDE-PnP-Erkennung. Die hat den remap63-Parameter ausgeschaltet. Deshalb muss die IDE-PnP-Erkennung auf der endgültigen LFS LiveCD wohl deaktiviert werden.

Neu gelernt:
* Die Eintragungen in der Datei menu.lst von GRUB dürfen keine Zeilenumbrüche enthalten, auch keine automatischen. Längere Eintragungen bekommen ein \ am Ende der Zeile und können dann in der nächsten Zeile fortgesetzt werden.
* Mein Computer hat 267,80 BogoMips. Das sagt zumindest mein Kernellog, das sich mit dmesg auslesen lässt. Die BogoMips geben – laut BogoMips-Mini-HOWTO – auf eine unwissenschaftliche Art an, wie schnell ein Prozessor ungefähr arbeitet. Auf die BogoMips bin ich auf der SBU-Seite gestoßen, wo man die LFS-Kompilierzeiten verschiedener Systeme vergleichen kann. Dort wird das als Systemparameter abgefragt.

10.10.07
Die Änderungen für den Diskmanager wurden nun in die aktuelle Testversion der LiveCD eingearbeitet. Die CD fährt mit linux hda=remap63 load=ide-generic ohne Probleme hoch und der Diskmanager wird erkannt. Mit dem device mapper und kpartx (kpartx ist jetzt auch auf der CD.) kann man die Partitionen auch ohne den remap63-Parameter sichtbar machen – fdisk erkennt die Partitionen dann allerdings nicht.
Vielleicht werde ich die Installation schon mit der Version 6.3 durchführen. Sie bietet den Vorteil, dass man sie direkt aus der ISO-Datei auf der Festplatte starten kann und die Festplatte ist nicht nur viel schneller als das CD-Laufwerk, sondern auch weniger störanfällig.

08.11.07
Die Festplatte ist neu partitioniert. Das wurde nötig, weil ich mehr Swap brauchte, denn weniger als 512 MB RAM oder Swap führen zu Problemen beim Kompilieren.
Ich werde die Installation wie geplant mit der Version 6.3 durchführen und zwar mit der ISO auf der Festplatte.

Neu gelernt:
Selbst wenn man Partitionen gelöscht hat, kann man den Inhalt wieder zugäglich machen, indem man die Partionen einfach neu anlegt. (Ich bin zufällig darauf gestoßen. Die Partitionen waren nicht einmal identisch, sondern bloß ähnlich. Dabei kommt es nur auf den Startzylinder an, der Endzylinder ist egal. Das dürfte damit zusammen hängen, dass die FAT am Anfang der Partition abgelegt wird.)

12.11.07
Arbeitsumgebung ohne Probleme eingerichtet.

Phase 2: Erstellung des temporären Systems

13.11.07
Das erste Paket der tool chain (binutils) ist kompiliert. Es hat etwa anderthalb Stunden gebraucht. 1 SBU ist bei mir also ca. 90 min.
Die Kompilierung von gcc ist gestartet und wird wohl heute nacht fertig werden.
[Nachtrag vom 18.01.08: Wenn man die Kompilierzeit genau bestimmen möchte, muss man die die Werte, die time { Anweisung; } für user und sys ausgibt, addieren. Der Wert für real ist größer als diese Summe, denn er beinhaltet auch die Verlangsamung durch andere Prozesse.]

15.11.07
Die Installation ist auf dem alten Rechner zwar recht langsam, aber bisher problemlos. Die im Buch angegebenen geschätzten Kompilierzeiten weichen von den durch mich gemessenen teilweise erheblich ab. gcc brauchte bei mir 11,2 SBUs statt der 9,2 im Buch und glibc 5,3 SBUs statt 7. Wenn ich mit dem 5. Kapitel durch bin, werde ich mein System bei der offiziellen SBU-Seite anmelden.
Erwähnenswert ist vielleicht noch eine kleine Besonderheit des Kapitels 5.5.1. Dort heißt es: «Der Kernel muss eine Programmierschnittstelle (API) veröffentlichen, damit die C-Bibliothek (Glibc in LFS) diese verwenden kann. Dazu werden bereinigte Versionen der C-Header verwendet, die mit den Kernelquellen ausgeliefert werden.» Das ist nicht nur eine nette Hintergrundinformation, sondern der diskrete Hinweis, dass für diesen Installationsschritt die Kernelquellen zu entpacken sind. Dann muss man in das entpackte Hauptverzeichnis der Kernelquellen wechseln und kann erst dann die API-Header installieren.
Solche Dinge sind vermutlich kein Zufall. Viele Leute, die mal LFS installiert haben, sind der Meinung, man könne zwar was dabei lernen, aber zur täglichen Arbeit sei das System ungeeignet. Dieses Urteil wird zumindest von einigen LFS-Programmierern geteilt. Deshalb kommt das Ganze gelegentlich ein bisschen lehrerhaft rüber. Das kann schon mal nervig sein.

Neu gelernt:
* Die bash bietet zwar eine ganze Reihe von Vereinfachungen und Abkürzungen – am Anfang sind die aber vor allem verwirrend.
* Copy+paste funktioniert auf der LiveCD ganz gut, wenn man in einem Terminal das LFS-Buch als HTML-Datei mit lynx öffnet, mit der linken Maustaste den gewünschten Text markiert, in ein anderes Terminal springt und den Text dort mit einem einfachem Druck auf die rechte Maustraste einfügt.

19.11.07
Ich bin heute mit dem 5. Kapitel fertig geworden. Mir sind manchmal im Nachhinein Fehler aufgefallen, z.B. hatte ich im Kapitel 5.23.1 das make install vergessen. Das ließ sich leicht korrigieren, aber was ist, wenn so ein Fehler unbemerkt geblieben ist? Vermutlich geht das Spiel dann einfach noch mal von vorn los.
Da ich bis jetzt noch keine Testsuite habe durchlaufen lassen, könnten natürlich noch jede Menge anderer ernsthafterer Fehler existieren, von denen ich noch nichts weiß. Allerdings erschien es mir nicht sinnvoll, Tests zu machen, wenn es im LFS-Buch heißt, man könne den Test zwar durchführen, es sei jedoch nicht ungewöhnlich, wenn dieser scheitere und das stelle auch kein schlechtes Zeichen dar. Wenn ich die problematischen Fehlermeldungen von den weniger problematischen unterscheiden könnte, wäre das anders, aber von diesem Punkt bin ich noch weit entfernt.

Neu gelernt:
Einer der Gründe für LFS war, mehr über Linux zu lernen. Darüber wollte ich hier auch schreiben. Leider erschließt sich mir manches erst nach und nach und vieles bleibt diffus. Dazu gehört beispielsweise der Umgang mit dem Streameditor Sed. Hier werde ich mich mal nach einer Dokumentation umsehen, die etwas Klarheit schaffen kann.
Eine Sache ist mir jedoch jetzt schon klar: Selbst wenn man sich ein eigenes Linux zusammenbaut, ob mit oder ohne LFS-Buch – der Hauptteil der Arbeit wurde von den vielen Programmierern der einzelnen Pakete geleistet, und zwar nicht nur, weil sie lauffähigen Quelltext geschrieben haben. Auf ihr Konto gehen auch die Konfigurationsdateien für die Anpassung der Pakete an meine Hard- und Software. Das erscheint mir eine noch größere Leistung zu sein. So brauche ich dem Paket nur noch ein paar Parameter zu übergeben und den Rest macht der Compiler bzw. make. Ach ja, make gehört auch zu den Programmen, bei denen sich ein Blick hinter die Kulissen zu lohnen scheint.

20.11.07
Die tool chain wurde gesichert. Im LFS-Buch heißt es dazu: «Wie Sie am besten eine Sicherungskopie von $LFS/tools erstellen, ist Ihnen als lehrreiches Experiment selber überlassen.» Das klingt recht geheimnisvoll, aber ich nehme an, ein mit tar -c erzeugtes Archiv wird es schon tun. Damit habe ich bereits mein gesamtes Windows vor dem beinahe sicheren Untergang durch die nötige Umpartitionierung am Ende von Phase 1 gerettet.

Phase 3: Aufbau des LFS-Systems

20.11.07
An dieser Stelle muss ich die Entscheidung über die zukünftige Paketverwaltung treffen. Am besten gefällt mir die Variante mit den Paket-Archiven (Kapitel 6.3.2.6). Allerdings ist das ziemlich anspruchsvoll. Es setzt ein Wissen über die Pakete voraus, über das ich einfach nicht verfüge und dass so umfangreich ist, dass ich es mir nicht einfach irgendwo anlesen kann. Bei jedem Fehler, der möglicherweise auftritt, wird sich mir die Frage stellen, ob das an der falschen Handhabung des Paketmanagements liegt, an einem Fehler in der tool chain oder vielleicht nur einem einfachen Tippfehler.
Außerdem weiß ich nicht mal, ob ich überhaupt jemals ein Paket updaten muss. Wenn das System läuft, sehe ich keinen Grund, daran herumzuspielen. Wozu brauche ich die neueste Version der Glibc oder des Kernels, wenn mein OpenOffice.org mit der alten Version gut funktioniert? Aus diesen Gründen werde ich erst einmal ohne Paketverwaltung weitermachen.
Die tool chain habe ich übrigens nicht richtig erstellt. Zumindest im Paket gzip ist ein Fehler aufgetreten, sodass ich aus der chroot-Umgebung keine gz-Tarballs entpacken konnte. Meine Lösung sah so aus:

  1. Wechsel in eine Konsole des Host-Systems (hier LFS LiveCD), Login als root
  2. Rekursive Zuordnung des Verzeichnisses tools zum Benutzer lfs mit chown -R lfs:root /mnt/lfs/tools
  3. Neue Kompilation und Installation des Paketes Gzip als Benutzer LFS in der LFS-Arbeitsumgebung, aus der ich mich noch nicht abgemeldet hatte. (Hätte ich mich bereits abgemeldet, wäre der nächste Versuch die erneute Einrichtung der Arbeitsumgebung für den Benutzer LFS gewesen.)
  4. Wechsel in eine Konsole des Host-Systems (hier LFS LiveCD), Login als root
  5. Rekursive Zuordnung des Verzeichnisses tools zum Benutzer root mit chown -R root:root /mnt/lfs/tools
  6. root kann in der chroot-Umgebung gz-Tarballs entpacken.

Glück gehabt! Ab jetzt setze ich hinter jeden ausgeführten Befehl ein Häkchen.

Verdammt! Der gleiche Mist ist mir auch mit dem Paket Grep passiert. Das configure-Skript der Glibc lief nicht. Auch hier half aber der Trick mit dem nachträglichen Installieren. Dass ich die Pakete kompiliert habe, weiß ich sicher, aber ich habe wohl das make install vergessen. Das kommt davon, wenn man müde ist und schnell fertig werden will.

Neu gelernt:
An LFS nur ausgeschlafen herumbasteln!

Ich habe mich heute im Netz nach Beschreibungen für Sed umgesehen, nachdem weder mein Linux-Handbuch («Linux in a Nutshell» – ansonsten eine sehr große Hilfe) noch die man pages erklären konnten, welche Funktion die Option -i hat. Ziemlich gut scheint die Einführung von Thomas Pircher zu sein. Als ich aber auch dort die Option -i nicht finden konnte, habe ich noch die Sed-Dokumentation der Zeitschrift «Linux User» ausgegraben. Und dort war dann endlich zu lesen, dass die Option -i bedeutet, dass die Veränderungen direkt in die angegebene Datei geschrieben werden.

23.11.07
Vorgestern ist ein weiterer Fehler aufgetreten. Die Kompilation der Glibc konnte nicht abgeschlossen werden. Ich erstelle seit gestern eine neue tool chain. Damit das nicht ganz umsonst ist, werde ich diesmal alle Befehle in einer Datei zusammenfassen, sodass ich das nächste Mal, wenn ich LFS irgendwo installieren will, nur noch die Datei starten muss.

29.11.07
Die neue tool chain ist heute fertig geworden. Im Nachhinein kam mir mehr als ein Kommando unbekannt vor. Ich habe nun aber wirklich jedes ausgeführte Kommando abgehakt und außerdem in einer extra Datei mitgeschrieben. Mal sehen, ob es geholfen hat. Ich lasse gerade die Glibc durchlaufen. Morgen habe ich das Ergebnis.
Interessant ist vielleicht noch, dass es ein Problem mit den SBUs gibt. Ich habe immer nur die Kompilierzeit gemessen – vorgesehen ist jedoch die Messung aller Vorgänge zum Bau der Pakete abgesehen vom Entpacken der Quellen. Mitbekommen habe ich das aber erst beim neunten Paket der neuen tool chain. Vielleicht hole ich die Messung nach, wenn mein LFS läuft. Eigentlich sind die SBUs ja wirklich nebensächlich, aber auf der SBU-Seite gibt es einfach noch keinen vergleichbar alten Rechner, auf dem ein neues LFS gebaut wurde. Deshalb lohnt die Mühe möglicherweise doch.

Neu gelernt:
Mittlerweile habe ich mich ein wenig mit Sed bekannt gemacht. Es ist alles recht kryptisch. Aber man muss eben in Rechnung stellen, dass das Programm bereits etliche Jahrzehnte auf dem Buckel hat und eigentlich nur ein kleines schnelles Werkzeug für die Administratoren von Unix-Systemen war. Da wurde natürlich eine Syntax verwendet, die dem C-Programmierer geläufig ist – an die Leute, die man abschätzig (l)user nannte, dachte dabei selbstverständlich niemand. Diese Nachsicht empfiehlt sich überhaupt für den Umgang mit Linux. Man kann das System zwar an jeden Benutzer anpassen, aber eigentlich ist es nichts als ein Haufen freier Unix-Programme, die seit fast 25 Jahren auf einen eigenen Kernel warten und in der Zwischenzeit einfach schon mal mit dem arbeiten, was Tausende Programmierer – warum auch immer – aus der wohl eher mittelmäßigen Minixvariante von Torvalds gemacht haben. Mittlerweile ist Linux ein richtig hübsches System, fast alle haben sich daran gewöhnt und kaum jemand redet noch von HURD. Aber die Wurzeln lassen sich immer noch erkennen.
Jedenfalls ist es gar nicht so kompliziert, Sed beizubringen, was man möchte. Das Verstehen fremder Sed-Skripte bleibt jedoch schwierig – und für jemanden, der ohnehin ein Problem mit den Algorithmen und Quelltexten anderer Leute hat, erst recht.

01.12.07
Gestern endete die Testsuite der Glibc mit einigen Fehlern. Das LFS Buch bemerkt dazu unter anderem: «Auf alter oder langsamer Hardware oder unter hoher Systemlast können einige Tests aufgrund von Zeitüberschreitungen fehlschlagen.» Und in der LFS-Mailinglist wurde für die Testsuite der Glibc die Option TIMEOUTFACTOR empfohlen. Also habe ich den Test mit make TIMEOUTFACTOR=20 -k check 2>&1 | tee glibc-check-log neu gestartet. Die Logdatei zeigte nun keine Fehler mehr an (auch nicht den erlaubten und erwarteten posix/annexc-Fehler) und der Test war viel zu schnell fertig. Also habe ich Glibc noch mal neu kompiliert und den Test mit TIMEOUTFACTOR durchlaufen lassen. Ergebnis: Alles in Ordnung!

Neu gelernt:
Die Testsuites sind auch bloß Programme, die kompiliert werden und die dazu auf die Funktionen des Programmes, das sie testen sollen, angewiesen sind. Wenn die Testprogramme ohne Fehler kompiliert werden können, bedeutet das, dass das eigentliche Paket ebenfalls ohne Fehler kompiliert wurde.

04.12.07
Es gab eine kleine Verzögerung, weil das LFS-Buch zum Teil doch etwas einsilbig ist. Bei der Konfiguration des Paketes Gcc (Kapitel 6.12.1) soll der Parameter --enable-languages=c,c++ übergeben werden. Im Kapitel 5.11.1 stand, dies hätte zur Folge, dass sowohl der C- als auch der C++-Compiler installiert würden.
Für die tool chain erschien mir das auch ausreichend, aber Gcc kann eigentlich mehr und weshalb soll die endgültige Version auf diese beiden Sprachen beschränkt werden?
Im LFS-Mailinglist-Archiv fand ich zu diesem Thema eine Diskussion aus dem Jahr 2003. Die Option wurde damals eingeführt, weil für den Bau des Basissystems nur der C- und C++-Compiler nötig sind und das Paket so schneller gebaut wird. Außerdem ermöglichte diese Beschränkung den Rückgriff auf das kleinere Gcc-Kernpaket, was den Traffic auf den LFS-Servern reduzieren sollte. Unumstritten war der Parameter allerdings nicht.
Ich wollte die Option nicht einfach weglassen, weil ich mir unsicher bin, ob die Voraussetzungen für den Bau aller Compiler erfüllt sind. Zum Glück zeigte das BLFS-Buch (Das Ding hat 1275 Seiten!) einen Ausweg: Der Compiler kann später aufgerüstet werden, wenn Bedarf besteht.
[Nachtrag vom 23.12.07: Es gibt auf der LFS-Seite einen Hint, der beschreibt, wie man bereits während des Baus von LFS weitere Compiler zu Gcc hinzufügt.]

06.12.07
Gcc ist kompiliert. Mit Testsuite hat das 2033 Minuten gebraucht. Einige Tests sind fehlgeschlagen:

In der Mailinglist der Gcc-Seite wurde dieses Problem in den letzten Jahren schon ein paar mal besprochen. Es gibt eine Reihe von Lösungsvorschlägen, die sich auf die Testsoftware DejaGNU beziehen. Aber es gibt auch die Empfehlung, die fehlgeschlagenen Tests einfach auf sich beruhen zu lassen. 2033 Minuten sind fast 34 Stunden.

07.12.07 - 08.12.07
Ich habe beschlossen, den Timeouts beizukommen.
1. Versuch: In der Datei /tools/share/dejagnu/config/sim.exp in Zeile 80 wird der Timeout von 240 auf 10000 erhöht. Wenn ich die Daten richtig interpretiere wird der Wert aus dieser Datei nur genutzt, wenn weder für das zu testende Paket, noch für das System, auf dem der Test durchgeführt wird, ein Timeout-Wert definiert ist.
Dieser Versuch ist fehlgeschlagen. Schon beim Durchlauf der Testsuite waren die Timeouts zu erkennen. Die Testsuite hat aber noch andere Informationen ausgeworfen:

Using /tools/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /tools/share/dejagnu/config/unix.exp as generic interface file for target.
Using /sources/gcc-4.1.2/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.

Target ist unix und Board ist hier wohl in etwa synonym mit System.

2. Versuch: Die Änderung in der sim.exp wurde rückgängig gemacht und der Datei /tools/share/dejagnu/config/unix.exp wird folgende Zeile hinzugefügt.

set sim_time_limit 10000

Dieser Versuch ist ebenfalls fehlgeschlagen

3. Versuch: Die Änderung in der config/unix.exp wurde rückgängig gemacht und der Datei /tools/share/dejagnu/baseboards/unix.exp wird folgende Zeile hinzugefügt.

set sim_time_limit 10000

Dieser Versuch ist fehlgeschlagen

4. Versuch: Die Änderung in der baseboards/unix.exp wurde rückgängig gemacht und in der Datei /tools/share/dejagnu/remote.exp wird in Zeile 260 der timeout von 300 auf 10000 erhöht.

[Nachtrag vom 10.01.08: Diese Änderung kann man auch durch die Eingabe des folgenden Befehls bewirken: sed -i ’s/300/10000/g’ /tools/share/dejagnu/remote.exp.]

Neu gelernt:
Das && zwischen den Befehlen (z.B. bei make && make install) wird von bash so interpretiert, dass der zweite Befehl nur dann ausgeführt wird, wenn der erste Befehl erfolgreich war.

09.12.07
Der 4. Versuch ist teilweise geglückt. Die Timeouts des gcc-Tests sind weg. Übrig bleiben dort 2 Fehler, die ich mir später ansehe. Die 6 Fehler des libmudflap-Tests sind alle Timeouts und betreffen alle den Test heap-scalestress. Mich wundert, dass 10000s (166min) dafür nicht ausreichen. Wenn ich heap-scalestress in der chroot-Umgebung allein kompiliere und dann ausführe, ist das Programm in weniger als 2min fertig. Eine weitere Erhöhung des Timeouts erscheint mir sinnlos.

Neu gelernt:
So ein Test scheint in drei Schritten abzulaufen:

  1. Lässt sich das Testprogramm kompilieren?
  2. Kann das kompilierte Testprogramm ausgeführt werden?
  3. Stimmt der Output des ausgeführten Testprogramms mit den Erwartungen überein? [Nachtrag vom 21.12.07: Der erwartete Output kann auch ein Fehler sein.]

(heap-scalestress hängt bei Schritt 2.)

14.12.12
heap-scalestress arbeitet mit einem Timeout von 300s. Ich muss herausfinden, wo und warum dieser Timeout gesetzt wird.

18.12.07
Die Timeouts sind erledigt. Die Lösung brachte eine Änderung in der 82. Zeile der Datei /tools/share/dejagnu/config/unix.exp. Aus

set status [remote_wait $dest 300]

habe ich

set status [remote_wait $dest 6001]

gemacht.

[Nachtrag vom 10.01.08: Diese Änderung kann man auch durch die Eingabe des folgenden Befehls bewirken: sed -i ’s/300/6001/’ /tools/share/dejagnu/config/unix.exp.]

Es war gar nicht so schwer, darauf zu kommen. Die Testsuite gab mir die Fehlermeldung «program timed out.» Diesen Satz habe ich mit egrep in den DejaGNU-Quellen gesucht und in der Datei remote.exp gefunden, und zwar zwei mal. Dass es sich bei remote.exp um eine Konfigurationsdatei handelte, die durch die Kompilation (im Kapitel 5.10) nicht in eine Binärdatei umgewandelt wurde, machte den Rest recht einfach. Um herauszufinden, welche der beiden Stellen verantwortlich ist, habe ich die Sätze verändert. Der erste bekam die Nummer 1 und der zweite die 2. Diese Nummern wurden zusammen mit der Fehlermeldung angezeigt. Damit konnte ich herausfinden, dass es die zweite Stelle war, die mir den Timeout bescherte. Danach wurde die zweite Fehlermeldung noch einmal ergänzt, und zwar so, dass sie mir anzeigte, auf welchen Wert der Timeout wirklich gesetzt war, wenn die Fehlermeldung kam. Damit erfuhr ich den Timeout von 300.
Jetzt habe ich wieder DejaGNU mit egrep durchsucht: Wo kommt die Zahl 300 vor? Es gab zehn interessante Stellen. An diesen Stellen habe ich statt der 300 Werte von 290 bis 299 eingetragen. Der nächste Durchlauf der Testsuite zeigte nun einen Timeout von 293 an. Damit war klar, welche Datei ich an welcher Stelle verändern musste, um den Timeoutwert so zu erhöhen, dass der libmudflap-Test genügend Zeit bekam.
Leider hat diese schöne Methode auch ihre Grenzen. Hätte dort aus irgendeinem Grund nicht die Zahl 300 gestanden, sondern z.B. (500 - 200) oder (Variable1 - Variable2) – Ein Hacker hätte jetzt (foo - bar) geschrieben. – wäre die Suche ein wenig schwieriger geworden.

Jetzt bleiben nur noch die beiden Fehler zu klären, die keine Timeouts waren. Dabei handelt es sich um die gcc-Tests fastcall-sseregparm und sse-9.

21.12.07
Ich habe vergeblich versucht, den Fehlern der Testsuite auf die Spur zu kommen. Weder in der LFS-Mailinglist noch auf der Gcc-Seite sind meine beiden Fehler jemals aufgetaucht. Genau genommen, müsste ich mich auch noch um einige XPASSes kümmern. Ein XPASS wird ausgegeben, wenn der Test wider Erwarten erfolgreich beendet wird, denn einige Tests sollen ausdrücklich mit einem Fehler enden.
Ich lasse den gcc-Test jetzt noch einmal so durchlaufen, dass der jeweilige Status möglichst ausführlich ausgegeben wird. Das geht mit make -k check-gcc RUNTESTFLAGS="-v -v -v -v". Wenn auch das keine neuen Einsichten bringt, mache ich mit dem nächsten Paket weiter. In der LFS-Mailinglist ist das die übliche Empfehlung, wenn nur einige wenige Tests fehlschlagen. Und auch auf der entsprechenden Gcc-Seite ist zu lesen: «It is normal for some tests to report unexpected failures. At the current time the testing harness does not allow fine grained control over whether or not a test is expected to fail. This problem should be fixed in future releases.» Das dürfte in etwa zeitgleich mit der Einführung der Demokratie in China erfolgen.

[Notiz: In der Datei /sources/gcc-4.1.2/gcc/testsuite/lib/gcc.exp in Zeile 145 gibt es noch einen Hinweis auf die Option timeout.]

23.12.07
Ich habe gestern einen Quasi-Absturz meines Hostsystems fabriziert. Als ich die nun etwas größere Logdatei des gcc-Tests mit joe betrachten wollte, hat es anscheinend den device mapper gehimmelt. Und der ist irgendwie daran beteiligt, die LiveCD-Iso als Dateisystem zu betreiben. Mein im Aufbau befindliches LFS lief zwar noch, aber das überlastete Hostsystem hat den Prozessor doch arg in Anspruch genommen. Einfach weiterzumachen wäre also keine gute Idee gewesen. Hätte ich joe nicht als root gestartet, sondern als anderer Benutzer, hätte ich den Prozess vielleicht abschießen können – habe ich aber nicht.
Die neue Situation bringt auch einige neue Möglichkeiten. Ich kann die fehlenden SBUs der ersten Pakete aus Kapitel 5 nun sofort herausfinden. Und weil ich jetzt sowieso einen Weg finden muss, wieder in den unterbrochenen Installationsprozess einzusteigen, kann ich mir gleich ein Skript schreiben, das das in Zukunft automatisch macht. Damit kann ich den Rechner auch einfach ausschalten, solange ich ihn nicht arbeiten lasse. Zu diesem Zweck habe ich mir schon die nötigen Informationen besorgt. Dabei bin ich auch auf Informationen gestoßen, wie man Gcc bereits während der LFS-Installation weitere Compiler hinzufügt.
Die ausführlicheren Fehlermeldungen bei fastcall-sseregparm und sse-9 besagen übrigens, dass bei der Ausführung der kompilierten Dateien eine «illegal instruction» auftrat. Vielleicht ist der Test wirklich nicht für meine Hardware geeignet. Ich werde das erst mal auf sich beruhen lassen.

Neu gelernt:
* Es macht auch beim LFS-Bau von der LiveCD Sinn, weitere Benutzer einzurichten und weitestmöglich mit diesen zu arbeiten.
* chroot führt eigentlich nur ein einziges Kommando mit dem neuen root-Pfad aus. Wenn dieses Kommando allerdings der Start einer shell ist, gilt der geänderte Pfad solange man in dieser shell arbeitet.
* Die Java- und Objective-C-Compiler können durch einfache Ergänzung des configure-Parameters enable-languages im Kapitel 6.12 zu Gcc hinzugefügt werden. Die anderen Compiler erfordern etwas mehr Aufwand und entsprechende Vorbereitungen im Kapitel 5.
* Ich hatte es schon einmal herausgefunden. Dann erschien es mir zu unwichtig, um es hier zu erwähnen. Kurz darauf habe ich es wieder vergessen. Und nun musste ich es neu suchen und jetzt wird es auch hier erwähnt: Der Befehl pwd gibt das aktuelle Verzeichnis an.

08.01.08
Ich habe die fehlenden Kompilierzeiten aus dem 5. Kapitel bestimmt und auf der SBU-Seite eingetragen. Morgen entpacke ich meine gesicherte tool chain und mache direkt bei Kapitel 6 weiter. Ein extra Skript werde ich mir dafür dann nicht schreiben.
Diesmal installiere ich auch gleich den Java-Kompiler von Gcc.

13.01.08
Ich bin jetzt wieder an der Stelle angelangt, an der ich am 23.12.07 die Installation unterbrochen hatte nur mit dem Unterschied, dass jetzt auch der Java-Compiler installiert ist. Der zusätzliche Zeitaufwand für diesen einen Compiler war beachtlich. Allein die Kompilation von Gcc benötigte fast 18 SBUs – alles zusammen dann rund 39 SBUs. Damit lasse ich Kapitel 6.12 erst einmal hinter mir.

[Nachtrag vom 14.08.08
Wenn man auch mit LFS die Copy-and-Paste-Funktion von Gpm nutzen möchte, macht es Sinn die Installation von Gpm vor dem Kapitel 6.20 des LFS-Buches (Ncurses) durchzuführen. Die Gpm-Installation ist nicht kompliziert und im BLFS-Buch sehr gut beschrieben.
Wird Gpm nicht vor Ncurses installiert, muss Ncurses später erneut kompiliert werden. Mehr Informationen finden sich bei den BLFS User Notes zum Paket Gpm.]

15.01.08
Ich bin jetzt bis zum Kapitel 6.23 gekommen. Heute war unter anderen das Paket Ncurses dran, das die Arbeit mit Textbildschirmen erleichtern soll. Ncurses bringt keine der üblichen Testsuites mit, sondern eine Reihe von Spielchen und Demos, mit denen man die Funktionen des Paketes überprüfen kann. (xmas war wohl am witzigsten.) Das geht nach Aussage der Datei INSTALL im Ncurses-Hauptverzeichnis auch, bevor man das kompilierte Paket installiert. Das LFS-Buch behauptet hier etwas anderes. Da das Testen vor der Installation allerdings mit einigen Konfigurationen verbunden gewesen wäre, habe ich doch erst installiert und dann getestet.

Neu gelernt:
* Die wichtigsten Befehle für den täglichen Umgang mit dem Linux-System befinden sich wohl im Paket Coreutils. Dort gibt es aber auch Befehle zur Primfaktorzerlegung oder zur automatischen Nummerierung von Dateizeilen.

16.01.08
Auch wenn das Paket Autoconf (Kapitel 6.26) nur eine Kompilierdauer von weniger als 0,1 SBU hat, läuft die Testsuite doch gut 3,5 SBU. Dabei werden dann allerdings noch einige Tests übersprungen, die auf das Paket Automake (Kapitel 6.27) angewiesen sind. Deshalb werde ich nach der Installation von Automake das Paket Autoconf erneut kompilieren, testen und installieren. Das ist vielleicht ein wenig übertrieben, aber mein Computer ist einfach zu langsam, um im Fall eines Fehlers alles noch mal von vorn zu machen.

18.01.08
Von dem vorgestrigen Vorhaben, das Paket Autoconf nach dem Paket Automake noch einmal durchlaufen zu lassen, habe ich Abstand genommen. Während des Tests von Automake wurden ebenfalls mehrere Tests übersprungen, weil andere Pakete fehlen. Im Appendix C des LFS-Buches werden all diese Abhängigkeiten aufgelistet. Es ist aufgrund der zirkulären Abhängigkeiten fast unmöglich, vollkommen sicher zu gehen, dass alle Pakete wirklich perfekt kompiliert wurden.
Ein wenig spannend wurde es heute im Kapitel 6.34: Grub. Die letzte Anweisung in diesem Kapitel lautet: cp -v /usr/lib/grub/i386-pc/stage{1,2} /boot/grub. Darunter steht, man solle i386 durch den auf die jeweilige Hardware passenden Ausdruck ersetzen. Das wäre in meinem Fall i586. Ein solches Verzeichnis existiert aber nicht – genau genommen ist i386-pc sogar das einzige Verzeichnis in /usr/lib/grub. Deshalb gehe ich davon aus, dass i386 auch für i586 gilt. Dafür spricht auch, dass das LFS-Buch andernfalls sicherlich i686 als Standard vorgegeben hätte.
Die nächste Frage war, welche Dateien außer stage{1,2} nach /boot/grub kopiert werden müssen. Laut LFS-Buch sind e2fs_stage1_5 und reiserfs_stage1_5 die wahrscheinlichsten Kandidaten. Nach info grub handelt es sich bei diesen Dateien um boot images. Sie werden von grub-install automatisch an die richtige Stelle kopiert. Die Einrichtung von grub im Kapitel 8.4 erfolgt allerdings interaktiv über das Programm grub und nicht automatisch durch grub-install. Leider konnte ich auf die Schnelle nicht herausfinden, woran ich erkennen kann, welches boot image ich brauche. Muss das image mit dem Dateisystem übereinstimmen, auf dem mein grub liegt? Das ist ein ext3. Soll ich dafür die Datei e2fs_stage1_5 nehmen? Wenn man alle boot images nach /boot/grub kopiert, macht man vermutlich nichts falsch. Ich werde trotzdem erst einmal versuchen, ob e2fs_stage1_5 ausreicht. Ob das so ist, erfahre ich dann in Kapitel 8.4. Notfalls tut es auch grub-install.

Neu gelernt:
Wenn man die Kompilierzeit genau bestimmen möchte, muss man die die Werte, die time { Anweisung; } für user und sys ausgibt, addieren. Der Wert für real ist größer als diese Summe, denn er beinhaltet auch die Verlangsamung durch andere Prozesse. Ich werde jetzt trotzdem bei der Messung der real-Werte bleiben. Der Unterschied ist nicht besonders groß (unter 5%).

04.04.08
Als ich vor dem Strippen (Kap. 6.58) eine Sicherheitskopie machen wollte, hat es mal wieder den device mapper ausgehebelt. Beim Wiedereinstieg in den Installationsprozess soll laut Stages-stop-and-resume-Hint der Befehl /sbin/udevstart ausgeführt werden. Diese Information trifft jedoch nur für die LFS-Version 6.6.1 zu. Seit der 6.2er gibt es den Befehl überhaupt nicht mehr. Das Verzeichnis /dev muss also anders aufgefüllt werden. Dazu orientiere ich mich am Kapitel 6.2. Demnach wird der Hauptteil der Arbeit durch ein bind mount erledigt, das allerdings nur außerhalb der chroot-Umgebung funktioniert. Der Wechsel in die chroot-Umgebung erfolgt also erst nach dem Auffüllen des dev-Verzeichnisses.
Das Strippen verlief ohne Probleme, sodass das Kapitel 6 damit erledigt ist.

[Nachtrag vom 14.08.08
Im Kapitel 6.40 Inetutils-1.5 empfiehlt das LFS-Buch die Option --disable-servers. Dabei handelt es sich unter anderen um den FTP-Server (ftpd) und den Telnet-Server (telnetd). Diese Programme mögen zwar veraltet und unsicher sein, aber um mal schnell zwei Computer miteinander zu verbinden, stellen sie wohl die einfachste Variante dar. Um diese Programme später mit LFS nutzen zu können, ohne Inetutils erneut zu kompilieren, sollte diese Option weggelassen werden.]

Phase 4: LFS wird startklar gemacht

05.04.08
Die Bootskripte sind für die spätere Arbeit natürlich von großer Bedeutung und für das Verständnis von Linux wesentlich. Leider ist das alles nicht ganz einfach zu verstehen. Gerade bei den Netzwerken habe ich noch einige Lücken, aber ich hoffe, später die richtigen Einstellungen mit ein wenig Probieren am laufenden System zu finden. Schön ist, dass die Skripte sehr schlank sind.

13.04.08
Ich habe mich in den letzten Tagen durch das Konfigurationsmenü des Kernels gewühlt. Das sind einige hundert Optionen, von denen mir mindestens die Hälfte schleierhaft ist. Dass der erste Probestart meines neuen LFS daneben ging, hat mich dann auch nicht überrascht. Bevor der Kernel überhaupt geladen wurde, stellte der Rechner die Arbeit mit den Worten «PANIC: CPU too old for this kernel.» ein. Ich hatte übersehen, dass an einer Stelle der Konfiguration der Prozessortyp eingestellt werden muss. Gerade läuft der zweite Durchgang mit verbesserter Konfiguration.
Auf die Einrichtung von Grub habe ich vorerst verzichtet. Da ich Grub schon auf dem Rechner hatte, kann ich mein LFS auch über die Grub-Kommandozeile während des Bootvorgangs starten, ohne mir eventuell zusätzliche Probleme einzuhandeln.

Neu gelernt:
* ELF steht für Executable and Linkable Files. Das sind ausführbare Programme sowie Bibliotheken.
* Es gibt die Möglichkeit, den Kernel mit einer zufällige Konfiguration zu kompilieren – keine Ahnung, wozu.

14.04.08
Nachdem ich den zweiten Kernel an Ort und Stelle gebracht und die Bootskripte noch einmal durchgesehen habe, ist mein neues LFS heute ohne weitere Probleme hochgefahren.
Die Schwierigkeiten mit dem Kernel gingen wirklich auf die falsche Prozessoreinstellung zurück, und bei den Bootskripten hatte ich übersehen, dass es bei LFS ein Bootskriptpaket gibt, das noch installiert werden musste.
Das neue Grub-Menü ist nun ebenfalls eingerichtet. Da ich das Modul ide_generic in den Kernel kompiliert habe, muss nur noch hda=remap63 als Kernelparameter übergeben werden.

Jetzt folgen noch ein paar Kleinigkeiten wie die Eintragung der restlichen Kompilierzeiten auf der SBU-Seite, Anlegen einer Sicherheitskopie des neuen LFS, Einstellungen an der Shell u.s.w. Danach versuche ich, die Hardware vollständig zum Laufen zu bekommen (Audio, Infrarot, PCMCIA-Ethernetkarte), noch ein paar hilfreiche Programme zu installieren (z.B. Joe und Gpm) sowie eine passende grafische Oberfläche zu finden.

Phase 5: Test und Einrichtung des LFS

28.05.08
Nachdem ich verschiedene mehr oder weniger umständliche Methoden zur Sicherung meines LFS ausprobiert habe, stellte sich heraus, dass es auch einen sehr einfachen Weg gibt: tar cpvj --one-file-system --atime-preserve --file=<Name der Zieldatei> / .
Die Zieldatei darf ruhig auf der LFS-Partition liegen, tar kann damit umgehen. Das einzige, was bei dieser Sicherung fehlt, sind die Gerätedateien /dev/console und /dev/null, die aber in einem zweiten Schritt an das Archiv angehängt werden können. Es ist aber natürlich auch möglich, diese beiden Dateien nach den Anweisungen im Kapitel 6.2.1 des LFS-Buches neu zu erstellen, wenn das Backup zurückgespielt werden muss. Wenn das Verzeichnis /sources viele Daten enthält, die leicht ersetzbar sind, werde ich es vermutlich von der Archivierung ausschließen.

Neu gelernt:
* Es lohnt sich, den einfachsten denkbaren Weg zuerst auszuprobieren.
* LFS lässt sich ohne große Probleme stark verkleinern. Wer auf alle Programme unter /usr verzichten kann, erhält in wenigen Sekunden durch einfaches Löschen aller enthaltenen Dateien bereits ein 18,5 MB großes Linux, das z.B. für die Sicherung des LFS oder die Rückspielung des Backups hinreichend gerüstet ist. Unschön ist lediglich, dass es beim Start zwei Fehlermeldungen gibt, weil die LFS-Bootskripte die Programme syslogd und klogd aus dem Verzeichnis /usr/sbin aufrufen. Werden diese beiden Programme von insgesamt 49 KB nach /usr/sbin kopiert, verläuft der Start fehlerfrei. Selbstverständlich können auch die Bootskripte geändert werden.
Eine weitere Verkleinerung des Mini-LFS ist möglich. Alle unnötigen Programme in /bin und /sbin können gelöscht werden. Welche Bibliotheken die verbleibenden Programme brauchen, lässt sich mit ldd feststellen – die anderen kommen ebenfalls weg. Der Kernel kann auf das Nötigste beschränkt werden.
Etwas aufwendiger ist der Einsatz von uclibc anstelle der Glibc, da hier alle benötigten Pakete mit der tool chain neu kompiliert werden müssen. Dabei kann gleich die BusyBox zu Einsatz kommen, die das MiniLFS noch kleiner macht.

02.07.08
Das nächste kleinere Projekt ist die Einrichtung des Netzwerks.
Damit der PCMCIA-Steckplatz des Notebooks benutzt werden kann, muss dem Kernel der Steckplatztreiber hinzugefügt werden. Bei meinem COMPAQ 5300 mit dem Cirrus-Logic-PCMCIA-Sockel PD6722 war es das Modul i82365. Ich habe mich für die statische Variante entschieden und den Kernel neu kompiliert. Das Einschieben und Entfernen der Karte wurde nun problemlos erkannt und die Karte mit Strom versorgt.
Auch das Modul für die PCMCIA-Netzwerkkarte – bei meiner D-Link DFE-670TXD war es das Modul pcnet_cs (NE2000) – befindet sich nun im Kernel.
Damit ist es aber noch nicht getan. Bei den Kernels neuer als 2.6.13 erfolgt die Verwaltung der PCMCIA-Karten mittels pcmciautils. Dieses Paket erfordert seinerseits das Paket sysfsutils. Nach der Installation dieser beiden Pakete wird beim Start folgende Meldung ausgegeben: eth0: NE2000 (DL10022 rev 30): io 0x300, irq 3, hw_addr 00:11:95:23:91B3. Der Kartentreiber wurde nun also eth0 zugeordnet. Ein Gerät /dev/eth0 existiert allerdings nicht und wird auch später nicht mehr erzeugt werden! Die Karte taucht aber als /sys/bus/pcmcia/devices/0.0 auf. Das ist ein Link auf /sys/devices/platform/i82365.0/0.0 . Außerdem werden durch pcmciautils beim Start einige Adressen für den PCMCIA-Steckplatz reserviert. Welche Adressen das sind, wird in der Datei /etc/pcmcia/config.opts festgelegt. Da ich nicht alle Adressen benötige, habe ich die anderen auskommentiert.
Der letzte Schritt ist die Erstellung der Dateien /etc/sysconfig/network-devices/ifconfig.eth0/ipv4 und /etc/resolv.conf gemäß den Kap. 7.13.2 und Kap. 7.13.3 des LFS-Buches. Damit wird eth0 gestartet, eine IP-Adresse zugewiesen, der Standardgateway festgelegt und eine Verbindung ausgehandelt.

Wenn ich nun den Computer mit eingesteckter und an den Router angeschlossener Karte starte, komme ich mit Lynx ohne Probleme ins Netz. Ein paar Probleme müssen allerdings noch gelöst werden: Wenn die Karte beim Start noch nicht eingesteckt ist, wird eine Fehlermeldung ausgegeben, dass eth0 nicht existiert und nach dem Einstecken der Karte wird die Netzwerkverbindung zum Gateway noch nicht automatisch aufgebaut.

Neu gelernt:
Um eine PCMCIA-Karte unter LFS zum Laufen zu bringen sind folgende Schritte nötig:

  1. Finden des richtigen Moduls für den Steckplatz, Anpassung der Kernelkonfiguration
  2. Finden des richtigen Moduls für die Karte, Anpassung der Kernelkonfiguration
  3. Neukompilation des Kernels, damit die Module aus 1. und 2. verwendet werden können
  4. Installation von sysfsutils und pcmciautils, die nicht in LFS enthalten sind
  5. Anpassung der Netzwerkkonfiguration gemäß Kap. 7.13.2 und Kap. 7.13.3 des LFS-Buches

13.07.08
Ich habe in der letzten Woche die Soundkarte eingerichtet und danach gleich noch einen MP3-Player. Speaker-test aus den Alsatools meldete zwar falsche Parameter, aber die Musik lief trotzdem. Ein Problem gibt es allerdings: Schon das Abspielen von MP3s bringt den Prozessor an seine Grenzen. Laut top werden dafür 90% der Rechenkapazität beansprucht. Da bleibt für den Rest nicht viel Platz.

14.08.08
In der letzten Zeit habe ich mich ein wenig mit dem Netzwerk beschäftigt. Dabei fiel mir auf, dass das LFS-System zwar geeignet ist, als FTP- oder Telnet-Client zu arbeiten, aber nicht als Server. Die Ursache liegt im Kapitel 6.40 des LFS-Buches (Inetutils). Mit der Option --disable-servers wurde hier die Installation der Server unterdrückt, da diese als veraltet und unsicher gelten. Das war allerdings kein allzugroßes Problem, da ich den Computer, zu dem ich die Verbindung herstellen wollte, leicht als FTP-Server einrichten konnte. Für meine Zwecke scheint SSH ohnehin am besten geeignet, weil ich damit entfernte Dateisystem in meinen Verzeichnisbaum einhängen kann.
Außerdem habe ich heute endlich Gpm installiert, weil es ansonsten nur eine Frage der Zeit sein kann bis ich irgendeinen Tippfehler mache. Bei der Gpm-Installation bin ich den User Notes gefolgt und habe Gpm mit der Option --without-curses installiert und danach noch einmal Ncurses wie bereits im Kapitel 6.20 des LFS-Buches angegeben kompiliert und installiert.

Neu gelernt:
Das FTP-Programm von Inetutils kann nur mit Dateien <2GB arbeiten. Dieses Problem lässt sich umgehen, indem man die Dateien mit split aufteilt und nach der Übertragung wieder mit cat zusammensetzt.

26.10.08
Bei eingesteckter Netzwerkkarte trat häufig die Fehlermeldung eth0: interrupt(s) dropped! auf. Als Ursache stellte sich die alte Hardware heraus, die kein APIC (Advanced Programmable Interrupt Controller) besitzt. Mit APIC können die Interrupts flexibler vegeben werden als mit den äteren XT-PICs. Üblicherweise gibt man noapic als Kernelparameter an, um Linux klarzumachen, dass APIC nicht vorhanden ist. In meinem Fall half das nicht, sondern der Parameter nolapic (= no local apic) war erforderlich.

Neu gelernt:
Die Verteilung der Interrupts lässt sich unter /proc/interrupts einsehen.

09.11.08
Nachdem ich so ein wunderschönes LFS auf meinem LTE 5300 eingerichtet habe, musste ich einsehen, dass die Rechenleistung für das Betriebssystem zwar locker ausreicht, mit weiteren Anwendungen aber hoffnungslos überfordert ist. Weil ich jedoch weiterhin das Ziel habe, LFS zu meinem Alltagssystem zu machen, musste ich die Hardware aufrüsten und habe mir ein IBM T41 zugelegt.
Damit werde ich ein neues LFS bauen. Diese Seite ist damit abgeschlossen.

Fazit

Kann man mit wenigen Grundkenntnissen ein LFS bauen?

Ja, wenn man eine Menge Interesse, Zeit und Geduld mitbringt.

Was kann man dabei lernen?

Eine ganze Menge – jedenfalls dann, wenn nicht immer alles glatt geht. Denn am meisten habe ich immer dann gelernt, wenn irgendetwas nicht erwartungsgemäß lief. All die kleinen Schwierigkeiten, die sich mir immer wieder in den Weg stellten, waren ein gut dosierter Anreiz, mich näher mit den Zusammenhängen im Hintergrund zu befassen. Eine problemlose LFS-Installation hätte mir nicht einmal halb so viel gebracht.

Zunächst habe ich eine Menge technische Details erfahren: Neue Befehle und ihre Feinheiten, die Aufgaben der einzelnen Pakete, wo ihre Dateien liegen, warum DejaGNU auf Tcl angewiesen ist usw. Das gab mir schon mal das gute Gefühl, dass jede Datei auf meiner Festplatte – oder zumindest der überwiegende Teil davon – dort seine Existenzberechtigung hat.
Dann habe ich einigermaßen überrascht festgestellt, welche Möglichkeiten GNU/Linux bietet, und was ich bereits mit den wenigen Paketen der tool chain bewirken kann.
Beides zusammen hat mir geholfen, GNU/Linux so zu akzeptieren, wie es ist – mit all den ganzen Kommandos und Optionen, die mir früher so überflüssig erschienen. Für mich als reinen Anwender waren sie in der Tat überflüssig, doch sobald ich mit LFS mein System in die eigenen Hände nahm, wurden sie sehr nützlich. Die großen Distributionen von heute gelten als sehr anwenderfreundlich. Vielleicht ist das so. Sicher ist jedoch, dass sie mir den Blick darauf versperrten, dass GNU/Linux eigentlich kein fertiges Endprodukt ist, sondern vor allem ein äußerst vielfältiges Werkzeug.

Einige Links

Die offiziellen Seiten

Die Homepage von Linux From Scratch

Die deutsche Übersetzung von Linux From Scratch

SBU-Seite mit den Listen der benötigten Zeit für das Kompilieren der einzelnen Pakete in unterschiedlichen LFS-Versionen auf unterschiedlichen Systemen,
unter denen nun auch mein System zu finden ist.

Erfahrungen von anderen mit Linux From Scratch, geschrieben in deutscher Sprache, geordnet nach Aktualität (zuletzt überprüft am 21.04.08)

Erfahrungen mit Hardened Linux From Scratch und Cross Linux Form Scratch von:
Ingo Wiarda (aktuell) und
Stefan Rother (08.06.06).

01.12.06
Artikel von Thomas Leichtenstern unter linux-user.de über die Installation von der LFS-Live-CD.

Unvollendeter Bericht / unvollendete Installation von mischka:
Teil 2 (10.09.06)
Teil 1 (27.08.06).

13.03.06
Martin Wiesinger, der ohne große Schwierigkeiten sein LFS installierte und mit Beyond Linux From Scratch weitergemacht hat:
Link zur Startseite, dann in der Navigation bei «Linux from Scratch» klicken oder
direkt zu seiner LFS-Seite, aber ohne Navigation.

05.03.06
Seite von Jörn Abatz mit einem Projekt zum Paketmanagement unter LFS und einem gut verständlichen Informationsangebot zur Praxis mit Linux-Software.

16.01.06
Seite aus dem Blog von Ronald Schaten, der LFS problemlos an zwei, drei Abenden auf einer Virtuellen Maschine installierte und nicht glaubt, dass man durch die Installation von LFS zu grundlegenden Erkenntnissen über Linux gelangt.

18.10.05
Jens Gutzeit, der sich vor allem mit der Kompilierdauer auf unterschiedlichen Systemen befasst.

15.04.04
LFS-Buch-nahe, ausführliche Dokumentation einer Projektarbeit an der FH Augsburg über die Installation von LFS 5 auf einem 600-MHz-Rechner im Netzwerk, die wegen Bootloaderproblemen unvollendet blieb.
Auf den Seiten der FH Augsburg finden sich auch weitere Informationen zu LFS.

11.12.03
Anfrage von mrsuicide bei www.linuxforen.de zu Erfahrungen mit LFS und jede Menge Antworten.

11.06.02
Tagebucheintrag von Erwin Dogs bei www.linux-community.de.

05.10.01
Forumsbeitrag von Moe, der LFS empfielt, allerdings nur für erfahrene Benutzer.

Wer selber Erfahrungen mit Linux From Scratch gesammelt und bereits im Netz veröffentlicht hat, kann hier einen Link auf seine Seite setzen lassen.
Wer seine Erfahrungen zwar veröffentlichen möchte, aber keinen eigenen Webspace hat, kann seine Notizen direkt hier einstellen.
Die Emailadresse ist im Impressum zu finden.