SysV Init

Aus VDR Wiki
(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
(init.d)
 
(24 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
==Einleitung==
 
==Einleitung==
Diese Seite gibt einen groben Überblick über die Startscripte eines linux Systems mit System V Init Scripten.
+
Diese Seite gibt einen groben Überblick über die Startskripte eines Linux Systems mit System V Init Skripten.
 
{{Box Hinweis|
 
{{Box 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!'''
+
'''Achtung: Jedes Linux System hat ''Besonderheiten'' bei den Bootvorgängen! Nicht ''jedes'' System verwendet SysV Skripte und selbst Systeme damit unterscheiden sich u.U. sehr stark!'''
 
}}
 
}}
 
==Der Bootvorgang==
 
==Der Bootvorgang==
Zeile 8: Zeile 8:
 
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.
 
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.
 
}}
 
}}
*BIOS wird geladen
+
'''''Boot Prozess unter Linux x86'''''
*BIOS durchsucht Master Boot Record des Boot Devices
+
===1. BIOS===
*auf der ersten als bootbar gekennzeichneten Partition wird Bootcode ausgeführt
+
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 eventuell Bootdevices) und sucht dann auf dem ersten gefundenen Boot Device nach einem Master Boot Record (MBR).
*Bootcode lädt Bootloader (lilo, grub)
+
 
*Bootloader verweist auf Kernel und übergibt optional Parameter (/, Kernelparameter)
+
===2. MBR===
*Kernel startet ''init'' (als fallback Option gäbe es noch /bin/sh, aber das ist hier unwichtig)
+
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 gegebenenfalls 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.
*init lädt lädt die Konfigurationsdatei /etc/inttab
+
 
*in inittab ist ein Runlevel als ''initdefault'' eingtragen, dieser wird gestartet
+
===3. Kernel===
*init ruft rc auf, welches die script im jeweiligen Runlevel entsprechend der Nummerierung aufruft
+
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.<br>
*init ruft getty auf, welches den login ermöglicht
+
{{Box 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.
 +
 
 +
{{Box 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 eingebunden, benötigte Daemons gestartet etc. Zum Schluss startet init die notwendigen Login-Programme (getty etc.).
  
 
==Die Verzeichnisstruktur in /etc/rc.d==
 
==Die Verzeichnisstruktur in /etc/rc.d==
 
===init.d===
 
===init.d===
Dieses Verzeichnis enthält die scripte, die von SysV ausgeführt werden sollen.
+
Dieses Verzeichnis enthält die Skripte, die von SysV ausgeführt werden sollen.
Diese scripte sind für nahezu jedes Linux individuell, aber sie haben Gemeinsamkeiten:
+
Diese Skripte sind für nahezu jedes Linux individuell, aber sie haben Gemeinsamkeiten:
 
*Parameter '''start''' (wird beim Entern des jeweiligen Runlevels ausgeführt)
 
*Parameter '''start''' (wird beim Entern des jeweiligen Runlevels ausgeführt)
 
*Parameter '''stop''' (wird beim Verlassen des jeweiligen Runlevels ausgeführt)
 
*Parameter '''stop''' (wird beim Verlassen des jeweiligen Runlevels ausgeführt)
Zeile 28: Zeile 48:
  
 
===rc<RUNLEVEL>.d===
 
===rc<RUNLEVEL>.d===
Dieses Verzeichnis sollte *nur* Verweise auf die scripte in init.d enthalten.
+
Dieses Verzeichnis sollte *nur* Verweise auf die Skripte in init.d enthalten.
 
Alle symbolischen Links hier sind nach folgenden Konventionen benannt:
 
Alle symbolischen Links hier sind nach folgenden Konventionen benannt:
*K<NUMMER><SCRIPTNAME> => ../init.d/<SCRIPTNAME>
+
*K<NUMMER><SKRIPTNAME> => ../init.d/<SKRIPTNAME>
Wird beim Verlassen des Levels in der Reihenfolge der Nummern aufgerufen und ruft das script mit 'stop' auf.  
+
Wird beim Verlassen des Levels in der Reihenfolge der Nummern aufgerufen und ruft das Skript mit 'stop' auf.  
*S<NUMMER><SCRIPTNAME> => ../init.d/<SCRIPTNAME>
+
*S<NUMMER><SKRIPTNAME> => ../init.d/<SKRIPTNAME>
Wird beim Entern des Levels in der Reihenfolge der Nummern aufgerufen und ruft das script mit 'start' auf.<br>
+
Wird beim Entern des Levels in der Reihenfolge der Nummern aufgerufen und ruft das Skript mit 'start' auf.<br>
 
Die Runlevel haben folgende Bedeutung:
 
Die Runlevel haben folgende Bedeutung:
 
*0: Stop des Systems
 
*0: Stop des Systems
*1: single user (Administration), Dateisysteme gemountet
+
*1: single user (Administration), Dateisysteme eingebunden
 
*s: wie 1, aber ohne multi-user Dateisysteme
 
*s: wie 1, aber ohne multi-user Dateisysteme
 
*2..4: normalerweise identisch, multi user, default meist 2 oder 3  
 
*2..4: normalerweise identisch, multi user, default meist 2 oder 3  
 
*5: multi user mit grafischer Oberfläche (X11)
 
*5: multi user mit grafischer Oberfläche (X11)
 
*6: Reboot
 
*6: Reboot
Level 2..5 werden bei einigen Distris anders gehandhabt.
+
*7..f: meist unbenutzt/nicht existent
Ein Runlevel kann mit init >RUNLEVEL> erreicht werden.
+
Level 2..5 werden bei einigen Distribution anders gehandhabt.
  
 
===rcsysinit.d===
 
===rcsysinit.d===
 
wie vor, wird jedoch vorher aufgerufen.
 
wie vor, wird jedoch vorher aufgerufen.
  
(to be continued)
+
 
 +
==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
 +
 
 +
 
 +
[[Kategorie:Begriffserklärungen]][[Kategorie:Konfigurationsdateien]]

Aktuelle Version vom 1. September 2013, 12:22 Uhr

Inhaltsverzeichnis

[Bearbeiten] Einleitung

Diese Seite gibt einen groben Überblick über die Startskripte eines Linux Systems mit System V Init Skripten.

Hinweis
Hinweis

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


[Bearbeiten] 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

[Bearbeiten] 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 eventuell Bootdevices) und sucht dann auf dem ersten gefundenen Boot Device nach einem Master Boot Record (MBR).

[Bearbeiten] 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 gegebenenfalls 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.

[Bearbeiten] 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.


[Bearbeiten] 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.

[Bearbeiten] 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!

[Bearbeiten] 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 eingebunden, benötigte Daemons gestartet etc. Zum Schluss startet init die notwendigen Login-Programme (getty etc.).

[Bearbeiten] Die Verzeichnisstruktur in /etc/rc.d

[Bearbeiten] init.d

Dieses Verzeichnis enthält die Skripte, die von SysV ausgeführt werden sollen. Diese Skripte 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)

[Bearbeiten] rc<RUNLEVEL>.d

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

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

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

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

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

  • 0: Stop des Systems
  • 1: single user (Administration), Dateisysteme eingebunden
  • 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 Distribution anders gehandhabt.

[Bearbeiten] rcsysinit.d

wie vor, wird jedoch vorher aufgerufen.


[Bearbeiten] Aktuelle Runlevel abfragen

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

runlevel


[Bearbeiten] Runlevel wechseln

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

init 3

bzw.

telinit 3