Bootvorgang

Nach dem Bootvorgang, dessen Durchführung gänzlich beim Bios und dem Linux-Kernel liegen, übergibt der Kernel die restliche Arbeit an das Programm init, dessen einzige Aufgabe darin besteht, Prozesse, Daemons, Skripte und ganz am Ende auch die tty-Konsole (teilweise auch den X-Server) zu starten, so daß sich der Benutzer ins System einloggen kann.

Die Konfiguration des Inits erfolgt prizipiell sehr simpel, ist aber durch die verschiedene Realisierung der verschiedenen Distributoren mittlerweile sehr unübersichtlich.

Jede Distribution verfolgt mittlerweile ihr eigenes Konzept beim Realisieren des Bootvorgangs. Die Unterschiede sind zumeist tiefliegender als nur in den verschiedenen Datei- und Verzeichnisnamen, sondern liegen häufig in gänzlich verschiedenen Ideen der Umsetzung des Bootvorgangs. Dazu aber später mehr.

Grundstruktur von SysV

Linux kennt verschiedene sogenannte Runlevel. Bei modernen Distributionen kommt der Linux-Nutzer während der Installation nur noch indirekt mit dem Begriff Runlevel in Kontakt.
Zumeist wird bei einer Installation des Systems gefragt, ob der Benutzer sich auf seinem System später auf der Konsole oder bereits unter X (mittels xdm, gdm oder kdm) einloggen möchte. Neuerdings entfällt sogar diese Frage gänzlich, und es wird automatisch immer der X-Server zum Einloggen gestartet.

Intern entsprechen diese beiden Varianten verschiedenen Runleveln. Einloggen mit X bzw. auf Konsole sind gleichbedeutend zu den Runleveln 2 (Multi-User mit Netzwerk) und Runlevel 3 (Multiuser mit Netzwerk und grafischem Einloggen).
In diesen Punkten stimmen die verschiedenen Distributionen zumeist noch miteinander überein.

Insgesamt ist man aber nicht auf diese wenigen Runlevel beschränkt. Prizipiell kann man beliebig viele Runlevel auf seinem System einrichten, und nach Belieben konfigurieren. Zumindest 6 Runlevel sind bei den meisten Distributionen standardmäßig enthalten, wenn auch einige häufig leer bleiben.
Nähere Informationen, welche Funktion sich hinter welchem Runlevel verbirgt, findet man in der /etc/inittab.
Im folgenden ein Auszug aus der inittab einer SuSE-Distribution:

   # runlevel 0 is halt
   # runlevel S is single-user
   # runlevel 1 is multi-user without network
   # runlevel 2 is multi-user with network
   # runlevel 3 is multi-user with network and xdm
   # runlevel 6 is reboot
  

Das Wechseln von einem Runlevel in einen anderen ist auch während eines laufenden Systems möglich. Hierfür existiert der Befehl

  >> init X
  

Zusätzlich ist es hilfreich, wenn ein am Netzwerk angeschlossener Linux-PC schnell vom Netzwerk getrennt werden soll (z.B. weil Verdacht eines unerlaubten Zugriffs übers Netz besteht), ohne direkt das Netzwerkkabel herausnehmen zu müssen. Ein einfaches

  >> init S
  

Außerdem erkennt man, daß ein Reboot, bzw. ein Anhalten des Systems nichts weiter als das Wechseln in den Runlevel 6 bzw 0 entspricht. Die Befehle reboot -n bzw. halt sind demnach gleichzusetzen mit init 6 oder init 0.

Auch die Angabe, welcher Runlevel nun standardmäßig während des Bootens gestartet werden soll, erfolgt in der /etc/inittab. Der Eintrag

  id:3:initdefault:
  

Konfiguration

Linux wäre nicht Linux/Unix, wenn man an dieser Stelle nicht wieder mal bis zum Lebensende rumkonfigurieren könnte.
So kann es ganz entscheidend sein, welche Hardware bei welchem Runlevel initialisiert werden soll.

Beispielsweise ein Laptop, der sowohl mobil als auch in einem (oder gar mehreren) Firmennetzwerk(en) eingesetzt werden soll, braucht nur dann die Unterstützung der PCMCIA-Netzwerkkarte, wenn er in der Firma benutzt wird. Wird der PC unterwegs gestartet, können auf Druckertreiber, sämtlicher Netzwerksoftware (Treiber, Apache, NFS-mounting, NIS ...) verzichtet werden und somit wichtige Ressourcen eingespart werden.

Derartiges kann man einfach mittels verschiedene Runlevel realisieren. Ein Runlevel für Einzelplatzrechner, ein weiterer für den Einsatz in Netzwerken.
Es ist sogar möglich, für den Einsatz in verschiedenen Netzwerken auch verschiedenen Runlevel zu konfigurieren, die dann beim Booten die jeweiligen Netzwerkkonfiguration einstellen. Wechselt man nun mit laufendem Laptop von einem Netzwerk zum anderen, kann einfach der entsprechende Runlevel gestartet werden, und die Netzwerkkonfiguration wird dem neuen Netzwerk angepaßt.
Dies ist aber nur eine von vielen Einsatzmöglichkeiten.

Die Konfiguration der einzelenen Runlevel ist abhängig von der benutzten Distribution. Unter SuSE liegen die Konfigurationsdateien/-Skripte unter /sbin/init.d, während z.B. bei RedHat-basierenden Installationen die Skripte unter /etc/rc.d/ liegen.

Häufig existiert ein symbolischer Link von dem einen Verzeichnis zu dem anderen, in der Hoffnung, das somit die Kompatibilität zwischen den verschiedenen Distributionen erhalten bleibt (zumeist nicht mehr als ein trauriger Versuch).

Leider hat man sich in dieser Hinsicht noch nicht einigen können, und jeder Distributor verweist auf die Vorzüge seines eigenen Konzeptes.

In diesem jeweiligen Unterverzeichnis liegen sämtliche Skripte, welche systemkritische Dienste, Daemons etc. während des Bootvorganges starten, oder beim Herunterfahren des Systems auch wieder beenden:

  i4l         network      random       single
  alsasound   i4l_hardware nfs          reboot    skeleton
  apache      cron         idedma       nfsserver route     smbfs
  apmd        dhclient     inetd        scd       routed    sshd
  at          dummy        init.d       pcmcia    rstatd    syslog
  autofs      firewall     irda         pcnfsd    rusersd   usb
  boot        gpm          kbd          portmap   rwhod     wvdial.dod
  halt        kerneld      powerfail    sendmail  xdm
  lpd         pppoed       serial       ypclient
  

Die einzelnen Skripte dienen z.B. zum Starten des cron-Daemons (cron), der für die regelmäßige Ausführung von Programmen zuständig ist, dem Starten des Web-Servers (apache) bis hin zur Initialisierung der USB-Hardware (usb).

Die meisten Skripte besitzen (zumindestens von der groben Struktur her) den folgenden Aufbau:

   #! /bin/sh
   case "$1" in
      start)
          echo -n "Starte Service XYZ"
          /pfad/zu/XYZ
          ;;
      stop)
          echo -n "Beende Service XYZ"
          killall  XYZ 
          # oder /pfad/zu/XYZ -quit falls vom Programm unterstützt
          ;;
      restart)
          $0 stop  &&  $0 start
          ;;
      status)
          echo -n "Statusausgaben des Prozesses: "
  	# Ein Befehl, der zusätzliche Informationen zum laufenden
          # Programm ausgibt.
          ;;
      *)
          echo "Usage: $0 {start|stop|status|restart}"
          exit 1
          ;;
   esac
  

Um nun festzulegen, welche Skripte bei welchem Runlevel gestartet werden sollen, legt man in den Unterverzeichnissen rcX.d (X entspricht dem jeweiligen Runlevel) einen symbolischen Link auf das jeweilige Skript. Dabei sind aber noch folgende Einzelheiten zu beachten:

Die symbolischen Links müssen einer vorgeschriebenen Namensgebung folgen. Soll ein Skript beim Starten eines Runlevels ausgeführt werden, so muß der entsprechende symbolische Link mit dem Großbuchstaben "S" für Start beginnen, gefolgt von einer zweistelligen Nummer, die die Reihenfolge der auszuführenden Skripte festlegt und als drittes erst der eigentliche beschreibende Name des Links. Beginnend bei S01xxx werden nun alle Skripte nach steigender Zahlenfolge bis hin zu S99xxxx der Reihe nach ausgeführt. Dabei wird automatisch die Option "start" an die jeweiligen Skripte mit übergeben.

Das Ausführen der Skripte in der korrekten Reihenfolge ist deshalb so wichtig, da viele Programme erst dann gestartet werden können, wenn bereits vorher andere Dienste initialisiert wurden, bzw. Hardwarkomponenten installiert wurden. So kann beispielsweise ein Netzwerk erst dann angesprochen werden, wenn die zugehörige PCMCIA-Netzwerkkarte initialisiert wurde.

Ganz analog verläuft es mit dem Stoppen von Prozessen, beim Verlassen eines Runlevels. Die zugehörigen Skripte werden alle nach dem Muster K01xxxxx bis K99xxxxx mit den eigentlichen Programmen verlinkt.

So könnte abschließend das Verzeichnis /sbin/init.d/rc2.d/ des Runlevels 2 folgendermaßen aufgebaut sein:

  K19cron        K24ypclient      S03pcmcia          S19idedma
  K19nscd        K30idedma        S04dummy           S20apache
  K19smbfs       K30random        S04firewall_init   S20apmd
  K20apache      K35routed        S04irda            S20at
  K20apmd        K35syslog        S05dhclient        S20gpm
  K20at          K36nfs           S05i4l             S20inetd
  K20gpm         K37portmap       S05network         S20lpd
  K20inetd       K38route         S07firewall_setup  S20rstatd
  K20lpd         K40dhclient      S07route           S20rusersd
  K20rstatd      K40i4l           S08portmap         S20rwhod
  K20rusersd     K40network       S09nfs             S20sendmail
  K20rwhod       K42pcmcia        S09syslog          S20sshd
  K20sendmail    K44i4l_hardware  S10kbd             S21alsasound
  K20sshd        K45dummy         S10routed          S21cron
  K21alsasound   K45irda          S13random          S21nscd
  K22wvdial.dod  K51firewall      S16ypclient        S21smbfs
  K23nfsserver   K99kerneld       S17autofs          S22wvdial.dod
  K23pcnfsd      S01kerneld       S17nfsserver       S99firewall_final
  K24autofs      S03i4l_hardware  S17pcnfsd
  

Man erkennt hieran schon einen Unterschied der SuSE-Distribution zu bisher vorgestellten Schemata: Es befinden sich viel mehr Links in den Unterverzeichnissen, als man wirklich starten möchte.

Was von der Idee übrig bleibt...

Wie bereits anfangs erwähnt, besitzt jede Distribution ihre eigenen Vorstellungen, wie ein "ordentlicher" Bootvorgang auszusehen hat.
Im Zuge immer stärkerer Ausrichtung auf den Desktop-Markt wird versucht, die Komplexität des Systems vor dem Benutzer so weit wie möglich zu verstecken. Dieser zwar zumeist lobenswerte Schritt bringt aber auch eine Reihe Probleme mit sich. Denn ein Benutzer, der nicht weiß, wie das System genau funktioniert, kann weder auftretende Probleme beheben, noch das System an eigene Bedürfnisse anpassen.

Dies geht sogar soweit, daß Meldungen beim Starten eines Programmes komplett unterdrückt werden und nur durch ein grünes done oder ein error dem Benutzer während des Bootens mitgeteilt wird, ob das betreffende Programm erfolgreich gestartet werden konnte oder nicht.
Falls nicht, wird dem Benutzer zumeist keine weitere Hilfe mehr ausgegeben, und er steht zunächst vor dem Problem, wo er mit der Fehlerbeseitigung anfangen soll.

Die Krönung des Ganzen sind Programme wie LPP (Homepage: http://lpp.freelords.org/), die den Bootvorgang gänzlich vor dem Benutzer mittes bunter Bootlogos und Statusanzeige verbergen. Es ist wohl nur eine Frage der Zeit, bis gängige desktop-orientierte Distributionen uns standardmäßig mit derartigen Schrecklichkeiten begrüßen.

Bei SuSE beispielsweise sieht das Init-Konzept etwa folgendermaßen aus:
Alle installierten systemwichtigen Tools werden automatisch in den entsprechenden rcX.d-Unterverzeichnissen verlinkt. Das Vorhandensein des jeweiligen Links bewirkt allerdings noch nicht das automatische Starten während des Bootens, sondern die Skripte beinhalten nur eine Abfrage der globalen Konfigurationsdatei /etc/rc.config. Ist in dieser Datei der zugehörige Wert START_XXX (z.B. START_HTTPD für den Apache Web-Server) auf yes gestellt, wird beim Ausführen des Skriptes auch der zugehörige Prozess gestartet.

Gewonnen hat man dadurch die Verlagerung der Kontrolle über die beim Booten zu startenden Prozesse nach Yast. Für einen Anfänger ist dies auf den ersten Blick wahrscheinlich einfacher, als die zugehörigen Links in den /sbin/init.d-Unterverzeichnissen zu erstellen. Allerdings bewirkt dies nur die Verlagerung einer zentralen Konfiguration auf eine andere zentrale Stelle. Anstatt die Variable, ob der Prozess nun gestartet werden soll oder nicht, in eine weitere Datei zu verlegen, könnte Yast doch auch gleich den symbolischen Link erstellen oder entfernen. Das Resultat wäre dasselbe und darüber hinaus noch standardkonformer.

Allerdings besitzt das von YAST benutzte Prinzip eine nicht zu unterschätzende Schwäche:
Es ist nicht mehr möglich gezielt zu steuern, bei welchen Runleveln ein Prozeß gestartet werden soll, bzw. nicht gestartet werden soll. Die Variablen START_XXX sind unabhängig vom Runlevel und beeinflussen alle gleichsam.
Dem wird nur dadurch Abhilfe getragen, daß einige Links nur in ganz speziellen Runleveln existieren (z.B. der Link auf xdm nur im Runlevel 3).

Möchte man eigene Runlevel erstellen oder bereits von YAST verwaltete Prozesse (z.B. Apache) nur in ausgewählten Runleveln starten, kommt man nicht drumherum selbst Hand anzulegen, Links zu entfernen oder zu erstellen und u.U. die vorgefertigten Skripte komplett durch eigene zu ersetzen.

boot.local

Wem das bisher alles zu kompliziert ist, kann immer noch auf die Datei boot.local ausweichen. Hierbei handelt es sich um ein einfaches Skript, welches auch im /sbin/init.d/ Verzeichnis liegt und in dem vom Systemadministrator einfache Befehle abgelegt werden können, die während des Bootens ausgeführt werden sollen.

Diese Datei bietet auch eine Ausweichmöglichkeit, wenn ein Prozeß sowieso bei jedem Booten, unabhängig vom Runlevel gestartet werden soll.

Ein kurzer Eintrag des gewünschten Befehls in diese Datei erspart häufig das Erstellen eines Init-Skriptes mit all seinen Optionen (start, stop, status ...).

Leider existieren auch hier wieder verschiedene Umsetzungen der Idee. Bei de SuSE-Distribution beispielsweise wurde bis zur Version 6.x das Skript boot.local noch am Ende aller Init-Skripte ausgeführt. Es existierte ein Link unter S99local(??) in allen Runleveln auf die boot.local-Datei.

Seit der Versionsnummer 7.0 wird die boot.local nun aber am Anfang, noch vor den anderen Init-Skripten ausgeführt.
Dies kann sehr entscheidend sein, denn normalerweise benutzt man die boot.local, um kleinere Tools und Programme zu starten, für die ein eigenes Init-Skript übertriebener Aufwand wäre.
Befindet sich die Ausführung der boot.local am Anfang aller Init-Skripte, funktionieren diese Programme häufig noch nicht, da benötigte Hardware noch nicht initialisiert wurde (z.B die Netzwerkkarte).

Abhilfe schafft in diesem Falle eine eigene Batch-Datei, auf die dann in sämtlichen Runleveln mit einem Link S99xxxx verwiesen wird.

Distributions spezifisch

• SuSE:
  Die Verarbeitung der in den Init-Skripten zu startenden Prozesse wird seit der Distributions-Version 7.0 durch die Programme startproc und killproc übernommen. startproc legt für jeden gestarteten Prozess unter /var/run/ eine Datei mit dem Namen des Prozesses + Endung ".pid" ab, in dem die Prozess-ID abgelegt wird, welche der gestartete Prozeß besitzt. Damit kann das Programm killproc den Prozess wieder beenden, indem es ein Kill-Signal an genau diese Prozeß-ID schickt. Außerdem entfernt killproc die zugehörige PID-Datei wieder.

  War das Starten des Prozesses erfolgreich, übergibt das Skript ein $rc_done an inetd, was ein Ausdrucken einer Erfolgsmeldung bewirkt.
  Sollte ein Fehler während des Startens passieren, wird stattdessen ein $rc_failed zurückgegeben.
  Den genauen Text-Inhalt von $rc_done und $rc_failed kann man mittels yast (oder in der /etc/rc.config) einstellen.

  Ein typisches Init-Skript sieht (seit Version 7.0) vom Aufbau her folgendermaßen aus:

  Init-Skript

  #! /bin/sh # . /etc/rc.status . /etc/rc.config base=${0##*/} link=${base#*[SK][0-9][0-9]} rc_reset case "$1" in start) echo -n "Starting XYZ daemon" startproc /usr/sbin/XYZ rc_status -v ;; stop) echo -n "Shutting down XYZ daemon" killproc -TERM /usr/sbin/XYZ rc_status -v ;; restart) $0 stop && $0 start rc_status ;; reload) # Befehl um Konfigurationsdatei neu einzulesen ;; status) echo -n "Checking for XYZ daemon" checkproc /usr/sbin/XYZ && echo "XYZ is up" || echo "No XYZ daemon" ;; probe) # Befehl um XYZ zu testen ;; *) echo "Usage: $0 {start|stop|status|restart|reload|probe}" exit 1 esac rc_exit

  
  

  Weitere Eigenheiten bei SuSE sind, daß das Skript boot.local seit der Distributionsversion 7.0 schon zu Beginn der eigentlichen Init-Skripte ausgeführt wird, während es bei älteren Distributionen am Ende der Init-Skripte ausgeführt wurde.
  Dieses Verhalten kann zu Problemen führen, da man nun nicht mehr in der boot.local Netzwerkprogramme starten kann, da zu diesem Zeitpunkt die Netzwerktreiber noch gar nicht initialisiert wurden.
  Abhilfe schafft ein eigenes Skript z.B. /sbin/init.d/boot.last, welches in allen Runleveln ganz am Ende gestartet wird (also ein symbolischer Link S99zzzboot.last -> .../boot.last.

• RedHat:
  Ob der Aufbau der RedHat-Skripte nun die Übersichtlichkeit erhöht, bleibt Geschmackssache. Das Unterbringen der verschiedene Aufrufe (start, stop ...) in eigene Funktionen bringt eigentlich keinerlei Vorteile.
  Zusätzlich wird eine Lock-Datei im /var/lock/subsys/-Verzeichnis angelegt.

  Init-Skript

  #! /bin/sh # # skeletond Start/Stop the skeleton daemon. # # chkconfig: 2345 90 60 # # processname: skeleton # config: /etc/skeleton # pidfile: /var/run/skeleton.pid # Source function library. . /etc/init.d/functions RETVAL=0 # See how we were called. start() { echo -n "Starting skeleton daemon: " daemon skeleton RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/skeleton return $RETVAL } stop() { echo -n "Stopping skeleton daemon: " killproc skeleton RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/skeleton return $RETVAL } rhstatus() { status skeleton } restart() { stop start } reload() { echo -n "Reloading skeleton daemon configuration: " killproc skeleton -HUP retval=$? echo return $RETVAL } case "$1" in start) start ;; stop) stop ;; restart) restart ;; reload) reload ;; status) rhstatus ;; condrestart) [ -f /var/lock/subsys/skeleton ] && restart || : ;; *) echo "Usage: crond {start|stop|status|restart|condrestart}" exit 1 esac exit $?

  
  
• Mandrake:
  Als letztes Beispiel der einfachheithalber noch ein Skeleton (Die Distribution selbst beherbergt keine Skeleton-Datei. Die folgende Datei wurde dem Start-Skript des Cron-Daemons entnommen und leicht geändert.)

  Das Installationsskript der Mandrake-Distribution ist am einfachsten aufgabaut und zeigt am wenigsten distributionsspezifische Eigenschaften.
  

  Init-Skript

  #! /bin/sh # # skeleton Start/Stop a daemon. # # chkconfig: 2345 40 60 # # processname: skeleton # config: /etc/skeleton # pidfile: /var/run/skeleton.pid # Source function library. . /etc/rc.d/init.d/functions # See how we were called. case "$1" in start) echo -n "Starting daemon skeleton: " daemon skeletond echo touch /var/lock/subsys/skeletond ;; stop) echo -n "Stopping skeleton daemon: " killproc skeletond echo rm -f /var/lock/subsys/skeletond ;; status) status skeletond ;; restart) killall -HUP skeletond ;; *) echo "Usage: skeleton {start|stop|status|restart}" exit 1 esac exit 0

  
  

• Übersicht:
  Eine kleine Liste an Skeleton-Dateien verschiedener Distributionen:
  • Caldera
  • Mandrake
  • SuSE
  • Debian
  • RedHat
  • Trustix

Tip: Spezialfall Laptops

Als sehr hilfreich hat sich die Benutzung von Runleveln speziell bei Laptops herausgestellt, die in verschiedenen Netzwerken eingesetzt werden. Z.B. ein Arbeitslaptop, der einerseits im heimischen LAN als auch im Firmennetzwerk benutzt wird.
Normalerweise muß nun jedesmal die Netzwerkkarte, Gateway und DNS-Server umkonfiguriert werden, wenn man das Netz wechselt. Zusätzlich werden einige Dienste, die in der Firma gebraucht werden, zuhause nicht benötigt (lpd, NIS, NFS ...).
Erstellt man nun einen eigenen Runlevel für die jeweiligen Einsatzbereiche, kann diese Konfiguration bei jedem Booten automatisch geschehen. Dafür kopiert man einfach ein bestehenden Runlevel z.B. nach rc7.d und paßt diesen an die Bedürfnisse der jeweiligen Netzwerkumgebung an.
Auf keinen Fall sollte man vergessen, in der /etc/inittab diesen neuen Runlevel anzumelden, speziell die Zeile

  7:123:respawn:/sbin/mingetty tty7
  

Zusätzlich sollten mittels eines speziellen Skriptes, welches im neu erzeugten Runlevel gestartet wird, die Konfigurationsdateien ausgetauscht werden, d.h. man kopiert beispielsweise die besetehende Netzwerk-Konfiguration in ein Backup-Verzeichnis, und ersetzt die notwendigen Dateien durch die Konfigurationen des Firmennetzwerkes. Sollten die unterschiede in der Konfiguration umfangreicher ausfallen, kann man auch gleich das gesamte /etc-Verzeichnis austauschen. Dabei ist aber drauf zu achten, daß der Rechner nie in einem Zustand ohne /etc-Verzeichnis beendet wird, denn dann kann er das nächste mal nicht mehr booten.

Abschließend wird noch ein Eintrag in die LILO-Konfigurationsdatei vorgenommen, so daß schon beim Booten mitgeteilt werden kann, welche Konfiguration gestartet werden soll. Dafür kopiert man den Eintrag, für die bisher genutzte Distribution, und erweitert sie um einen append-Eintrag

   [...]
   # bisher genutzer Eintrag
   image = /boot/kernel_redhat7_z
     root = /dev/hda2
     label = redhat
  
   #---neuer Eintrag
   image = /boot/kernel_redhat7_z
     root = /dev/hda2
     append = "init=/sbin/init 7"
     label = firma
  

Nach Aufruf des Befehls lilo kann nun beim nächsten Booten die Option "Firma" ausgewählt werden, und LILO übergibt dem Kernel die Option in der append Zeile und sagt ihm somit, daß der Runlevel 7 genutzt werden soll.
Dadurch wird das für die Firma benötigte /etc-Verzeichnis erstellt und man besitzt sofort die korrekte Systemkonfiguration.
Dadurch kann man das System mit verschiedensten Konfigurationen starten, ohne daß man für jede eine eigenen Partition benötigen würde.

Fazit

Der Bootprozeß spiegelt mehr als alles andere die Eigenheiten der einzelnen Distributionen wieder.
Jede größere Linux-Distribution hat seine eigene Vorstellung davon, wie der Aufbau einer Konfiguration der Runlevel auszusehen hat.

Das Nachsehen hat in diesem Fall wie immer der User, der bei dieser Vielfalt schnell die Übersicht verliert.

Aus einem durchdachten und simpel aufgebauten Prinzip wurde somit ein unüberschaubares Gewusel an eigenen Ansätzen. Frei nach dem Motto "Viel hilft viel" füllen einige Distributionen die Runlevel-Unterverzeichnisse mit unnötigen Links, die dann im Endeffekt doch nicht gestartet werden.

Bleibt zu hoffen, daß im Zuge künftiger offener Standardisierungen auch Einigkeit über den Aufbau des Boot-Prozesses einkehrt.

Für Unterstützung bedanke ich mich bei sh0 und zyz für die Bereitstellung der Skeleton-Dateien.
Homepage: www.libertynet.de

Anmerkungen zu diesem Artikel