News Linux-Wissen: Die Rolle des Init-Systems im Bootprozess

enzephalograph schrieb:
Da ich beruflich mit Linux zu tun habe und mich mit der Thematik befasst habe, finde ich den Artikel nicht so gut und ich finde, dass er ein (zumindest in Teilen) falsches Bild vermittelt.

Da kann ich dir nur uneingeschränkt recht geben. Der Artikel strotzt nur so vor gefährlichen Halbwissen und gehört dringest überarbeitet. Ansonsten freue ich mich schon auf Zukünftige Diskussionen!

Um es noch einmal ganz klar zu sagen: GRUB hat überhaupt rein gar nichts mit dem Linux Kernel zu tun und umgekehrt. Sowohl der Linux Kernel lässt sich mit anderen Mitteln booten als auch GRUB kann beliebige andere Betriebssysteme (oder Bootloader) booten. Auch wird da nichts entpackt und schon gar nicht das initrd, was noch nicht einmal zwingend vorhanden sein muss, oder sonst irgendwas! Und auch die Darstellung des gesamten Init-Vorgangs ist mehr als gruselig und extrem aus einer Debian/Ubuntu Perspektive geprägt.

Ich kann nur inständig darum bitten den Artikel zu überarbeiten und die Dinge richtig zustellen. Bei Nachfragen bin ich auch gerne dabei behilflich!
 
Die Serie gefällt mir gut. Selbst für mich als Neuling (seit knapp zwei Monaten Linux auf dem Studiumslaptop) ist der Inhalt gut verständlich. Ich würde mir fast schon mehr Details wünschen.
 
ich3k schrieb:
Da kann ich dir nur uneingeschränkt recht geben. Der Artikel strotzt nur so vor gefährlichen Halbwissen und gehört dringest überarbeitet. Ansonsten freue ich mich schon auf Zukünftige Diskussionen!

Um es noch einmal ganz klar zu sagen: GRUB hat überhaupt rein gar nichts mit dem Linux Kernel zu tun und umgekehrt. Sowohl der Linux Kernel lässt sich mit anderen Mitteln booten als auch GRUB kann beliebige andere Betriebssysteme (oder Bootloader) booten. Auch wird da nichts entpackt und schon gar nicht das initrd, was noch nicht einmal zwingend vorhanden sein muss, oder sonst irgendwas! Und auch die Darstellung des gesamten Init-Vorgangs ist mehr als gruselig und extrem aus einer Debian/Ubuntu Perspektive geprägt.

Ich kann nur inständig darum bitten den Artikel zu überarbeiten und die Dinge richtig zustellen. Bei Nachfragen bin ich auch gerne dabei behilflich!

Naja, im Artikel geht es ein wenig durcheinander: erst lädt der Grub den Kernel, dann präsentiert er ein Auswahlmenü, dann übergibt er die Steuerung an Init. Das ist natürlich Quatsch; das Menü kommt logischerweise vor dem Laden des Kernels, möglicherweise hat der Autor das mit dem Laden von core.img (dem Grub-Kernel) verwechselt. Nach dem Laden, Entpacken und Starten des Kernels verabschiedet sich Grub. Den Rest kann der Kernel dann alleine, vor allem das Init starten. Allerdings hast du nicht ganz recht mit dem Entpacken, das macht schon noch der Bootloader, indem er die entsprechende "Decompression-Stub" - ein Teil des Kernel-Images - ausführt.
 
ich3k schrieb:
Da kann ich dir nur uneingeschränkt recht geben. Der Artikel strotzt nur so vor gefährlichen Halbwissen und gehört dringest überarbeitet. Ansonsten freue ich mich schon auf Zukünftige Diskussionen!

Um es noch einmal ganz klar zu sagen: GRUB hat überhaupt rein gar nichts mit dem Linux Kernel zu tun und umgekehrt. Sowohl der Linux Kernel lässt sich mit anderen Mitteln booten als auch GRUB kann beliebige andere Betriebssysteme (oder Bootloader) booten. Auch wird da nichts entpackt und schon gar nicht das initrd, was noch nicht einmal zwingend vorhanden sein muss, oder sonst irgendwas! Und auch die Darstellung des gesamten Init-Vorgangs ist mehr als gruselig und extrem aus einer Debian/Ubuntu Perspektive geprägt.

Ich kann nur inständig darum bitten den Artikel zu überarbeiten und die Dinge richtig zustellen. Bei Nachfragen bin ich auch gerne dabei behilflich!

Die Rubrik Linux-Wissen ist nicht dazu gedacht, bis in letzte Details zu gehen. Sie kann nicht alle Möglichkeiten und Alternativen aufgreifen. Das aus der Debian-Perspektive berichtet wird, ist richtig. Ich sehe nicht, was dagegen einzuwenden wäre. Zudem schreibe für Desktop-Anwender, nicht für Sys-Admins.

Das die Initrd nicht zwingend vorhanden sein muss, habe ich erwähnt. Das GRUB etwas mit dem Linux-Kernel zu tun hat, habe ich nicht behauptet, und auch Lilo als früher häufig genutzten Bootloader erwähnt. Ich habe nichts davon geschrieben, dass die Initrd ausgepackt wird. Der Satz zu Initrd lautet:"Der Kernel lädt, falls vorhanden, die temporäre Initial-RAM-Disk initrd." Das mit dem Auswahlmenü von GRUB ist durcheinander gekommen, da erfolgt natürlich zuerst die Anzeige des Menüs.

An einer Diskussion über Systemd möchte ich mich an dieser Stelle nicht beteiligen. Mir ist klar, dass Gentoo Systemd alternativ anbietet und ansonsten auf OpenRC setzt. Die Nummerierung der Runlevel habe ich als "gemeinhin" bezeichnet, was Ausnahmen einschliesst.

Und nun geh ich kochen. Ein schönes Wochende noch.
 
fethomm schrieb:
Das aus der Debian-Perspektive berichtet wird, ist richtig. Ich sehe nicht, was dagegen einzuwenden wäre.

Dagegen ist nichts einzuwenden, jedoch sollte man es zumindest im Text explizit erwähnen, wenn man dem ganzen nicht gleich den Titel "Die Rolle des Init-Systems im Bootprozess bei Debian" gibt. Ansonsten kann ich mir demnächst Fragen anhören, wo denn das GRUB Menü in einem Android Handy ist.

Außerdem ändert es nichts daran, dass immer noch kein Chainloading statt findet, welches im Boot-Kontext (also nicht zu verwechseln mit exec()) für das ersetzen eines Bootloaders durch einen anderen steht.

fethomm schrieb:
Das mit dem Auswahlmenü von GRUB ist durcheinander gekommen, da erfolgt natürlich zuerst die Anzeige des Menüs.

Und warum gehen Sie dann jetzt bitte Kochen anstatt den Fehler im Artikel zu korrigieren? Das würde sowohl dem unbedarften Leser als auch insbesondere Ihrer persönlichen Reputation zu Gute kommen!
 
ich3k schrieb:
Dagegen ist nichts einzuwenden, jedoch sollte man es zumindest im Text explizit erwähnen, wenn man dem ganzen nicht gleich den Titel "Die Rolle des Init-Systems im Bootprozess bei Debian" gibt. Ansonsten kann ich mir demnächst Fragen anhören, wo denn das GRUB Menü in einem Android Handy ist.

Außerdem ändert es nichts daran, dass immer noch kein Chainloading statt findet, welches im Boot-Kontext (also nicht zu verwechseln mit exec()) für das ersetzen eines Bootloaders durch einen anderen steht.



Und warum gehen Sie dann jetzt bitte Kochen anstatt den Fehler im Artikel zu korrigieren? Das würde sowohl dem unbedarften Leser als auch insbesondere Ihrer persönlichen Reputation zu Gute kommen!

Hatte ich natürlich getan, vermutlich ohne korrekt zu speichern. Nun nochmal.
 
Guten hunger! Ich kann mit linux zwar nix anfangen, aber fethomm ist eine wirkliche bereicherung für cb. Vermutlich der beste autor.
 
ich3k schrieb:
Da kann ich dir nur uneingeschränkt recht geben. Der Artikel strotzt nur so vor gefährlichen Halbwissen und gehört dringest überarbeitet. Ansonsten freue ich mich schon auf Zukünftige Diskussionen! ...

Manche Leuts sind schon lustig! :D Das ist doch keine Vorlesung an der Uni. Das ist ein verständlich geschriebener Einsteigerartikel für den Linuxstart...:lol:

ich3k schrieb:
Um es noch einmal ganz klar zu sagen: GRUB hat überhaupt rein gar nichts mit dem Linux Kernel zu tun und umgekehrt.

Wo steht eine anderslautende Behauptung im Artikel? Find das irgendwie nicht!
 
Zuletzt bearbeitet:
Mr.Seymour Buds schrieb:
Ein guter Artikel. Allerdings denke ich, dass der nächste Bericht über den Linux-Grafikstack noch mehr gelesen wird, weil Grafik nun mal in der Praxis noch wichtiger (oder viel wichtiger) ist, als das Booten.
Das ist ein Widerspruch. Ohne Bootvorgang keine Grafik. Und überhaupt ist auf einem GNU Linux die Grafik nur ein Zusatz. Die Shell unter der Haube ist neben dem Kernel immer noch das wichtigste.
 
Danke fuer den Artikel.

Ich finds schade, wie einige Leute hier wieder reagieren. Da werden fethom Sachen untrestellt, die so nicht mal ansatzweise im Artikel stehen.
Kritik ist ja gut, aber bitte den Artikel wirklich erst ein bis zwei mal lesen bevor man hier anfaengt Sachen an den Kopf zu werfen.
 
habe mich extra seit langem eingeloggt um zu schreiben: Danke für den Artikel!

Ich beschäftige mich viel mit Computern und Microcomputern in soft- und hardwareentwicklung, trotzdem ist es heutzutage einfach unmöglich überall Experte zu sein. Dieser Artikel ist deshalb ein Segen. In weniger als 10 Minuten bekommt man als Computeraffiner User hier einen leicht verständlichen Einblick über die Abläufe und Begrifflichkeiten, die bei einem Systemstart wichtig sind. Dass man dabei vereinfachen muss und somit nicht absolut korrekt schreiben kann ist völlig richtig.

Weiter so. Solche kompetent zusammengefassten Fachartikel sind toll und sehr selten zu finden!

Danke
 
Eine verständliche Erläuterung für das neue init-System, finde ich gut. Genauso gut finde ich, dass Ubuntu seinen Sonderweg aufgibt.
 
wolli_d schrieb:
Genauso gut finde ich, dass Ubuntu seinen Sonderweg aufgibt.

Warum das? Ich finde es eher schade, wenn bewährte Systeme sterben. Monokulturen sind nicht gut, denn wenn Entwickler davon ausgehen, dass sowieso 90% der Systeme identisch sind, dann können sie sich leicht dafür entscheiden, die restlichen 10% zu ignorieren. So ähnlich lief das ja z.B. bei Gnome3, welches plötzlich mit einer Abhängigkeit zu systemd daherkam. BSD musste das dann wieder herauspatchen, um Gnome3 überhaupt verwenden zu können.
 
Zuletzt bearbeitet:
ja muss auch sagen, was an dem "Halbwissen" so gefährlich sein soll ist mir ein Raetzel, aber irgendwie doch wieder nicht. Die meisten der Kommentare die hier auf Genauigkeit pochen sind offenbar wie man aus den Kommentaren raus lesen kann, Gegner von Systemd, und da gehts dann ums jedes Detail, besonders wenn Systemd in dem Artikel vermeintlich zu gut weg kommt.

Bei einer weniger ausführlichen Auflistung aller Abarten ist die Chance nun mal höher das es vielleicht 5x so viele lesen, und lieber wissen 5x so viele grob wie sowas funtzt als das 1x so viel es genau weiß. Entwickler, Systemd-hater und anderes Publikum wird sich direkt bei anderen Quellen informieren um die habe ich keine Angst.

Vieles von euren Argumenten sind auch nur Halbargumente. Vieles war auch ohne Systemd möglich wurde aber von niemandem gemacht. Dank dem Systemd Team bekamen viele Bereiche wo früher nur 2 commits pro Jahr von 2-3 Leuten gemanaged wurden jetzt massenhaft Liebe ab. Z.B. wars eben nunmal Fakt das bei den in der Wildbahn häufig anzutreffenden Implementierungen wirklich nen Teil vom Bootprozess im Log gefehlt hat. Und das galt nunmal nicht nur für Debian sondern für viele Linux Distris.

Auch erwähnt ihr auch nur die Halbwahrheit, also die negativen Sichten auf einige Eigenschaften, ein biraeres Log hat auch Vorteile, das es nunmal vor Manipulation besser geschützt ist und auch von Programmen besser und schneller lesbar ist. Zumal kann man immer noch den alten Syslog mit starten und dem alles durchlaufen das ging schon immer, von daher auch ne Halbwahrheit das standardmäßig das asciilog abgeschafft wurde.

Dann zu dem simplen Kern der nix kann der besser sein soll wie ein komplexeres Initsystem, ist auch nur eine Halbwahrheit, hier wird der Preis dafür verschwiegen und der ist extremst hoch. Jedes Initscript ist dann Programmcode hoch komplexer, jede Distri muss diese gesondert nochmal schreiben also bei 30 Distries hast dann 30x so viel Fehler wie bei Systemd wo die Konfigurationen Distributionsunabhaengig ist.

Schon was an Trillionen an Mahnjahren verschwendet wurde um alles 30x zu schreiben und dann dauernd zu maintainen. Auch verrückt das bei den Initprozessen im Grunde häufig mehr oder weniger das selbe drin steht. Jeder egal welches OS Entwickler weiß, dass wenn er in seinem Sourcecode 30x identische Codeabschnitte drin stehen hat das schlecht programmiert ist. Das Prinzip heisst DRY, Don't Repeat Yourself! Gibts auch nen Wikipedia link zu.

http://de.wikipedia.org/wiki/Don’t_repeat_yourself

Hoffe trotz allem das es nicht zu einer Systemd vs wasauch immer aus der Vergangenheit Thread wird. Hier gings um Wissen für Anfänger nicht um Meinungen was nun besser ist oder nicht. Habe hier mal noch die andere Seite des Diskurses dar gestellt um kein einseitiges Bild von manchen stehen zu lassen. Hoffe wir koennen das ohne das wir das abschließend hier aus zu diskutieren soweit weitgehend stehen lassen.
 
Wer war denn jetzt gegen systemd? Ich bestimmt nicht, ich nutze das ja selber. Journald finde ich aber wirklich nicht so toll. Gut dass du da die Geschwindigkeit erwähnst, habe nämlich systemd+jounald auf einem Raspberry Pi laufen, den ich über ssh warte. Da habe ich mich versehentlich mal bei den journalctl-Optionen vertippt und das System ist für 10 Minuten beschäftigt gewesen und hat auf keine Eingabe mehr reagiert. Klar kann man da noch einen konventionellen Logger nebenher laufen lassen, aber wie sinnvoll ist das denn?

Zum Artikel: der wurde deutlich überarbeitet, weil wirklich einige Fehler drin waren.
Ergänzung ()

Achso: zu trivialem Init: was hältst du denn von SysV-Init + OpenRC? Da hat man beides, das simple Init und ein leicht wartbares Skript-System.
 
Wenn ich schon bsd hoere als argument gegen ein linux init system, dann das mit dem binären logging system wo eben auch nur die negativen aspekte auf gezählt werden und die positiven ausgespart werden.

Sorry werde auch schon bei Bsd in dem Zusammenhang hellhörig kennst ja sicher das video von diesem Datenwolf Typ das auch ein BSD Fan (und kenne keine Leute die neutral sind und bsd und linux gleich gerne mögen ich gehöre btw auch nicht zu der Sorte wobei mir eigentlich die Bsd User fast mehr aufregen die sind meist noch Aroganter und Pseudo-elitaerer wie Linuxer und das muss man erstmal schaffen :) )


Aber zurück, sicher Systemd mag nicht so der Brueller sein fuer nen Raspberry Pi aber der Artikel ging ja um X86 und Grub ist fuer solche Arm-dinger meist auch nicht geeingnet soweit ich weiß, also das ne Software überall optimal ist ist selten.

Zu OpenRC, hab ich mir nicht im Detail angeschaut, aber wenn du schon schreibst, Skripte, halte ich schon nix mehr von. Upstart hatte auch irgendwie vereinfachte Scripte aber Scripte haben in Konfigurationsdateien nix zu suchen.

Und du brauchst Konfigurationsdateien um zentral an einer Stelle anpassungen und fixes coden zu können, sonst musst was im Zweifel in allen Scripten fixen.

Hmm ja das funtzt aus einem Grund mit Gentoo ganz gut. Weil dir Gentoo so ziemlich jede Software selbst anbietet und die Scripte mit liefert, wenn das einmal nicht der Fall ist und du nur ein Script für nen anderes System findest und du es manuell migrieren musst wirst du die Zeit (jeh nach Komplexitaet und deinen skills schwer zu sagen wieviel) hassen die du hier nur wegen diesem System aufbringen musst ich kann halt im Archwiki alle service files klauen als fedora nutzer und das es nicht sofort funtzt ist aeusserst unwahrscheinlich.

Und selbst wenn Ubuntu OpenRC verwenden würde, würde wäre es alles andere als wahrscheinlich das du dort so ein file benutzen kannst.

Davon ab gesehen es ist ein System das auch nicht DRY Konform ist, man schreibt 3x fast das gleiche nen Block für start stop und restart. Man könnte da anfangen und nen wrapper um die 3 machen und nur die abweichende Teile --start --stop und sowas uebergeben aber dann hat man die wrapper in jedem init-file. Das will man auch nur 1x schreiben noch weiter abstrahiert, und dann wird eben der core ein wenig groesser. lieber ein core dep doppelt so gross ist und 30 init files die halb so gross sind als umgekehrt.

Was auch noch dazu kommt ist dieser wunsch alles Unixish zu halten daran rührt bei vielen das sie eben pipes und grep und all die tools ausm ff können fuer neue user ist das journalctl tool nen segen, dann müssen sie eben nicht erst grep und co lernen um damit produktiv zu sein.

Aber auch ich finde diese tools super und ein segen. Mir ist schon zu überlegen in welchem verzeichnis die Logs sind zu viel Aufwand. Das mag 1x 10x 100x noch ok sein aber bein 1000x wirds nur noch ober lästig.

So hoffe mein ton ist freundlich nix für ungut :)
 
Zuletzt bearbeitet von einem Moderator: (Fullquote des unmittelbaren Vorposter entfernt)
Die Linux-Artikel von Ferdinand Thommes sind äusserst fundiert und hervorragend geschrieben. Gerade bei diesem kontroversen Thema auch bemerkenswert unparteiisch-neutral. Vielen Dank dafuer!
 
lightfoot schrieb:
[Sonderweg Ubuntu Upstart] Warum das? Ich finde es eher schade, wenn bewährte Systeme sterben. Monokulturen sind nicht gut, denn wenn Entwickler davon ausgehen, dass sowieso 90% der Systeme identisch sind, dann können sie sich leicht dafür entscheiden, die restlichen 10% zu ignorieren. So ähnlich lief das ja z.B. bei Gnome3, welches plötzlich mit einer Abhängigkeit zu systemd daherkam. BSD musste das dann wieder herauspatchen, um Gnome3 überhaupt verwenden zu können.

Man kann natürlich das Ableben von Fußpilz wie Upstart bedauern, allerdings sind gerade Monokulturen im Sinne der Wartbarkeit mehr als sinnvoll. Nach der Entscheidung bei Debian ist das Folgen von Canonical also nachvollziehbar.

Die BSDs müssen sich früher oder später auch was einfallen lassen. Entweder einen neuen Flicken auf den Flickenteppich setzen, oder die grundlegende Modernisierung, um die Patcherei zu begrenzen. Es fällt nicht so auf, aber hier an dieser Stelle beginnt für mich bei Linux tatsächlich eine Eigenentwicklung der Systemarchitektur.
 

Ähnliche Themen

Antworten
71
Aufrufe
13.170
Antworten
113
Aufrufe
19.375
Antworten
29
Aufrufe
5.280
Bruddelsupp
B
Zurück
Oben