Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 30.11.2020 17:22:25

towo hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 16:58:58
Alles, was als Modul konfiguriert wird, landet in /lib/modules/$(uname -r)/kernel.
Okay ... *grübel*
Dann frage ich mich, wieso meine initrd immer so gross wird...muss das nochmal checken...
towo hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 16:58:58
Was in der Ramdisk landet, wird nicht von Kernel bestimmt, sondern von den initramfs-tools.
Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?
Und da sollte alles landen, was der Kernel zum weiteren Booten braucht (also was meine HW an Chipset, Eingabegeräte, Festplatte/Controller und Grafik hat)?
fischic hat geschrieben: Dann lass sie doch weg.
Ja, darauf arbeite ich - letztendlich - hin, aber ein Verständnis-Schritt nach dem anderen :) ...
fischic hat geschrieben: Aber du hast bisher, soweit ich das verfolge, noch nirgends erklärt, was du eigentlich erreichen willst mit deinem selbstgebauten Kern.
Naja
1. Wollte ich mir mal selber einen Kernel bauen --> Erfahrung, Interesse
2. dachte ich, dass ein neuerer Kernel (bzw. auh durch die eigene Konfiguration bedingt) auch z.B. mehr in Richtung Bluetooth, USB-Dongle, etc. unterstützt
3. ... und eventuell den Bootprozess etwas beschleunigen (da der Standardkernel(+initrd) recht flott bootet) ...
fischic hat geschrieben: Dein Focus initrd vs. lib/modules/... ist wenig sinnvoll, siehe towo.
Verstehe ich nicht...
Wieso "wenig sinnvoll"?
Wenn ich es schlussendlich schaffe, dass ich entweder die initrd genz klein bekomme, oder gar weglassen kann, dann bootet doch die Kiste ja auch schneller und ich hab trotzdem die "volle" Hardwareunterstützung, da ja alles als Modul(e) zum späteren Zeitpunkt geladen werden kann...?

Benutzeravatar
towo
Beiträge: 4400
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von towo » 30.11.2020 18:05:04

Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?
Was hast Du immer mit make?
Wärend des Kernel-Baus wird keine initrd erzeugt. Das passiert erst beim installieren des Kernels.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 30.11.2020 18:12:04

towo hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 18:05:04
Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?
Was hast Du immer mit make?
Wärend des Kernel-Baus wird keine initrd erzeugt. Das passiert erst beim installieren des Kernels.
Na, 'make install' installiert doch den Kernel, bzw. leitet die Installation ein..?

Benutzeravatar
towo
Beiträge: 4400
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von towo » 30.11.2020 18:16:12

Wenn Du, wie dir geraten wurde, make bindeb-pkg einsetzt, dann wird auf Deinem System kein make install abgesetzt, und in dem resultierenden Paket ist keine initrd enthalten.
Nochmal, diese wird durch einen hook von dpkg beim Installieren des Kernel-Paketes mittels der initramfs-tools erzeugt.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 30.11.2020 18:26:47

towo hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 18:16:12
Wenn Du, wie dir geraten wurde, make bindeb-pkg einsetzt, dann wird auf Deinem System kein make install abgesetzt, und in dem resultierenden Paket ist keine initrd enthalten.
Jupp, das wurde mir geraten. Und ich erinnere mich, dass es da darum ging, dass keine Debug-Informationen mit in den Kernel gepackt werden. Aber dass dabei [auch] keine initrd erzeugt wird, habe ich nirgends gelesen (oder es überlesen, demfall sorry).
towo hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 18:16:12
Nochmal, diese wird durch einen hook von dpkg beim Installieren des Kernel-Paketes mittels der initramfs-tools erzeugt.
Aha(!), okay.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 06.12.2020 10:50:10

worker777 hat geschrieben:
KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 16:10:13
worker hat geschrieben:...dass der Kernel von der Grösse her so ziemlich dem Standard-Kernel entspricht, jedoch ist die initrd ca. 10 mal so gross, wie die vom Standard-Kernel...
Diese Aussage von Dir machte mich stutzig, daher mein Verweis auf die Kompression und Abwahl der Module. Ist das jetzt immer noch so?
Sobald ich es wieder testen kann, bescheide ich :) ...

So, hab jetzt nochmal herumkompiliert und das Ergebnis ist folgendes:
- die neue 'initrd' ist [fast] gleich so gross wie die des Standardkernels (4.19)
- der neue Kernel (9.6 MB) ist aber fast doppelt so gross, wie der Standardkernel (5 MB)
... und ja, ich habe den neuen Kernel mittels 'make -j12 bindeb-pkg' ersellt :D ...

Ich denke, dass da noch viel/einiges Zeugs einkompiliert wird, was überhaupt nicht gebraucht wird. Also Optimierungspotential ist auf jeden Fall noch da, obwohl die Kiste jetzt wirklich flott bootet. Aber das war eigentlich nicht mein Ziel. Mein Ziel war es zu verstehen wie die Dinge zustande kommen. Doch ich lasse es mal gut sein, da ich das Gefühl habe, dass sich wohl manch User (nicht Du KP97) an meinen Fragen "stört" - vielleicht bin ich aber auch teils schwer von Begriff :D ... keine Ahnung.

Ich wollte jedenfalls der Vollständigkeitshalber posten, wie es nun mit dem neuen Kernel aussieht, da ich es ja versprochen hatte...

Schönen Sonntag noch und danke.

fischig
Beiträge: 3584
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von fischig » 06.12.2020 14:13:19

worker777 hat geschrieben:ich habe das Gefühl, dass sich wohl manch User (nicht Du KP97) an meinen Fragen "stört"
Das liegt möglicherweise daran, dass man deine Fragen nicht recht versteht. Dass die initrd nichts zu tun hat mit dem Kern-Bau sollte inzwischen klar sein. Wenn's dir also darum geht, dass die dir im laufenden Betrieb zu groß ist, dann müsstest du dich auf initramfs-tools, nicht auf „Keernelkonfiguration“ fokussieren.
Ich geh's mal so an: Wenn du das Kern-Bauen verstehen willst, dann ist der Ausgangspunkt immer die Datei .config im Stammverzeichnis deiner Kern-Quellen. Was da drin steht IST die Konfiguration deines Kerns, welche der Compiler anschließend und ohne dein weiteres Zutun in Maschinencode umwandelt. Es gibt zwar ein paar unterschiedliche Kommandos zum Anstoßen der Kompilation (zum Umsetzen dessen, was in .config steht, die aktuell sinnvollste Methode (bindeb-pkg) wurde bereits genannt), aber die bewirken im Wesentlichen alle das Gleiche, die Unterschiede betreffen Beiwerk/Komfortabilität.
Man könnte den Verständniswunsch jetzt in zweierlei Richtungen weiter verfolgen: Untersuchung des Programmcodes der Kompilationskommandos, was im Änderungsfall zu neuen Kompilationskommandos führen würde. Damit kenne ich mich nicht aus.
Die andere Richtung wäre: Untersuchung und Manipulation des .config-Inhaltes. Wenn du die Quellen heruntergeladen und in einem Verzeichnis (im folgenden: Quellverzeichnis) entpackt hast, dann existiert dort zunächst gar keine .config, heißt, du kannst keinen NEUEN Kern kompilieren (stimmt wohl nicht ganz, der Kompilator würde sich selbst eine .config erstellen, was aber auf eine reine Dublette des existierenden hinausliefe). Die nächste Möglichkeit wäre, eine Konfigurationsdatei des laufenden Kerns als .config ins Quellverzeichnis zu transferieren. Eine solche Konfigurationsdatei findest du in /boot. Wenn die Kern-Versionsangabe dieser Datei mit den beiden ersten Stellen der Kern-Quellenversion übereinstimmt (Beispiel Unter boot liegt /config-4.19.0-6-amd64, Quellverzeichnis ist 4.19.144), dann kannst du den Kern ohne jede Änderung der .config sofort kompilieren. Das wahrscheinlich nicht gewollte Ergebnis wäre aber wieder: Doublette des laufenden Kerns. Sinn machte dieses Vorgehen: Kern-Bau auf Basis eines existierenden Standard-Kerns im eher unwahrscheinlichen Fall, dass die Quellen dieses Kerns ein Bauteil zwar kennen, dieses aber nicht kompiliert ist (das müsste dann in der .config im Quellverzeichnis nachgeholt werden) oder aber, schon relevanter, dass ein in den Sourcen nicht vorhandener neuer Patch einkompiliert werden soll. Eine darüber hinausgehende Veränderung einer existierenden Kern-Konfiguration eines Standard-Kerns scheint mir angesichts der Tausenden von Einstellmöglichkeiten in der config eines Kerns ein sowohl fehlerträchtiges als auch endloses Unterfangen.
Entsprechen die beiden ersten Stellen der config unter boot nicht den beiden ersten Stellen im Kern-Verzeichnis - kommt nur vor, wenn der existierende Kern älter ist als der zu bauende neue(ob, bzw. wie man einen älteren Kern auf Basis der config eines neueren baut, weiß ich wieder mal nicht)) - dann kann man auch diese als .config ins Quellverzeichnis transferieren, muss sie dann aber via

Code: Alles auswählen

make oldconfig
an die neuen Quellen anpassen. (Info zu make oldconfig jetzt bitte selbst suchen.)

Bleibt zu fragen, wie man denn anders an eine Ausgangs-Config kommen kann. Mir fällt nur ein einziges Ziel ein: den Kern anzupassen, mehr oder weniger ausschließlich, an die gegebene Hardware. Ich kenne zwei Möglichkeiten: Im Quellvereichnis eine völlig neue .config via

Code: Alles auswählen

make localmodconfig
zu erstellen (habe ich selbst noch nicht ausprobiert, hier gibt's eine, wie ich finde, recht gute Anleitung: https://www.heise.de/ct/artikel/Linux-K ... 02386.html
oder aber via

Code: Alles auswählen

make defconfig
eine SEHR spartanische .config zu erstellen, deren damit gebauter Kern höchstwahrscheinlich auf der gegebenen Maschine (noch) nicht oder zumindest nicht zufriedenstellend laufen wird, die man aber - entprechende Kenntnis seiner Hardware vorausgesetzt - ausbauen kann. (KBDCALLS kennt was noch Spartanischeres, aber das ist mir im Augenblick entfallen. :wink: ) Womit wir bei der Manipultion der .config angelangt wären:

Diese erfolgt in der Regel via

Code: Alles auswählen

make menuconfig
(es gibt noch andere Kommandos, aber mir ist keiner untergekommen, der das nach meiner Einschätzung nicht eher als persönliches Spielzeug genutzt hätte).
Die Benutzung von menuconfig setzt die Installation von Debianlibncurses-dev voraus. Mit make menuconfig kann man jetzt nach Herzenslust Kern-Bestandteile ein- und auskompilieren (Was man nicht ändern kann, sagt einem das Kommando schon! Es gibt eine eingebaute Suchfunktion via

Code: Alles auswählen

/ --> [gesuchtes Modul]
)
Ich benutze die Quellen von kernel.org, nicht die von Debian. Ich setze in der Regel bei make oldconfig an. Inwieweit die Benutzung der ja doch im Bezug auf die Original-Quellen veränderten Debian-Quellen konfliktträchtig ist, weiß ich wieder nicht, mochte es aber bisher auch nicht riskieren.

Abschließend ein Wort zur initrd:
Ob man deren Größe verändern kann und wenn ja, ob man das tun sollte, weiß ich nicht. Du bist hier der erste, den ich erlebe, den das ventuell interessiert. Wie schon o.a., ich verstehe dein Problem nicht recht.
Man kann ohne initrd auskommen, aber dann muss man auf udev verzichten und devtmpfs als zu mounten im Kern einkompilieren (insgesamt drei Einstellungen). Auch letzteres ließe sich wieder umgehen, aber dann wünsche ich viel Spaß beim händischen Befüllen von /dev.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 06.12.2020 15:18:25

fischic hat geschrieben: Das liegt möglicherweise daran, dass man deine Fragen nicht recht versteht.
Gut möglich. Demfall ist ja eine Nachfrage eine echte Alternative [zum Schweigen, etc.], finde ich :) ...
fischic hat geschrieben: Dass die initrd nichts zu tun hat mit dem Kern-Bau sollte inzwischen klar sein. Wenn's dir also darum geht, dass die dir im laufenden Betrieb zu groß ist, dann müsstest du dich auf initramfs-tools, nicht auf „Keernelkonfiguration“ fokussieren.
Jupp, das wurde mir dann schon klar.
fischic hat geschrieben: Wenn's dir also darum geht, dass die dir im laufenden Betrieb zu groß ist, dann müsstest du dich auf initramfs-tools, nicht auf „Keernelkonfiguration“ fokussieren.
Auch inzwischen klar.

Vielen Dank für Deine ausführliche Erklärung - war mir [in etwa] auch klar gewesen.

fischic hat geschrieben: Abschließend ein Wort zur initrd:
Ob man deren Größe verändern kann und wenn ja, ob man das tun sollte, weiß ich nicht. Du bist hier der erste, den ich erlebe, den das ventuell interessiert. Wie schon o.a., ich verstehe dein Problem nicht recht.
Danke, das ist genau das was ich mein[t]e...

Ich habe/hatte kein "Problem" (im eigentlichen Sinne) mit der 'initrd'. Es war halt zuerst so, dass ich nach dem 'make -j12 bzImage modules' eine viel zu grosse initrd (abgesehen vom ebenfalls "übergrossen" Kernel) bekam und das kostete halt wirklich viel Bootzeit (ca. 30 Sekunden; im Vergleich zu jetzt sind es ca. 12 Sekunden).
Das war schon ein wenig "problematisch" (aus der Sicht des Luxus gesehen :D ).

Was ich dann einfach nur wissen wollte (Verständnisfrage) war, wie - bzw. anhand welcher Kriterien - die initramfs-tools entscheiden was in der initrd und was als ladbares Modul in '/lib/modules/...' landet...

Vielleicht zum besseren Verständnis zu dieser Frage noch folgendes:
Ich habe mir überlegt, warum eine initrd:
1. überhaupt gebraucht wird (das ist wohl ein Verhalten aus Reliktzeiten? Bzw. gebraucht dann wohl in Fällen wo man '/boot' auf ner separaten Partition will/braucht.)
2. überhaupt gepackt wird, da das Dekomprimieren wohl mehr Zeit in Anspruch nimmt als ein direktes Laden von - sagen wir mal - ca. 5 MB Daten/Treiber/etc. (und in Bezug auf den Kernel stelle ich die selbe Frage betr. der Komprimierung). Und hier könnte man dann wieder gedanklich weiter gehen und sagen, dass man auch keinen Dekomprimierungscode in den Kernel einkompilieren müsste, wenn man die initrd nicht vorher komprimiert hätte ......

Der Hintergrund zu diesen Fragen ist: Ich finde, dass das Booten von Linux durch diese zwei Punkte ziemlich ausgebremst (zeitlich gesehen) wird.

Ich wollte einfach nur verstehen, anhand von welchen Kriterien der Kernel + die initrd gebaut werden (also welche Treiber wo (Kernel oder initrd) und warum (gerade dort wo sie eben landen) landen.
Nun weiss ich ja, dass beim Kompilieren unterschiedliche Programme benutzt werden um den Kern und um die initrd zu bauen. Die Kriterien, was die initramfs-tools wo, wie und warum in die initrd reinprügeln, sind mir immer noch nicht bekannt, aber ich vermute mal, dass ich das wohl auch nicht wirklich verstehen werde, denn da scheint es wohl dann doch --> Richtung direkte Programmierung zu gehen, was ein Durchschnitts-User wohl nicht mehr verstehen würde...

Hoffe mal ich habe es jetzt deutlich genug geschildert - besser bekomme ich es wirklich nicht mehr hin :D ...

fischig
Beiträge: 3584
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von fischig » 06.12.2020 15:50:01

wie [...] die initramfs-tools entscheiden was in der initrd und was als ladbares Modul in '/lib/modules/...' landet...
Das ist aber wieder diese sinnlose Entgegensetzung von initrd und /lib/modules/. Die initrams-tools entscheiden, was in die initrd kommt. Punkt. :wink: Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 06.12.2020 16:07:39

fischic hat geschrieben: ↑ zum Beitrag ↑
06.12.2020 15:50:01
wie [...] die initramfs-tools entscheiden was in der initrd und was als ladbares Modul in '/lib/modules/...' landet...
Das ist aber wieder diese sinnlose Entgegensetzung von initrd und /lib/modules/. Die initrams-tools entscheiden, was in die initrd kommt.
Nun das ist [D]eine Meinung und ich gönne sie Dir auch, aber erklären tut es nicht viel...
fischic hat geschrieben: Punkt. :wink:
Nö, nicht für mich. Ich meine, wenn man schon versucht seine Frage - die, wie Du meinst, die User hier nicht verstehen würden - zu präzisieren und dann ein "das ist so und Punkt" kommt, frage ich mich jetzt schon ein wenig, wo man in der Linuxwelt angekommen ist.
Ich dachte immer, dass man gerade in der Linux/*nix-Welt willkommen wäre, wenn man sich für das Betriebssystem und seine Funktionsweise - auch als ein Otto-Normal-User - interessieren würde. Aber mir scheint es, dass es manchen Usern zu "langweilig" geworden ist, entweder immer die selben Fragen zu beantworten oder aber die etwas komplizierteren hinter einem "das ist so und Punkt" quasi zu ersticken ..... so kommt es mir wirklich ein wenig vor ...
fischic hat geschrieben: Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.
Ja, Dich vielleicht nicht, aber mich schon. Das ist ja auch okay, aber sorry, demfall wäre keine Antwort wohl besser als so eine.
Will Dir wirklich nicht ans Bein pinkeln, aber ich finde, dass das kein Informationsaustausch ist, sondern "eins mit dem Knüppel drüber - und Punkt"...
Warum ich mir dann die Mühe mache und versuche schier endloss etwas zu erklären, wo dann einfach ein abrupter "Break" kommt...?

fischig
Beiträge: 3584
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von fischig » 06.12.2020 16:37:01

Nun das ist [D]eine Meinung
Das ist keine Meinung, sondern eine Tatsachenbehauptung. Die kann man akzeptieren oder mit einer anderen Tatsachenbehauptung widerlegen. Mit subjektiver „Meinung“ hat das nichts zu tun. Ich weiß nicht wie ich mit jemandem umgehen soll, der auf die bei wolkenlosem Himmel mittags um 12 Uhr auf dem Frankfurter Römer getätigte Aussage: „Die Sonne scheint.“ antwortet: „Nun ja, das ist deine Meinung.“
worker777 hat geschrieben:
fischic hat geschrieben:Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.
Ja, Dich vielleicht nicht, aber mich schon.
Du hast das „die“ überlesen. Es interessiert die initramfs-tools nicht. Und die - mal als gegeben akzeptiert - wiederum interessiert weder was mich noch was dich interessiert oder nicht interessiert.
Zuletzt geändert von fischig am 06.12.2020 16:53:35, insgesamt 1-mal geändert.

worker777
Beiträge: 103
Registriert: 14.04.2015 07:59:26

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von worker777 » 06.12.2020 16:50:31

fischic hat geschrieben: ↑ zum Beitrag ↑
06.12.2020 16:37:01
worker777 hat geschrieben:
fischic hat geschrieben:Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.
Ja, Dich vielleicht nicht, aber mich schon.
Du hast das „die“ überlesen. Es interessiert die initramfs-tools nicht. Und die - mal als gegeben akzeptiert - wiederum interessiert weder was mich noch was dich interessiert oder nicht interessiert.
Stimmt. Das "die" hab ich tatsächlich überlesen - sorry.

KP97
Beiträge: 3395
Registriert: 01.02.2013 15:07:36

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von KP97 » 06.12.2020 19:04:09

Vorsicht mit "make oldconfig". Wenn man die manpage liest, hört es sich erstmal einleuchtend an.
Aber dieser Parameter setzt voraus, daß Du alle Deine Hardware einschaltest bzw. ansteckst, damit die benötigten Module auch erkannt werden.
Ich habe z.B. Wlan und Kabel, lasse das Netzwerk über systemd verwalten. Ich lasse beides aber nicht parallel laufen, sondern benutze nur die Kabelverbindung.
Als ich diesen Parameter mal eingesetzt habe, hatte ich nicht mehr ans Wlan gedacht, und der fertige Kernel erkannte daher auch mein Wlan Modul nicht mehr.
Außerdem hat es die config nur minimal verkleinert, macht also nicht viel Sinn, im Gegenteil.

Du kannst die Größe der initrd.img nachträglich nur über die initramfs.conf beeinflussen. Wie das geht hatte ich oben schon beschrieben.
Sonst geht das nur über die menuconfig, hast Du ja jetzt herausgefunden.

Man kann z.B. auch nachträglich in der /lib/modules/kernel..../ noch Module entfernen, wenn man diese löscht und anschließend ein "depmod -a" ausführt.
Das ist der einzige, mir bekannte Grund, um das Verzeichnis aufzurufen. Natürlich wird dieses Verzeichnis benötigt, man sollte also schon genau wissen, was man macht.

Die config auf die eigene Hardware anzupassen, wenn man die config vom Standardkernel als Vorlage nimmt, benötigt viel, viel Zeit, Wissen und Probiererei.
Wenn man es dann aber mal hat, verwendet man diese ja immer wieder, solange man die Hardware einsetzt.
Der Kernel ist dann aber auch nur für dieses System einzusetzen. Wenn man universeller sein will, kann man halt nicht so rigoros vorgehen. Dann muß man auch Module berücksichtigen, die man momentan nicht hat, aber evtl. später mal. Dann wird der Kernel aber auch wieder umfangreicher.
So ist es halt im Leben, man kann nicht alles haben...;-)

Der obige Befehl muß make localmodconfig lauten.
Freud'scher Verschreiber
Zuletzt geändert von KP97 am 06.12.2020 19:12:49, insgesamt 1-mal geändert.

Benutzeravatar
towo
Beiträge: 4400
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von towo » 06.12.2020 19:07:18

Vorsicht mit "make oldconfig". Wenn man die manpage liest, hört es sich erstmal einleuchtend an.
Aber dieser Parameter setzt voraus, daß Du alle Deine Hardware einschaltest bzw. ansteckst, damit die benötigten Module auch erkannt werden.
Das gilt wohl eher für make localmodconfig oder make localyesconfig!

make oldconfig adaptiert einfach die config des laufenden Kernel in die benutzten Sourcen.

KP97
Beiträge: 3395
Registriert: 01.02.2013 15:07:36

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von KP97 » 06.12.2020 19:09:25

Ja, stimmt natürlich, ich habe an localmodconfig gedacht und oldconfig geschrieben.

fischig
Beiträge: 3584
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von fischig » 06.12.2020 19:20:48

make oldconfig adaptiert einfach die config des laufenden Kernel in die benutzten Sourcen.
So wie ich das Procedere verstehe, passt make oldconfig die aktuell verwendete .config an die neuen Quellen an. Mit dem laufenden Kern muss das nichts zu tun haben.

Benutzeravatar
towo
Beiträge: 4400
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage

Beitrag von towo » 06.12.2020 19:48:44

Wenn Du keine .config in die Sourcen kopierst, zieht make oldconfig die config des laufenden Kernels als Grundlage heran. Anderen Falls wird natürlich eine .config benutzt, wenn eine da ist.

Antworten