ABSTRACT: der bootvorgang eines linux systems wird erklaert. AUDIENCE: junior admin SYSTEM: linux SECTION: basic unix commands AUTHOR: mond COPYRIGHT: GNU Free Documentation Licence http://www.gnu.org/licenses/fdl.txt zum guten verstaendniss wie unser betriebsystem so arbeitet gehoert auch zu verstehen wie es bootet. vorallem wenn das system mal aus irgend einem grund nicht starten will ist es wichtig zu verstehen wie der startvorgang (booten) ablaeuft.. es gibt tausende moeglichkeiten ein linux zu booten.. es besteht in so einem fall also kein grund zur panik... booten ist an und fuersich ein ziemlich heickler vorgang: das system das noch gar nicht laeuft muss von festplatten lesen von denen es noch gar nicht weiss wie es sie anspricht und files lesen von denen es noch gar nicht weiss wie sie in einem filesystem organisiert sind...etc..etc.. die aufgabe erinnert einwenig an den versuch baron muenchhausens sich an den haaren aus dem sumpf zu ziehen... im englischen sprachraum sagt man: "an den stiefen (bzw schnuersenkeln) aus dem sumpf ziehen"... daher kommt auch der name "boot strapping" ) wir koennen den bootvorgang in folgende phasen unterteilen: 1. BIOS phase: BIOS nennt man das programm das fix in auf einem ROM speicher am motherboard eingebrannt ist. das BIOS hat relativ primitive funktionen eingebaut die es erlauben die ersten paar bloecke einer harddisk oder floppy zu lesen. je nachdem was man im BIOS setup ausgewaehlt hat kann liest es einen dieser datenbloecke und startet den datenblock als programm an. (moderne BIOSe koenne auch von CD oder netzwerk booten. erweiterungen des BIOS koennen auch auf ROM speichern in erweiterungskarten liegen - damit kann man z.b. auch von einem SCSI controller booten ...) 2. boot loader: das programm dass da von floppy oder dem ersten harddisk block gelesen ist ist sehr kurz.. einige hundert bytes lang und kann keine komplexen aufgaben bewaeltigen.. es muss funktionen die das BIOS zur verfuegung stellt benuezten um weitere datenbloecke zu laden... und diese wieder anzustarten.. so kann man komplexere funktionen in den BOOT loader integrieren.. ziel des bootloaders ist den "kernel" in den RAM speicher zu laden und anzustarten. 3. kernel phase: der linux kernel wenn er vom boot loader in den RAM speicher geladen und angestartet wurde entpackt sich zuerst selbst und testet und init alisiert dann die hardware.. das sind die ganzen zeilen die beim booten ueber den bilschirm laufen.. 4. root filesystem mounten: als lezte aufgabe mountet der kernel das "/" root filesystem und startet ein programm an. wenn sonst nichts angegeben ist ist das das programm /sbin/init. init wird somit der prozess mit der nummer 1. manche boot loader erlauben es dem kernel parameter mit zu uebergeben. dann kann man mit dem parameter INIT= ein anders programm angeben. z.b. INIT=/bin/bash wuerde dem kernel sagen dass er als erstes programm direkt eine shell starten soll. (das ist manachmal ganz praktisch.. wenn sonst nichts mehr geht..) 5. startup scripts: init liest das file /etc/inittab und startet die darin aufgelisteten programme und scripts. init kann verschiedenen "runlevel" verwalten und verschiedenen scripts nur auf verschiedenen runleveln starten etc... aufgabe der startup scripts ist es z.b. weitere harddisks laut /etc/fstab zu mounten.. IP addressen auf netzwerkkarten zu sezten.. daemons zu starten..etc..etc.. obiges schema hat noch einen kleinen hacken: da der kernel das root filesystem selbst mounten muss kann der treiber dieses geraetes (z.b. ein exotischer SCSI controler oder aehnliches) natuerlich NICHT als modul geladen werden.. weil um module laden zu koennen muesste er ja auf eben dieses geraet schon zugreiffen koennen... .. das ist natuerlich unpraktisch fuer die hersteller von distributionen weil dann kernels haben muessen die sehr viele geraete schon fix einkompiliert haben... um das problem zu loesen gibt es eine stufe 4.a: 4a. initrd: anstatt das "/" root filesystem von einer harddisk zu mounten wird eine RAM disk gemountet die schon vorher in phase 2 vom boot loader mit dem selben mechanismus in den speicher geschrieben wurde wir der kernel selbst. die ramdisk ist gross genug um viele module zu enthalten. es wird das passende modul geladen um auf das echte "/" filesystem zugreiffen zu koennen. die programme in der initrd umgebung mounten dieses und dann geht alles wie gewohnt bei 5. weiter.. man kann aber in dieser initrd umgebung schon alles machen was man im echten linux machen kann.. (sofern die entsprechenden programme halt in der RAM disk platz haben..) die hersteller von distributionen verwenden daher die initrd umgebungen sehr gerne.. hat man sich seinen eigenen kernel compiliert der alles fix einkompiliert hat was man braucht kann man aber auf initrd verzichten.. in der naechsten CD folge lernen wir dann welche verschiedenen bootloader fuer linux existieren und wie wir diese benutzen um unser system zu booten. EXERCISES: * rebootet dein system und versuch anhand der meldungen am bildschirm zu sagen ab wann welche phase erreicht ist. REFERENCES: