• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kernel bauen

tux94

Newbie
Hallo, bin neu hier im Forum :D
Nach nem Dreivierteljahr Linux-Erfahrung wollte ich auch mal meinen eigenen Kernel backen. Dafür muss ich euch aber vorher mit ein paar Fragen löchern :wink: :
Wann kommt Kernel 2.6.24 raus und welche Vorteile bringt er gegenüber dem 2.6.23er?
Es ist ja immer davon die Rede, dass Suse in "seinen" Kernel immer spezielle Patches einbaut (Apparmor, Bootsplash).
Wo kriegt man die her und wie baut man die ein?
Wie ist das mit den ACPI Funktionen? Als ich letztens die neue 10.3 installiert hab, habe ich mit Freude festgestellt, dass die meisten Hotkeys auf meinem Notebook jetzt auch funktionieren. Werden diese vom Kernel oder von KDE/Gnome gesteuert?
Was muss ich da bei den Kernelmodulen beachten?
Vor kurzem hab ich mal zum Test den 2.6.24-rc3 kompiliert, hat ganz gut funktioniert, allerdings hatte ich halt kein AppArmor, keinen Bootsplash und kein X (wegen fehlendem Nvidia-kernelmodul, klar).
Vielen Dank schonmal
 

Gimpel

Guru
tux94 schrieb:
Hallo, bin neu hier im Forum :D
Na dann herzlich willkommen :)
Wann kommt Kernel 2.6.24 raus und welche Vorteile bringt er gegenüber dem 2.6.23er?
Wenn er fertig ist. Die Vorteile von neueren kerneln sind prinzipiell immer: neue Treiber, neue features. Siehe dazu dann den changelog.
Es ist ja immer davon die Rede, dass Suse in "seinen" Kernel immer spezielle Patches einbaut (Apparmor, Bootsplash).
Wo kriegt man die her und wie baut man die ein?
Aus dem kernel .src.rpm zum Beispiel. "Einbauen" tut man die mit patch, oder bei ganzen serien mit tools wie quilt.
Wie ist das mit den ACPI Funktionen? Als ich letztens die neue 10.3 installiert hab, habe ich mit Freude festgestellt, dass die meisten Hotkeys auf meinem Notebook jetzt auch funktionieren. Werden diese vom Kernel oder von KDE/Gnome gesteuert?
Kommt drauf an, eigentlich werden die vom X server angesprochen.
Was muss ich da bei den Kernelmodulen beachten?
Vor kurzem hab ich mal zum Test den 2.6.24-rc3 kompiliert, hat ganz gut funktioniert, allerdings hatte ich halt kein AppArmor, keinen Bootsplash und kein X (wegen fehlendem Nvidia-kernelmodul, klar).
Vielen Dank schonmal
apparmor, bootsplash und alles was nicht im sog. vanilla kernel ist, musst du selber reinpatchen.
Den nvidia treiber muss man auch selbst installieren nach jedem kernel wechsel/update.
 
OP
T

tux94

Newbie
Es ist ja immer davon die Rede, dass Suse in "seinen" Kernel immer spezielle Patches einbaut (Apparmor, Bootsplash).
Wo kriegt man die her und wie baut man die ein?

Aus dem kernel .src.rpm zum Beispiel. "Einbauen" tut man die mit patch, oder bei ganzen serien mit tools wie quilt.

Ich hab die kernel sources vom Yast eingetragen sind installiert.
Wo finde ich denn jetzt die Patches?
 

Appleonkel

Hacker
tux94 schrieb:
Aus dem kernel .src.rpm zum Beispiel. "Einbauen" tut man die mit patch, oder bei ganzen serien mit tools wie quilt.

Ich hab die kernel sources vom Yast eingetragen sind installiert.
Wo finde ich denn jetzt die Patches?

kernel-source-$version.$arch.rpm ist nicht das selbe wie kernel-source-$version,src.rpm. Das heisst du musst in das src.rpm schauen. In der kernel-source-$version.$arch.rpm was du wahscheinlich installiert hast, ist schon alles gepatcht ;)

Beispiel für 10,3
Code:
rpm -i http://download.opensuse.org/distribution/10.3/repo/src-oss/suse/src/kernel-source-2.6.22.5-31.src.rpm
cd /usr/src/packages/SOURCES/
ls patches.*
Nun siehst du eine Reihe von Paketen in den die patches sind die openSUSE im Kernel hat.

mfg Appleonkel
 
OP
T

tux94

Newbie
OK
ich hab jetzt lauter tar Archive.
Ich hab z.b. das Apparmor Archiv entpackt und hab einen ganzen Haufen *.diff Dateien.
Muss ich die alle patchen???
 
OP
T

tux94

Newbie
Wie mach ich das am schnellsten?
Soll ich ein Shell-Skript schreiben?
Achja, muss ich wirklich alle patches anwenden, ich hab grad in der series.conf bei reiserfs patches gelesen:
These are currently known to cause corruption on disk. :oops:
Bekomm ich dann eigentlich noch über den Suse-Updater Kernel-Updates?
Wenn nicht, wie bleib ich dann auf dem laufenden?
Greetz
 

Gimpel

Guru
tux94 schrieb:
Wie mach ich das am schnellsten?
Soll ich ein Shell-Skript schreiben?
Ein bash loop tut's auch.
Code:
for i in `grep apparmor series.conf`; do patch -d /pfad/zu/deiner/kernel-source -p1 < $i;done
..so in der art.
Achja, muss ich wirklich alle patches anwenden, ich hab grad in der series.conf bei reiserfs patches gelesen:
These are currently known to cause corruption on disk. :oops:
Du musst garnix :)
Bekomm ich dann eigentlich noch über den Suse-Updater Kernel-Updates? Wenn nicht, wie bleib ich dann auf dem laufenden?
Updates gibts nur für den SuSE kernel, welchen du ja gerade, aus welchem Grunde auch immer, 1zu1 nachzubauen scheinst.
 
OP
T

tux94

Newbie
Updates gibts nur für den SuSE kernel, welchen du ja gerade, aus welchem Grunde auch immer, 1zu1 nachzubauen scheinst.
Naja, ich will halt einen Kernel der optimal mit Suse zusammenspielt

Was mach ich denn bei einem Sicherheitsproblem? Den ganzen Kernel neu compilen oder nur ein paar Module?

Achja, muss ich wirklich alle patches anwenden, ich hab grad in der series.conf bei reiserfs patches gelesen:
These are currently known to cause corruption on disk. :oops:
Du musst garnix :)

Welche patches SOLLTE ich dann anwenden, was habt ihr denn so Erfahrungen gemacht?
 

Gimpel

Guru
tux94 schrieb:
Updates gibts nur für den SuSE kernel, welchen du ja gerade, aus welchem Grunde auch immer, 1zu1 nachzubauen scheinst.
Naja, ich will halt einen Kernel der optimal mit Suse zusammenspielt

Was mach ich denn bei einem Sicherheitsproblem? Den ganzen Kernel neu compilen oder nur ein paar Module?
Die entsprechenden patches hinzufügen/bzw den source tree updaten, und das Ding neu bauen.

Welche patches SOLLTE ich dann anwenden, was habt ihr denn so Erfahrungen gemacht?
Ich glaub kaum jemand hier zerlegt den SuSE kernel und baut ihn anschliessend nur halb wieder zusammen.
Die defekten reiserfs patches in der series.conf sind sicher #auskommentiert, ansonsten wäre das ja grob fahrlässig.
 
Oben