SysV Init
Wirbel (Diskussion | Beiträge) (→init.d) |
Wirbel (Diskussion | Beiträge) |
||
(24 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
==Einleitung== | ==Einleitung== | ||
− | Diese Seite gibt einen groben Überblick über die | + | 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 | + | '''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. | ||
}} | }} | ||
− | + | '''''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 eventuell 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 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. | |
− | + | ||
− | + | ===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.<br> | |
− | + | {{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 | + | Dieses Verzeichnis enthält die Skripte, die von SysV ausgeführt werden sollen. |
− | Diese | + | 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 | + | 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>< | + | *K<NUMMER><SKRIPTNAME> => ../init.d/<SKRIPTNAME> |
− | Wird beim Verlassen des Levels in der Reihenfolge der Nummern aufgerufen und ruft das | + | Wird beim Verlassen des Levels in der Reihenfolge der Nummern aufgerufen und ruft das Skript mit 'stop' auf. |
− | *S<NUMMER>< | + | *S<NUMMER><SKRIPTNAME> => ../init.d/<SKRIPTNAME> |
− | Wird beim Entern des Levels in der Reihenfolge der Nummern aufgerufen und ruft das | + | 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 | + | *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 | + | *7..f: meist unbenutzt/nicht existent |
− | + | 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. | ||
− | + | ||
+ | ==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.
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
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.
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.
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