SysV Init

Aus VDR Wiki
Wechseln zu: Navigation, Suche

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 Kernel Module kann der Kernel nicht auf die eigentliche Root Partition "/" zugreifen.

Hinweis
Hinweis

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. Mounten der root Partition "/"

Durch den Übergabeparameter des Bootmanagers weiss der Kernel, wo seine Root Partition ist und wird diese mounten. Natürlich müssen die benötigten Module für das richtige Dateisystem und die Treiber für IDE/SATA/SCSI-Hardware ebenfalls im Kernel oder der (optionalen) initrd enthalten sein!

6. init

Nun greift der Kernel auf das Dateisystem zu und startet das Programm /sbin/init. Dieser Init-Prozess steuert nun den eigentlichen Bootprozess des Linuxsystems.

Hinweis
Hinweis

Falls /sbin/init nicht gefunden werden kann, wird /sbin/sh gestartet. Werden beide nicht gefunden wird eine kernel panic ausgelöst. Falls der Kernel nicht auf das angegebene root Dateisystem zugreifen kann (falsche Partition, fehlende Module) aus diesem Grunde ebenso.


Init lädt die Konfigurationsdatei /etc/inittab, aus der hervorgeht welcher runlevel gestartet werden soll (Eintrag initdefault) und welches Programm dafür verantwortlich ist (für gewöhnlich /sbin/getty). Init startet rc, welches die init-Skripte des jeweiligen Runlevels nach aufsteigender Nummerierung ausführt. Auf diese Art und Weise werden über die /etc/fstab die verbleibenden Dateisysteme gemountet, benötigte Daemons gestartet etc. Zum Schluss startet init 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