SysV Init

Aus VDR Wiki
(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
(4. initrd)
(4. initrd (optional))
Zeile 22: Zeile 22:
 
Wie gesagt, der Kernel weiss nichts von den Platten. Deshalb schiebt ihm der Bootloader eine temporäre Partition unter, in der der Kernel die Module findet, die initrd. Auf der initrd ist ein gewöhnliches Dateisystem enthalten und sind die Kernel Module zum Zugriff auf das root Dateisystem gespeichert. Von dort kann der Kernel also während des Bootens seine Module laden. Danach kennt er dann die Festplatten und Partitionen.
 
Wie gesagt, der Kernel weiss nichts von den Platten. Deshalb schiebt ihm der Bootloader eine temporäre Partition unter, in der der Kernel die Module findet, die initrd. Auf der initrd ist ein gewöhnliches Dateisystem enthalten und sind die Kernel Module zum Zugriff auf das root Dateisystem gespeichert. Von dort kann der Kernel also während des Bootens seine Module laden. Danach kennt er dann die Festplatten und Partitionen.
  
Wer neugierig ist, was auf einer initrd zu finden ist kann diese mit gzip entpacken und anschließend mit dem loop device mounten. Ebenso ist es auf diese Weise möglich, einer initrd weitere Module hinzuzufügen. Anleitingen gibt es dazu reichlich im Netz.
+
Wer neugierig ist, was auf einer initrd zu finden ist kann diese mit gzip entpacken und anschließend mit dem loop device mounten. Ebenso ist es auf diese Weise möglich, einer initrd weitere Module hinzuzufügen. Anleitungen gibt es dazu reichlich im Netz.
  
 
===5. /-Partition===
 
===5. /-Partition===

Version vom 14. Oktober 2007, 11:13 Uhr

Inhaltsverzeichnis

Einleitung

Diese Seite gibt einen groben Überblick über die Startscripte eines linux Systems mit System V Init Scripten.

Hinweis
Hinweis

Achtung: Jedes Linux System hat Besonderheiten bei den Bootvorgängen! Nicht jedes System verwendet SysV Scripte und selbst Systeme damit unterscheiden sich u.U. sehr stark!


Der Bootvorgang

Hinweis
Hinweis

Diese Darstellung ist sehr stark vereinfacht und bezieht auf ein vollständig installiertes System mit allen vorhandenen Dateien. Im Falle des Fehlens einer dieser Dateien sieht die Reihenfolge u.U. völlig anders aus.


Boot Prozess unter Linux x86

1. BIOS

Beim Einschalten des PCs wird das BIOS ("Basis Betriebssystem", engl. Basic I/O System) gestartet. Dieses führt rudimentäre Checks durch (Prozessor vorhanden, Hauptspeicher und auch evtl. Bootdevices) und sucht dann auf dem ersten gefundenen Boot Device nach einem Master Boot Record (MBR).

2. MBR

Dieser MBR ist auf einem bootfähigen Device (Festplatte, USB-Stick etc.) immer an der gleichen Stelle gespeichert, so dass das BIOS ihn problemlos finden kann. Im MBR steht ausführbarer Bootcode, der für gewöhnlich auf einen Bootmanager in einer als startbar gekennzeichneten Partition verweist. Der Bootmanager (Lilo, Grub, Windows Bootmager, ..) wird also geladen und ausgeführt. Je nach verwendetem Betriebssystem (DOS, Windows, Linux) macht der Bootmanager etwas anderes. Unter Lilo/Grub liest er seine Konfiguration ein und stellt ggf. ein Bootmenü mit möglichen Einträgen dar. Ist das ein Linux, sucht er den angegebenen Kernel (Lilo blockorientiert, Grub bereits Dateisystem) und lädt diesen.

3. Kernel

Der Kernel wiederum wird geladen, weiss aber über die BIOS Funktionalität hinaus noch nichts von seinen Festplatten (und deren Controllern). D.h. ohne die richtigen Treiber/ Module kann der Kernel nicht auf die eigentliche /-Partition zugreifen.
Deshalb muss der Kernel zum Zugriff auf die root Partition benötigte Module fest einkompiliert haben oder über eine initrd verfügen in der diese benötigten Kernelmodule und Programme bereits enthalten sind.

4. initrd (optional)

Wie gesagt, der Kernel weiss nichts von den Platten. Deshalb schiebt ihm der Bootloader eine temporäre Partition unter, in der der Kernel die Module findet, die initrd. Auf der initrd ist ein gewöhnliches Dateisystem enthalten und sind die Kernel Module zum Zugriff auf das root Dateisystem gespeichert. Von dort kann der Kernel also während des Bootens seine Module laden. Danach kennt er dann die Festplatten und Partitionen.

Wer neugierig ist, was auf einer initrd zu finden ist kann diese mit gzip entpacken und anschließend mit dem loop device mounten. Ebenso ist es auf diese Weise möglich, einer initrd weitere Module hinzuzufügen. Anleitungen gibt es dazu reichlich im Netz.

5. /-Partition

Durch den Uebergabeparamter des Bootmanagers weiss der Kernel nun, wo seine /-Partition ist und wird diese entsprechend mounten. Natuerlich muss das Modul fuer das richtige Dateisystem ebenfalls im Kernel/ initrd enthalten sein!

6. init

Nun greift der Kernel auf das Dateisystem zu und laedt die Datei /sbin/init. Diese Datei wiederum fuehrt nun den eigentlichen Bootprozess jenseits des Kernels durch, fuehrt also die init-Skripte aus, liest die /etc/fstab und mountet die verbleibenden Dateisysteme und startet die notwendigen Login-Programme (getty etc.).

Die Verzeichnisstruktur in /etc/rc.d

init.d

Dieses Verzeichnis enthält die scripte, die von SysV ausgeführt werden sollen. Diese scripte sind für nahezu jedes Linux individuell, aber sie haben Gemeinsamkeiten:

  • Parameter start (wird beim Entern des jeweiligen Runlevels ausgeführt)
  • Parameter stop (wird beim Verlassen des jeweiligen Runlevels ausgeführt)
  • meist den Parameter status (optionale Statusabfrage)

rc<RUNLEVEL>.d

Dieses Verzeichnis sollte *nur* Verweise auf die scripte in init.d enthalten. Alle symbolischen Links hier sind nach folgenden Konventionen benannt:

  • K<NUMMER><SCRIPTNAME> => ../init.d/<SCRIPTNAME>

Wird beim Verlassen des Levels in der Reihenfolge der Nummern aufgerufen und ruft das script mit 'stop' auf.

  • S<NUMMER><SCRIPTNAME> => ../init.d/<SCRIPTNAME>

Wird beim Entern des Levels in der Reihenfolge der Nummern aufgerufen und ruft das script mit 'start' auf.
Die Runlevel haben folgende Bedeutung:

  • 0: Stop des Systems
  • 1: single user (Administration), Dateisysteme gemountet
  • s: wie 1, aber ohne multi-user Dateisysteme
  • 2..4: normalerweise identisch, multi user, default meist 2 oder 3
  • 5: multi user mit grafischer Oberfläche (X11)
  • 6: Reboot
  • 7..f: meist unbenutzt/nicht existent

Level 2..5 werden bei einigen Distris anders gehandhabt.

rcsysinit.d

wie vor, wird jedoch vorher aufgerufen.


Aktuelle Runlevel abfragen

Mittel des Befehl runlevel lässt sich ermitteln in welchen SysV Init Level das eigene System läuft.

runlevel


Runlevel wechseln

Ein anderer als aktuelle Runlevel kann mit init <RUNLEVEL> erreicht werden. Um in Runlevel 3 zu wechseln :

init 3

bzw.

telinit 3