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
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
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
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.
) Womit wir bei der Manipultion der .config angelangt wären:
Diese erfolgt in der Regel via
(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
libncurses-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
)
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.