Alternative zu Linux gesucht - und nein kein Windows oder Mac OS

GNU-Fan

Hehe, ok.

Ok, dann werde ich mal das Versuchskaninchen spielen

Wie sieht es denn beim normalen Init-System von Gentoo aus, wie kann man da Dienste beim Boot in den Hintergrund forken, so dass man nicht ewig warten muss bis alle Dienste gestartet sind?

.filmor

RC_PARALLEL_STARTUP="yes" in /etc/conf.d/rc gibt sowas in der Art.

Wirkliches Versuchskaninchen wärst du mit Upstart, einit oder initng
Letzteres hab ich mal ausprobiert aber irgendwie nicht richtig ans laufen bekommen, weil sich das wohl damals nicht so gut mit dem Root-LVM-Spaß verstand. Außerdem hat Gentoo bisher im Prinzip nur sysvinit mit dem eigenen RC-System unterstützt, weshalb die Alternativen oft ohne Initskripte aus den ebuilds auskommen mussten. Das scheint sich mit baselayout-2 und OpenRC etwas zu bessern.

.filmor schrieb:

RC_PARALLEL_STARTUP="yes" in /etc/conf.d/rc gibt sowas in der Art.

Wirkliches Versuchskaninchen wärst du mit Upstart, einit oder initng
Letzteres hab ich mal ausprobiert aber irgendwie nicht richtig ans laufen bekommen, weil sich das wohl damals nicht so gut mit dem Root-LVM-Spaß verstand. Außerdem hat Gentoo bisher im Prinzip nur sysvinit mit dem eigenen RC-System unterstützt, weshalb die Alternativen oft ohne Initskripte aus den ebuilds auskommen mussten. Das scheint sich mit baselayout-2 und OpenRC etwas zu bessern.

Das RC_PARALLEL_STARTUP bringt ja echt einiges
Unterstützt der Startup bereits alle CPUs/Kerne? Dann müsste auf meinem Mehrkern-System der Bootvorgang ja locker halbiert werden, wenn ich mir anschaue wie sehr sich das bei meinem Single-Kern-Prozessor schon beschleunigt.

Das OpenRC scheint ja "nur" ne Art Wrapper/Aufsatz vom bisherigen init-System zu sein, aber scheint ja schon recht ordentlich zu laufen, werde es Morgen mal installieren.

Dafür fehlt mir wohl leider die Zeit (auch noch sämtliche Init-Skripte selbst zu erstellen)

Der eek-Smiley am Ende war nicht beabsichtigt.

.filmor

Linuckser schrieb:

Das RC_PARALLEL_STARTUP bringt ja echt einiges
Unterstützt der Startup bereits alle CPUs/Kerne? Dann müsste auf meinem Mehrkern-System der Bootvorgang ja locker halbiert werden, wenn ich mir anschaue wie sehr sich das bei meinem Single-Kern-Prozessor schon beschleunigt.

Naja, die Dienste müssen ja auch teilweise aufeinander warten, also ganz so einfach ist's nicht.
Übrigens nutzt das selbstverständlich mehrere Kerne (wenn der Kernel mit SMP-Unterstützung kompiliert ist), weil der Initvorgang im Prinzip nur das massenweise starten von Prozessen ist. Das auf mehrere CPUs aufzuteilen schafft jeder Multiprozessorkernel.

Linuckser schrieb:

Das OpenRC scheint ja "nur" ne Art Wrapper/Aufsatz vom bisherigen init-System zu sein, aber scheint ja schon recht ordentlich zu laufen, werde es Morgen mal installieren.

Immerhin ist's in C geschrieben, das sollte schon einiges im Vergleich zu dem alten Bash-basierten baselayout bringen.

.filmor schrieb:

Linuckser schrieb:

Das OpenRC scheint ja "nur" ne Art Wrapper/Aufsatz vom bisherigen init-System zu sein, aber scheint ja schon recht ordentlich zu laufen, werde es Morgen mal installieren.

Immerhin ist's in C geschrieben, das sollte schon einiges im Vergleich zu dem alten Bash-basierten baselayout bringen.

Ich dachte das wäre das bisherige auch schon, aber eben beim Nachlesen festgestellt, dass es tatsächlich erst mit 2.0 der Fall ist.

Ich mache gerade nen Backup der Gentoo-Partition, dann kann es losgehen.

Also Migration zu OpenRC verlief problemlos und läuft auch einwandfrei. Geschwindigkeit war ohne parallel ca. so schnell wie mit dem alten aber parallel. Beim zusätzlichen Einschalten von parllelem Start konnte ich aber keinen großen Unterschied feststellen (gefühlt).

GNU-Fan

Danke für die Info.

GNU-Fan schrieb:

Danke für die Info.

Konfiguration bleibt im wesentlichen gleich, nur sehr marginale Änderungen, wie /etc/rc.conf statt /etc/conf.d/rc.conf und die conf.d/clock heißt jetzt conf.d/hwclock (wobei der Name je nach System variiert), dann hat sich die Syntax der net-Konfigurationsdatei geringfügig geändert: die Klammern um die Parameter fallen weg.
An anderer Stelle heißt es jetzt statt UPPER_CASE_VARIABLE="lower-case-wert" lower_case_variable="UPPER-CASE-WERT".

So ich wollte nochmal kurz den Thread wiederbeleben.

Ich dachte bisher immer, dass mein Gentoo nur suspend2ram unterstützt und kein suspend2disk, jedoch ist mir vor kurzem aufgefallen, dass ich den Kernel kein "resume=/dev/swappartition" mitgegeben habe und habe es eben ausprobiert und es funktioniert einwandrei

Damit ist Gentoo bisher das erste Linux-System das bei mir beides unterstützt

Ich habe allerdings ein Problem mit Xorg oder etwas das auf die Grafik zugreift, denn wenn ich manchmal das Notebook ausschalten will wird der Bildschirm schwarz und es tut sich nichts mehr, das kann auch manchmal einfach passieren wenn ich X neustarten will mit Strg+Alt+Backspace. Ich vermute daher, dass es an X liegt (oder kann es auch Fluxbox sein?)
An meinem Login-Manager liegt es nicht da es auch auftritt wenn ich X aus einem Terminal heraus starte.

Hatte jemand von euch das schonmal oder eine Idee woran es liegen könnte?
Das ist derzeit das einzige was nicht sauber funktioniert unter Gentoo (ok und silent boot splash aber ich glaub da spielt baselayout2 noch nicht mit dem zusammen)

nman

Ich hatte mal ähnliche Probleme, weil mein Framebuffer nicht mit X.org zusammenspielen wollte, wenn ich die NVidia-Treiber geladen hatte.

Verwende seitdem nur mehr Vesafb, vielleicht liegt es bei Dir ja auch daran.

nman schrieb:

Ich hatte mal ähnliche Probleme, weil mein Framebuffer nicht mit X.org zusammenspielen wollte, wenn ich die NVidia-Treiber geladen hatte.

Verwende seitdem nur mehr Vesafb, vielleicht liegt es bei Dir ja auch daran.

Ich habe im Moment nur den Vesa- und Uvesa-FB Treiber aktiviert. Der IntelFB hatte immer seltsame Fehlermeldungen gebracht, dass er keinen Framebuffer in der entsprechenden Größe alloziieren konnte (hab mich da aber nie reingekniet da der uvesafb ja einwandfrei funktionierte).
Sollte ich evt. mal DRI deaktivieren? Reich dazu der entsprechende Eintrag in der Xorg.conf oder besser gleich im Kernel deaktivieren?

So ich bin jetzt mal von uvesafb auf vesafb gewechselt und werde mal beobachten ob dadurch der Fehler verschwindet.

Wie kann man denn den Kernel debuggen bzw. solche Module und überhaupt während dem Bootvorgang?