[gelöst] Allgemeine (Anfänger)fragen

[MrFrogman]

... Anfänger zumindest im Bereich ich-back-mir-meinen-eigenen-Kern.

Also, backe mir gerade mal testweise einen eigenen Kernel, die Vorteile haben mich überzeugt.
wie läuft das nun in Zukunft bei Updates ab? Die Updates für den Standard-Kernel werden mir dann nicht mehr angeboten?
Mal angenommen, ich würde einen eigenen Kernel permanent nutzen - was sicherheitstechnisch natürlich unsinnig ist - so wäre es doch nicht mehr nötig, das System bei Updates zu restarten? Einzelne Dienste lassen sich ja jederzeit von Hand neu starten.
Habe ich das soweit richtig verstanden? Das würde mir nämlich insofern die Arbeit massiv erleichtern, als dass Produktivsysteme dann längere Uptimes hätten (auch mal länger als etwa 50 Tage bis zum nächsten Standard-Kernel ) und die anderen Vorteile eines eigenen Kernels liegen ja auf der Hand.

MfG

Mr. Frogman

[Milbret]

Hallo,
soweit meine, auch nicht sehr großen, Kenntnisse reichen stimmt dies zwar.
Nachteil des ganzen ist aber, dass du durch den neusten Kernel auch immer unendeckte fehler hast.
Du musst also immer den neusten Kernel kompilieren und dann installieren und somit auch neustarten.

Mein Tipp wäre es eher, du nimmst den Debiankernel.
Unter einer stable Distribution ist dieser durch das Sicherheitsteam gewartet.
Somit kriegst du immer die patches.
Du musst dann nur updaten, neustarten und fertig.

Dies ist aus meiner Sicht als Anwender eine bessere Lösung.
Im Serverbereich würde ich dann aber doch überlegen nicht einen eigenen Kernel zu backen.
Ich kann mal die sources.list meines Webservers anschauen.
Dort werden auch für Debian spezielle Paketquellen genutzt.

Dort sind dann die neusten Pakete drin, die man im Serverbereich braucht.

MFG Martin

[storm]

Also, backe mir gerade mal testweise einen eigenen Kernel, die Vorteile haben mich überzeugt.
wie läuft das nun in Zukunft bei Updates ab? Die Updates für den Standard-Kernel werden mir dann nicht mehr angeboten?

Korrekt. Du hast ja dann auch keinen Std- oder Debian-Kernel mehr.

Mal angenommen, ich würde einen eigenen Kernel permanent nutzen - was sicherheitstechnisch natürlich unsinnig ist - so wäre es doch nicht mehr nötig, das System bei Updates zu restarten? Einzelne Dienste lassen sich ja jederzeit von Hand neu starten.

Wenn permanent bei dir heisst, dass du den jetzt gerade gebauten Kern dauerhaft nutzen willst, dann ist die Antwort ja. Natürlich gibt es trotzdem noch einige, wichtige Pakete, die einen Neustart durchaus ratsam erscheinen lassen.

Habe ich das soweit richtig verstanden? Das würde mir nämlich insofern die Arbeit massiv erleichtern, als dass Produktivsysteme dann längere Uptimes hätten (auch mal länger als etwa 50 Tage bis zum nächsten Standard-Kernel ;-) ) und die anderen Vorteile eines eigenen Kernels liegen ja auf der Hand.

Das stimmt schon. Den Eigenbau kannst du im Vgl. zum Debian-Kernel völlig zu machen (keine Module, debug-Code raus, keine experimentellen Treiber, etc.). Allerdings sollte dir auch bewusst sein, dass du ab diesem Zeitpunkt mehr Eigeninitiative hinsichtlich zB. Sicherheitslücken aufbringen musst, da dir niemand mehr Updates serviert.

ciao, storm

[Saxman]

Das stimmt schon. Den Eigenbau kannst du im Vgl. zum Debian-Kernel völlig zu machen (keine Module, debug-Code raus, keine experimentellen Treiber, etc.). Allerdings sollte dir auch bewusst sein, dass du ab diesem Zeitpunkt mehr Eigeninitiative hinsichtlich zB. Sicherheitslücken aufbringen musst, da dir niemand mehr Updates serviert.

Eine Möglichkeit die Ich gerne praktiziere ist mir den kernel aus den debian sourcen zu backen.
Der Vorteil davon ist daß sobald eine neue Version des kernels eintrudelt Ich die neuen sourcen über apt reinkriege und durch das changelog überblicken kann welche Treiber von Änderungen betroffen sind.
So krieg Ich bescheid wenn ein neuer kernel fällig wäre und kann über das changelog entscheiden ob die Änderungen für mich überhaupt interessant sind.
Ich hab hier zwar sid/experminental am laufen aber unter stable müssten die Änderung ja dann nur noch sicherheitskritische Sachen im Kernel betreffen. Ich denke das wäre ein guter Kompromiss.

Schönen Gruß

[cirrussc]

Ich hab hier zwar sid/experminental am laufen aber unter stable müssten die Änderung ja dann nur noch sicherheitskritische Sachen im Kernel betreffen. Ich denke das wäre ein guter Kompromiss.

Und so ein Kernel ist schließlich schnell aus der Röhre

[MrFrogman]

Hm, also die Idee von Saxman find ich ziemlich gut!
Eine Frage hab ich noch: Hab mir - für den ersten groben Test - mal den 2.6.28er runtergeladen und einfach meine aktuelle Konfiguratonsdatei übertragen, damit war der Kernel ja wie mein jetztiger konfiguriert (ist ein Debian Testing), aber nach dem Kompilieren fuhr der Rechner trotzdem nicht hoch, weil er wohl ein VFS nicht mounten konnte.
Habt ihr eine Erklärung? Oder muss ich den Kernel jedesmal konfigurieren, auch wenn cih die alte Konfigurationsdatei übernehme?

MfG

Mr. Frogman

[rksteve]

Wenn du eine Konfig von einer älteren Kernelversion verwendest kannst du
make oldconfig
verwenden, dann kannst du dort entscheiden was du von den neu hinzugekommenen Treibern verwenden willst. (ich weiss jetzt nicht was in Testing für eine Kernel-Version dabei ist)
Hast du auch die Module kompiliert und installiert?
lg,
Steve

[cirrussc]

... damit war der Kernel ja wie mein jetztiger konfiguriert (ist ein Debian Testing), aber nach dem Kompilieren fuhr der Rechner trotzdem nicht hoch, weil er wohl ein VFS nicht mounten konnte.

Das ist sicher bekannter Effekt.
Je nachdem was du vorher für einen Kernel hattest, jetzt wird sicher libata verwendet und die device Einträge der fstab stimmen nicht mehr.
Entweder anpassen oder besser, auf UUID bzw Label umstellen (Forensuche).

[crazyed]

Das hier ist zwar nicht Debian spezifisch, aber hier wird einiges beim Kernelbau Schritt für Schritt erklärt.

[MrFrogman]

Guten Morgen!

... und ein frohes neues Jahr euch allen erstmal

Vielen Dank für die zahlreichen Tips, werde mich wohl einfach nochmal etwas mehr in Fachlektüre vertiefen, das wird mit Sicherheit helfen!

MfG

Mr. Frogman