Kernel modifizieren, aber ohne komplette Neukompilierung

[TiTux]

Hallo,

über die SuFu und über habe ich dazu nichts gefunden. Worum es geht:

Ich habe mir einen neuen Kernel gebastelt (make-kpkg kernel_image --revision=name --initrd) und das fertige .deb Paket installiert.
Alles wunderbar. Wenn ich jetzt aber nachträglich noch eine Kleinigkeit ändern möchte,
was sich also auf das entfernen/hinzufügen von z.B. Modulen bezieht, möchte ich nicht,
dass er wieder ein ganz neues .deb Paket erzeugt, sondern mein altes .deb Paket sozusagen
patch. Wie muss ich dafür vorgehen. Hat das was mit "dpkg-reconfigure kernel-image" zutun, und wenn ja, wie genau muss ich vorgehen?

Ciao TiTux

[KBDCALLS]

Was für ein Kernel? Und um was für ein Modul geht es denn? Gehört es zu Kernel, oder stammt es von externen Sourcen?

Entfernen ist eigentlich kein Problem.

Lösche es aus dem Modulbaum und lasse

Code: Alles auswählen

 
depmod -a

laufen.

[peschmae]

Ich sehe den Sinn nicht ganz. Ich meine wenn du das Ding eh schon mal kompilierst hat geht das kompilieren sowieso ganz schnell (make sei Dank) und das Packen am Ende dauert auch nicht wirklich lange.

MfG Peschmä

[KBDCALLS]

Setz aber voraus das er den kompletten Sourcecode auf der Festplatte hat und noch nicht aufgeröumt hat in dem Source.

[TiTux]

Uups,

meine Angaben waren etwas dünn. Es handelt sich um einen 2.6.12.3 Kernel unter Sarge.
Die Frage hat sich allgemein aufgetan. Ein Freund von mir betreibt einen VDR und bei
ihm geht es um externe Sourcen, speziell um das LIRC Modul. Das wollte er nachträglich
einkompilieren, ohne den kompletten Kernel neu übersetzen zu müssen.

Was den Sinn angeht: Wenn ich meinen Kernel ändern möchte, rufe ich z.b. menuconfig auf,
mache meine Änderungen und bastel danach mein Paket, dass kompilieren dauert jetzt ne guten halbe Stunde,
obwohl sich beim Rest ja nix geändert hat, dass möchte ich halt aufs nötigste reduzieren und dachte,
dass man diese "Anpassung" schneller hinbekommt.

@KBDCALLS: Dumme Frage von einem newbie: Welche Datei bezeichnest Du als
Modulbaum?

Gruß TiTux

EDIT: Kernelsource liegt auf der Platte

[KBDCALLS]

@KBDCALLS: Dumme Frage von einem newbie: Welche Datei bezeichnest Du als
Modulbaum?

Gruß TiTux

EDIT: Kernelsource liegt auf der Platte

Vieleicht nicht ganz korrekter Ausdruck aber ich meinte das Verzeichnis da wo die Kernelmodule zu finden sind.

Zum Beispiel hier

Code: Alles auswählen

/lib/modules/2.6.12-0-k7/

[TiTux]

Ich muss also in meinem Fall in den folgenden Pfad gehen:

Code: Alles auswählen

/lib/modules/2.6.12.3/kernel/

Dort dann in das jeweilige Unterverzeichnis
und die gewünschte .ko Datei löschen.

Danach ein depmod -a und beim nächsten Start ist das Modul wech.

So richtig?

Und wenn ein neues Modul mit dazu soll? Dann doch komplett neu kompilieren?

[chabayo]

...ein modul auf die art zu verwerfen ist ja fast vulgär...find ich...

...gehts jetzt da drum ein modul zu eliminieren weil man es einfach vernichten, ins ewige nichts zu schicken, gedenkt, oder will man es einfach nicht im laufenden system eingebunden haben...

...ein grundsaetzlicher unterschied - was will er davon haben das modul nicht mehr auf der festplatte zu haben - 50kb speicher auf der festplatte??

...da kommt dann meine unwissenheit mit ins spiel:

so wie ich debian verstehe ladet er die in '/etc/modules' aufgefuehrten module zum start

...schlagt mich, aber will der nicht dahin?


P.S. - ein modul vom fremdanbieter kann man doch in den 'modulbaum', z.b. nach '/lib/modules/$(uname -r)/extra' kopieren, und dann vielleicht mit 'depmod -a' (?richtig) dem modprobe system mitteilen, welches dann per modprobe eingebunden wird...alternativ kann man en modul auch mit insmod einbinden...rmmod nimmt es dann wieder aus der laufzeitumgebung heraus...oder? hm, und dann noch lsmod, zeigt welche module der kernel immo anwendet...

[TiTux]

Hmm,

ok, lassen wir das löschen von Modulen einmal weg, im wesentlichen gehts mir darum,
ein Beispiel:

Ich hab vergessen, den Vesa Framebuffer mit in den Kernel zu kompilieren, es gibt ihn
also weder fest mit drin noch als Modul nachladbar. Ansonsten bin ich mit dem Kernel
hochzufrieden. Wie bekomme ich jetzt also im nachhinein den Framebuffer mit eingebunden,
ohne alles komplett neu zu kompilieren. Das gleiche würde mich interessieren, wenn ich eine
externe Source mit einbinden möchte. Es ging eingentlich weniger um das löschen von
Modulen, Sorry, wenn das so verstanden wurde.

Gruß TiTux

[chabayo]

...meiner ansicht nach waer es am einfachsten, wenn du nur ein modul, also einen treiber fuer ein neues geraet, dem bestehenden kernel hinzufuegst folgendes:

$ make menuconfig

wie du hier dein modul anwaehlst scheinst du schon zu wissen

$ make modules

ich denke er macht da alle module durch, wenn da kein make clean vorher irgendwie zustandekam max. ne sache von 5 minuten, maximal

$ make modules_install

das kopiert dir alle module wieder in den 'modulbaum', und macht auch nen depmod durchlauf

#

jetzt solltest du dein modul mit modprobe fuer den einsatz einbinden koennen, und wie gesagt, um es beim boot zu laden es in der datei /etc/modules eintragen (ohne die endung wie sie module haben .o/.ko)

[KBDCALLS]

Also das Framebuffer Modul gehört ja zu Kernel-source. Wenn ich ebend vorhin gesagt der Komplette Source samt Kompilat noch vorhanden ist . Konfiguriest du den Kernel einfach neu, und erstellst ein neues Deb mit dem gleichen Namen. Es werden nur die Teile vom Kernel neu kompiliert die sich auch in der Konfiguration geändert haben ((im günstigsten Fall nur die Framebuffermodule)und anschließend wird das neue Deb geschnürt, was du dann einfach drüberinstallierts, trotz identischer Versionsnummer geht das ohne Probleme. Make bzw make-kpkg macht das schon.

Zu den externen Modulen, also die nicht zum Kernel gehören. Entweder sind die Sourcen dieser Module so geschreiben das man sie mittles
patch in den Kernelsource integrieren kann. Oder man muß sie außerhalb des Kernelsource kompilieren. Der einfachste Fall man hat einen Debiankernel und den Quelltext gibt es als Debiansourcen. Dann braucht man nur die passenden Kernelheaders und kann das Modul kompileren. Gibt es dieses Modul nicht als Debianquelltext dann wird es etwas aufwendiger, aber das ist von Modul zu Modul verschieden, es ist das beste man konsultiert das README der Sourcen.

[TiTux]

THX

Genau das hab ich gesucht, was KBDCALLS im ersten Abschnitt beschrieben hat.
So klappt das wunderbar. Das man einfach über ein bestehendes deb drüberinstallieren
kann, hab ich nirgends vorher gelesen. Ich hatte testhalber das reiserfs Modul mit reingenommen, was danach auch auffindbar war.
Als anderen Test hab ich allerdings
noch das Logo Bild (der Pinguin) vorher in die Kernelsourcen ausgetauscht. Das hat er
allerdings nicht berücksichtigt und mein altes Logo angezeigt, weiß nicht warum, aber ist auch egal.

Was die externen Module angeht, dass werde ich bei einem Kumpel testen, der ja vor dieser
Aufgabe sitzt.

Vielen Dank,

TiTux


PS: Eine Frage hätte ich noch: wofür benötigt man jetzt noch die Option:

Code: Alles auswählen

dpkg-reconfigure kernel-image

?

[KBDCALLS]

Mit

Code: Alles auswählen

dpkg-reconfigure kernel-image

Könnte man eine neue Initrd erstellen. Wenn mans beim

Code: Alles auswählen

make-kpkg  --initrd kernel-image

angegeben hat, da eine erstellt werden soll, Auch wird die menu.lst des Bootmanagers (Grub) hiemit neu erstellt.

[armin]

Also das Framebuffer Modul gehört ja zu Kernel-source. Wenn ich ebend vorhin gesagt der Komplette Source samt Kompilat noch vorhanden ist . Konfiguriest du den Kernel einfach neu, und erstellst ein neues Deb mit dem gleichen Namen. Es werden nur die Teile vom Kernel neu kompiliert die sich auch in der Konfiguration geändert haben ((im günstigsten Fall nur die Framebuffermodule)und anschließend wird das neue Deb geschnürt, was du dann einfach drüberinstallierts, trotz identischer Versionsnummer geht das ohne Probleme. Make bzw make-kpkg macht das schon.

Bist du dir sicher?
Ich denke (glaube die Erfahrung gemacht zu haben), dass nach einer Konfigurationsänderung erstmal ein make-kpkg clean ansteht, damit das alles sauber übernommen wird

@TiTux Du kannst dir aber mal ccache ansehen - ist in solchen Fällen ganz praktisch.

[KBDCALLS]

Bist du dir sicher?
Ich denke (glaube die Erfahrung gemacht zu haben), dass nach einer Konfigurationsänderung erstmal ein make-kpkg clean ansteht, damit das alles sauber übernommen wird

Habs schon selbst gemacht. und es hat auch geklappt.

[K@sperl]

Wenn man den Kernel mit make-kpkg kompiliert, braucht man nur die Datei stamp-build zu löschen damit nicht der Kernel komplett neu übersetzt wird.

[gms]

Ich denke (glaube die Erfahrung gemacht zu haben), dass nach einer Konfigurationsänderung erstmal ein make-kpkg clean ansteht, damit das alles sauber übernommen wird

Das ist auch DIE Methode mit "Sauberkeitsgarantie". Die andere Methode wird in den meisten Fällen funktionieren. Selbst dann, wenn sie nicht funktioniert, wird dieses Problem dann in den meisten Fällen (bei Modulen warscheinlich sogar immer) auch frühzeitig erkannt werden. Entweder durch Fehler beim Compilieren oder spätestens bei Depmod.

Gruß
gms

[TiTux]

Letzte Frage noch:

Wofür würde ich evtl. eine neue initrd benötigen? Was kann sich da ändern,
dass ich eine neue brauche?

Ciao TiTux

[KBDCALLS]

Ich denke (glaube die Erfahrung gemacht zu haben), dass nach einer Konfigurationsänderung erstmal ein make-kpkg clean ansteht, damit das alles sauber übernommen wird

Das ist auch DIE Methode mit "Sauberkeitsgarantie". Die andere Methode wird in den meisten Fällen funktionieren. Selbst dann, wenn sie nicht funktioniert, wird dieses Problem dann in den meisten Fällen (bei Modulen warscheinlich sogar immer) auch frühzeitig erkannt werden. Entweder durch Fehler beim Compilieren oder spätestens bei Depmod.

Gruß
gms

Genau der Fall Treiber nachkompilieren ist ja im Makefile des Kernels vorgesehen, von ganzen Bäumen bis zum einzelnen Treiber.

Und wenn ich einen Kernelsource wirklich sauber haben will dann wurde ich ein

make distclean oder make mrproper noch hinterherschicken

[KBDCALLS]

Letzte Frage noch:

Wofür würde ich evtl. eine neue initrd benötigen? Was kann sich da ändern,
dass ich eine neue brauche?

Ciao TiTux

In der Regel wird zwar keine neue benötigt. Aber es kann durchaus sein , das ich zusätzlich Treiber in einer Initrd noch reinhaben will laden will oder die Reihenfolge beeinflussen will. Die wird aber auch nur bebraucht wenn der so kompiliert worden ist, wie ein Original Debiankernel. Mit anderen Worten der nackte Kernel ohne Initrd ist nicht in der Lage auf das Dateisystem der Bootpartition zuzugreifen. Sei es das die Festplattentreiber fehlen oder der Dateisystemtreiber.

[TiTux]

Danke für Eure Antworten, irgendwie interessiert mich das Kernel basteln schon sehr,
sollte mir evtl. das Buch leisten: http://www.amazon.de/exec/obidos/ASIN/3 ... 91-6955266

Ciao Rainer