2Fragen: Modul-Installation und custom-Kernel-Aktualisierung

[bumer]

Hallö,

Habe 2 Fragen zum Modul-Management und bezüglich der Aktualisierung eines kompilierten Kernel:

Wenn ich vergessen haben sollte einem speziell für meine Bedürfnisse kompilierten (custom) Kernel ein Modul hinzuzufügen und es sich später herausstellt, dass ich dieses Modul benötige, dann kann ich es nicht einfach mit kmod (modprobe) dauerhaft einbinden/integrieren, da es 1. gar nicht verfügbar ist im custom-Kernel und 2. wenn es verfügbar wäre und mit modprobe eingebunden wurde, dann nur für die aktuelle Session und nicht dauerhaft. Also muss ich den Kompilierungsvorgang wiederholen um dieses Modul dauerhaft zu laden – habe ich das so richtig verstanden?

Ich habe gelesen, dass wenn man einen Kernel von Kernel.org kompiliert und ihn "frisiert" bzw. den eigenen Bedürfnissen / Hardware anpasst, dass man diesen nur durch Patches updaten kann. Trifft das auch zu wenn ich den Debian-eigenen (Name in den Paketquellen: linux-image-VERSION-ARCHITEKTUR) Kernel aus den Paketquellen kompiliere und auf meine Bedürfnisse anpasse? Ich denke dem ist nicht so, trotzdem möchte ich es hier gerne bestätigt bekommen. Es geht mir um diverse Updates zB um die Sicherheitsaktualisierungen: Muss ich für den Debian-eigenen-auf-meine-Bedürfnisse-zugeschnitten-Kernel Patches laden, oder können Aktualisierungen weiterhin über aptitude (Paketquellen u-updaten und U-laden), bzw aus den Paketquellen heraus, installiert werden?

Grüße,
bumer

[cosmac]

hö!

Wenn du ein Modul vergessen hast, musst du neu kompilieren, da hilft nichts. Das geht dank "make" aber sehr viel schneller als beim ersten Mal. Dann kannst du dir aussuchen, ob du das Modul fest einbauen willst oder beim booten mittels modprobe laden willst. Auf den meisten Rechner wird modprobe doch sowieso gebraucht, der eine Aufruf mehr sollte doch nicht das Problem sein? Das sagt jemand, der praktisch alles fest einbaut

Ich habe gelesen, dass wenn man einen Kernel von Kernel.org kompiliert und ihn "frisiert" bzw. den eigenen Bedürfnissen / Hardware anpasst, dass man diesen nur durch Patches updaten kann.

Das ist wohl die normale Methode. Aber du kannst auch den kompletten Quelltext holen (oder als Debian-Paket per aptitude update beziehen) und dann erneut deine Anpassungen einbauen. Das die einfachere Methode, dauert aber deutlich länger. In dem Fall könntest du deine Anpassungen als Patch einspielen.

Ob du die Quellen von kernel.org oder als Debian-Paket bekommst ist egal. Patchen und neu kompilieren musst du immer. Es kann ja keine Debian-Pakete geben, in denen deine Anpassungen schon eingebaut sind¹. Updates per aptitude für einen Eigenbau-Kernel kann ich mir nicht vorstellen. Der Kernel ist ja aus einem Stück und muss deshalb immer kompiliert werden².

1) du kannst natürlich selbst ein Paket bauen, das kann sich bei mehreren Rechnern lohnen
2) Ja, es gibt ksplice. Ja, man könnte ein einzelnes Modul ersetzen, aber das bietet Debian nicht an und es würde auch selten etwas nützen.

[bumer]

Hi cosmac! Danke für die Info!

Das geht dank "make" aber sehr viel schneller als beim ersten Mal.

Inwiefern schneller? Meinst du make-kpkg, oder gibt es einen speziellen make-Befehl, der nur das neu-hinzugekommene Zeugs neu-reinkompiliert? Könntest du bitte etwas näher darauf eingehen?

Ob du die Quellen von kernel.org oder als Debian-Paket bekommst ist egal.

Ich habe den 3.2.60er aus den Debian-Paketquellen heruntergeladen und konfiguriert. Es ist also egal, ob ich den Kernel aus den Debian-Paketquellen oder von Kernel.org für ein Debian-System nutze. Die Frage ist jetzt ob ich diesen 3.2.60er aus den Debian-Paketquellen mit einem Patch von Kernel.org updaten kann? Oder muss ich warten bis eine neue Version in den Debian-Paketquellen auftaucht? Also wie ich die Patches einspiele, werde ich mir schon durchlesen, meine Frage bezieht sich eigentlich nur darauf, ob der 3.2.60 von Debian, der gleiche ist wie der 3.2.60er von Kernel.org, bzw. ob ich einen Debian-Kernel mit einem Kernel.org-Patch updaten kann?

Updates per aptitude für einen Eigenbau-Kernel kann ich mir nicht vorstellen.

Das ist mir nicht ganz klar, obwohl ich nicht bestreite, dass es so korrekt ist, aber: Das Kompilieren stellt doch einfach einen Prozess dar in dem ich nur Treiber entferne/hinzufüge. Ein Update des Kernels hat doch im eigentlichen Sinne nichts mit den Treibern zu tun, oder? Updates der Treiber müssten doch alle in den Paketquellen verfügbar sein, da die Paketquellen ja alles, was die Stand-Installation bereit stellt, abdecken, oder? Ich erstelle keine neuen eigenen Pakete. Das Kernel-Update aber aktualisiert doch die eigentlichen Kernel-Dateien, die bei mir noch die gleichen sein müssten, egal wie viele Treiber ich noch im System unterstütze oder entfernt habe? Mir ist das Prinzip nicht ganz klar wieso ich nicht Kernel-Daten über die Debian-Paketquellen updaten kann, ein Patch von Kernel.org hilft da aber weiter – die wissen doch im Endeffekt auch nicht was ich mit dem Kernel angestellt habe, wieso passt der dann (der Patch)?

Grüße,
bumer

[smutbert]

Die Treiber sind Teil des Linuxkernels und können entweder fix in den Kernel kompiliert werden oder als Modul (oder gar nicht) übersetzt werden, wobei das nicht nur für (Hardware)treiber sondern auch für andere Bestandteile des Kernels gilt, zB Netzwerkprotokolle, Scheduler,…

Einige Dinge braucht der Kernel fix drin, damit er überhaupt starten kann, zB muss er ohne Module das /-Dateisystem lesen können (damit man mit weniger fix einkompilierten Teilen auskommt, ist das erste /-Dateisystem meist eine initrd), aber das nur am Rande.


Wenn ein Treiber direkt in den Kernel soll, es aber nicht ist, kommt man um ein Neukompilieren nicht herum, will man aber nur ein Modul haben, das nicht vorhanden ist, so kann man es auch kompilieren, ohne gleich den kompletten Kernel neu zu kompilieren. Das wird zB bei außerhalb des Kernels gepflegten Modulen so gemacht, zB den proprietären Grafiktreibern von AMD und Nvidia.
Bei Treibern, die aber ohnehin in den Kernelquellen verfügbar sind, bedeutet dieses Vorgehen üblicherweise mehr Aufwand, als es das komplette Kompilieren des Kernel erfordern würde.



und jetzt noch zu dem, was Debian zur Verfügung stellt:

• linux-image-Version-abiname-Architektur
  Diese Pakete enthalten sowohl den eigentlichen Kernel, das Linuximage (meist /boot/vmlinuz-Version-Architektur) wie auch die Module in /lib/modules/Version-Architektur
• linux-headers-Version-abiname-Architektur
  Die Header sind eigentlich ein kleiner Teil des Quellcodes, in diesem Zusammenhang Dateien, die grundlegende Dinge des Kernel definieren, zB APIs. Die sind nötig, damit Software kompiliert werden kann, die Funktionen des Kernels nutzt, wie zB die erwähnten proprietären Grafiktreiber von AMD oder Nvidia.
  Meines Wissens sollten die Header auch ausreichen um Module, die man vergessen hat, zu kompilieren, aber wie gesagt, ist das aufwändig (und ich habe es noch nie versucht).
• linux-sources-Version
  enthält den kompletten Quellcode des Linuxkernels inklusiver der Patches, die Debian eingespielt hat. Wenn ich mir ausnahmesweise selbst einen Kernel gebaut habe, habe ich meistens einfach so ein Paket installiert.
  Natürlich könnte man auch den Quellcode direkt von kernel.org nehmen und so unter Umständen eine aktuellere Kernelversion zu erhalten.

Wer sich seinen eigenen Kernel kompiliert, muss ihn sich nach jedem Update neu kompilieren, egal, ob der die vorhandenen Quellen patcht, sich ein neues vollständiges Archive von kernel.org holt oder einfach ein linux-sources-… Paket aktualisiert.

Das Kompilieren geht beim zweiten Mal mit allen Tools schneller, weil afaik alle im Endeffekt auf make zurückgreifen, das es bereits so macht, wie cosmac beschrieben hat. Bei einem Update hilft dir das aber nicht unbedingt viel, weil man da entweder sowieso von einem neuen Sourcecodetree ausgeht oder im gepatchten das bereits übersetzte löscht, um sicherzugehen, dass keine alten bereits kompilierten Teile, die sich inzwischen aber geändert haben, im neuen Kernel landen.

[bumer]

Danke smutbert.

Kann ich einen 3.2.60er-Kernel aus den Debian-Paketquellen mit einem Patch von Kernel.org auf 3.2.62 updaten? Macht es einen Unterschied, dass der jetzige Kernel aus den Debian-Paketquellen stammt, der Patch aber von Kernel.org, oder ist das egal?

Kann ich auf einem 7.5er Wheezy-System einen 3.16er-Kernel von Kernel.org installieren und problemlos nutzen?

Grüße,
bumer

[cosmac]

Das geht dank "make" aber sehr viel schneller als beim ersten Mal.

Inwiefern schneller? Meinst du make-kpkg, oder gibt es einen speziellen make-Befehl, der nur das neu-hinzugekommene Zeugs neu-reinkompiliert?

make-kpkg hat damit nichts zu tun. Ein einfaches "make" reicht und kompiliert genau so viel wie nötig. Wenn die Kernelquellen frisch ausgepackt sind, muss je nach config fast alles übersetzt werden, das ergibt über 2000 Dateien, die dann zum Kernel-Image zusammen gebaut werden. Dazu kommen noch die einzelnen Module.

Wenn du jetzt noch ein weiteres Modul brauchst, muss (im günstigsten Fall) nur noch eine Datei übersetzt werden, der Rest ist ja noch vom letzten Mal da. Mit einem Patch werden auch nur wenige Dateien verändert und nur die müssen neu übersetzt werden. Zwar müssen alle 2000+ wieder zusammen gebaut ("gelinkt") werden, aber das geht sehr viel schneller als das kompilieren.

make geht vom Endprodukt aus (dem Kernel-Image) und sucht die Bausteine, die dafür nötig sind. Bei jedem einzelnen Baustein sucht es wiederum, was dafür gebraucht wird. Nur das, was fehlt oder (nach einem Patch) veraltet ist, wird neu übersetzt. Das spart meist viel Zeit, aber es gibt auch config-Änderungen, nach denen überraschend viel neu übersetzt werden muss; ich musste gerade den cgroup support einbauen, das war so ein Fall.

Die Frage ist jetzt ob ich diesen 3.2.60er aus den Debian-Paketquellen mit einem Patch von Kernel.org updaten kann?

im Prinzip ja, aber es kommt darauf an, ob sich der mit einem Debian-Patch überschneidet. Zum Beispiel könnte Debian einen Schönheitsfehler schon gepacht haben. Wenn später der offizielle Patch dazu kommt, passt der nicht zum Debian-Quellcode (er geht ja vom Original aus), dann verweigert patch. Keine Ahnung, wie oft das im wirklichen Leben passieren würde.

meine Frage bezieht sich eigentlich nur darauf, ob der 3.2.60 von Debian, der gleiche ist wie der 3.2.60er von Kernel.org?

nein, Debian ist recht Patch-freudig. Du kannst aber von Debian alle Patches auch einzeln bekommen und auch die Original-Quellen.

Ein Update des Kernels hat doch im eigentlichen Sinne nichts mit den Treibern zu tun, oder?

Theoretisch hast du Recht, praktisch lässt sich Debian nicht darauf ein. Treiber und Kernel müssen zusammen passen und man müsste von Fall zu Fall entscheiden, ob sich dieses Update auf die Treiber auswirkt. Deshalb gibt es im Paket immer nur alles zusammen.

Das Kernel-Update aber aktualisiert doch die eigentlichen Kernel-Dateien, die bei mir noch die gleichen sein müssten, egal wie viele Treiber ich noch im System unterstütze oder entfernt habe?

Das Update ersetzt auch alle Module. Solche, die du entfernt hast, sind anschließend wieder da und selbst gebaute passen nur vielleicht zum neuen Kernel.

Mir ist das Prinzip nicht ganz klar wieso ich nicht Kernel-Daten über die Debian-Paketquellen updaten kann, ein Patch von Kernel.org hilft da aber weiter?

das ist eine Missverständnis, es geht zwei verschiedene Vorgänge. Ein Update kann deine Kernelquellen nicht updaten und neu kompilieren, das musst du selbst machen. Dafür brauchst du einen Patch. Ob der von kernel.org oder debian.org kommt, ist egal.

Kann ich auf einem 7.5er Wheezy-System einen 3.16er-Kernel von Kernel.org installieren und problemlos nutzen?

Die offiziellen Schnittstellen des Kernels sind ungefähr das stabilste, was es in und um Debian gibt. Insofern kannst du einen neueren Kernel problemlos verwenden. Aber: die Schnittstelle zwischen Kernel und udev ist anscheinend nicht soo offiziell, sie hat sich in der Vergangenheit oft geändert. Zu einer Kernel-Version passen also immer nur bestimmte udev-Versionen. Und du kannst udev nicht updaten, die jessie-Version wird nicht unter wheezy laufen (wenn sie sich überhaupt installieren lässt). Man merkt auch nicht sofort, ob udev und Kernel sauber zusammenspielen (es wird ja nicht immer alles geändert). Also: wahrscheinlich geht's, probier's aus, immer mit einem Auge auf Fehlermeldungen in /var/log/syslog. Ich würde dafür auch den Boot-Parameter "quiet" entfernen.

[bumer]

Danke für die Antwort.

So wie ich das ganze verstehe ist es am besten die Kernel entweder nur direkt von Debian zu beziehen oder nur bei Kernel.org-Dateien zu bleiben. Beide zu mixen könnte also Probleme mit sich führen.

[cosmac]

Einfacher ist es auf jeden Fall. Ich würde bei Debian bleiben, der eine oder andere Debian-Patch mag ja durchaus nützlich sein.