Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Hallo zusammen,
ich bin jetzt schon einige Tage am Herumprobieren, wie ich meinen Kernel (5.9.11) am optimaltesten bauen könnte (als Greenhorn in diesem Bereich).
Bisher scheitere ich daran, dass
1. der neue Kernel in etwa die Grösse des "Standard-Kernels" (seit der Installation (4.19.xx)) hat
2. die initrd in etwa die Grösse der "Standard-initrd" hat
(daraus resultiert auch ein wesentlich längerer Bootvorgang...)
Ich habe die config-Datei des "Standard-Kernels" zum Bau des neuen Kernels genommen und dabei eigentlich "nur leichte" Veränderungen vorgenommen.
Diese wäre z.B.:
- Als Kompression LZ4
- Bluetooth -> alles in den Kernel rein, ansonsten als Modul ladbar
- Weiteres wie z.B. USB, etc. überwiegend als ladbare Module gekennzeichnet
Nun habe ich es letztendlich (wohl nach dem ca. 10. Kompilieren ) geschafft, 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.
Meine Frage nun ist die folgende:
Kann ich es irgendwie beim kompilieren/in der Config steuern, was in der initrd und was in /lib/modules/$kernel_version landet?
Oder wie "unterscheidet" das 'make' wo (initrd bzw /lib/modules/$kernel_version) welche Module landen?
Und noch eine Zusatzfrage: Ist es möglich den Kernel und/oder die initrd unkomprimiert zu bauen?
Für Aufklärung wäre ich dankbar, denn ich finde im Netz solche Infos nicht.
Grüsse
worker
ich bin jetzt schon einige Tage am Herumprobieren, wie ich meinen Kernel (5.9.11) am optimaltesten bauen könnte (als Greenhorn in diesem Bereich).
Bisher scheitere ich daran, dass
1. der neue Kernel in etwa die Grösse des "Standard-Kernels" (seit der Installation (4.19.xx)) hat
2. die initrd in etwa die Grösse der "Standard-initrd" hat
(daraus resultiert auch ein wesentlich längerer Bootvorgang...)
Ich habe die config-Datei des "Standard-Kernels" zum Bau des neuen Kernels genommen und dabei eigentlich "nur leichte" Veränderungen vorgenommen.
Diese wäre z.B.:
- Als Kompression LZ4
- Bluetooth -> alles in den Kernel rein, ansonsten als Modul ladbar
- Weiteres wie z.B. USB, etc. überwiegend als ladbare Module gekennzeichnet
Nun habe ich es letztendlich (wohl nach dem ca. 10. Kompilieren ) geschafft, 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.
Meine Frage nun ist die folgende:
Kann ich es irgendwie beim kompilieren/in der Config steuern, was in der initrd und was in /lib/modules/$kernel_version landet?
Oder wie "unterscheidet" das 'make' wo (initrd bzw /lib/modules/$kernel_version) welche Module landen?
Und noch eine Zusatzfrage: Ist es möglich den Kernel und/oder die initrd unkomprimiert zu bauen?
Für Aufklärung wäre ich dankbar, denn ich finde im Netz solche Infos nicht.
Grüsse
worker
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Die initrd selbst kannst Du beim eigenen Kernel nicht "befüllen", Du kannst nur wählen, ob Dein Kernel eine haben soll oder nicht.
Einstellungen für die initrd kannst Du in /etc/initramfs-tools vornehmen, das hält sich aber in Grenzen.
Wenn Du keine initrd nutzen willst, mußt Du alle benötigten Module fest in den Kernel aufnehmen. Dazu mußt Du aber genau wissen, welche das sind. Das empfiehlt sich also nicht.
Wenn Du keine Änderungen in der config vornimmst, wird der Kernel natürlich auch so groß wie die Vorlage. Dann kann man sich den Vorgang aber auch schenken und den Standardkernel nehmen, der tuts ja auch. Du könntest die debug-Funktionen herausnehmen, das verkleinert den Kernel auch.
Apropo debug...wie lautet denn Dein Kommando zum Kernelbauen? Hoffentlich doch wohlund nicht irgendwas anderes. Das würde evtl. die Größen erklären, wenn da noch die Funktionen für's debuggen enthalten sind. Diese Funktionen sind nur für Kernelentwickler gedacht, dazu gehörst Du aber nicht.
Im vorgenannten Kommando steht -j4 für vier Kerne, wenn Du mehr hast, den Wert entsprechend ändern.
Einstellungen für die initrd kannst Du in /etc/initramfs-tools vornehmen, das hält sich aber in Grenzen.
Wenn Du keine initrd nutzen willst, mußt Du alle benötigten Module fest in den Kernel aufnehmen. Dazu mußt Du aber genau wissen, welche das sind. Das empfiehlt sich also nicht.
Wenn Du keine Änderungen in der config vornimmst, wird der Kernel natürlich auch so groß wie die Vorlage. Dann kann man sich den Vorgang aber auch schenken und den Standardkernel nehmen, der tuts ja auch. Du könntest die debug-Funktionen herausnehmen, das verkleinert den Kernel auch.
Apropo debug...wie lautet denn Dein Kommando zum Kernelbauen? Hoffentlich doch wohl
Code: Alles auswählen
make -j4 bindeb-pkg
Im vorgenannten Kommando steht -j4 für vier Kerne, wenn Du mehr hast, den Wert entsprechend ändern.
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Da irrst du, KP97, leider.Wenn Du keine initrd nutzen willst, mußt Du alle benötigten Module fest in den Kernel aufnehmen.
Nur fällt ohne initrd auch udev weg, aber das lässt sich auch über einen dummy und /etc/modules lösen.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Ach schau an, meine früheren Kernel waren immer ohne initrd (2.6, 3.xx, 4.xx), da hatte ich die Module für meine Hardware fest einkompiliert.
Irgendwann funktionierte das nicht mehr, mit udev (systemd) hatte ich das aber nicht in Verbindung gebracht. Habe ab diesem Zeitpunkt mit initrd kompiliert, dann lief es wieder.
Irgendwann funktionierte das nicht mehr, mit udev (systemd) hatte ich das aber nicht in Verbindung gebracht. Habe ab diesem Zeitpunkt mit initrd kompiliert, dann lief es wieder.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Hallo KP97,
vielen Dank für Deine Antwort.
Aber eben, aus meiner Sicht ist es nicht wirklich nachvollziehbar, wenn man z.B. alles aus Bluetooth als Modul haben will/es mal braucht, und es wird vieles was man in der Konfig angibt in die initrd gequetscht - das verlängert ja dann wieder voll unnötig die Bootzeit...?
Naja, ich hab das so "gelernt", resp. erg00glet ...
Übrigens, wie ich eben noch gelesen habe, wird - glaubs ab Kernel 2.x - die initrd nicht mehr benutzt, sondern initramfs. Wieso lautet die entspr. Datei immer noch "initrd"?
Nochmals, vielen Dank für Deine ausführliche Erklärungen!
vielen Dank für Deine Antwort.
Das finde ich doch ziemlich doof - klar ich kenne die Mechanismen/Funktionsweise nicht im Detail, aber genau das würde mich interessieren ..... nach welchen Kriterien "befüllt" denn 'make' die initrd? Mal abgesehen davon, dass ich heute gelesen habe, dass man die initrd auch dekomprimieren und bearbeiten kann/könnte, finde ich das einen ziemlichen Umweg ..... weshalb gibt es denn keine Möglichkeiten dem 'make' mitzuteilen was in die initrd rein soll und was nicht?KP97 hat geschrieben:29.11.2020 17:56:21Die initrd selbst kannst Du beim eigenen Kernel nicht "befüllen", Du kannst nur wählen, ob Dein Kernel eine haben soll oder nicht.
Ja, das habe ich auch schon getan - da wurde die Grösse des Kernel schon kleiner...KP97 hat geschrieben:29.11.2020 17:56:21Du könntest die debug-Funktionen herausnehmen, das verkleinert den Kernel auch.
Aber eben, aus meiner Sicht ist es nicht wirklich nachvollziehbar, wenn man z.B. alles aus Bluetooth als Modul haben will/es mal braucht, und es wird vieles was man in der Konfig angibt in die initrd gequetscht - das verlängert ja dann wieder voll unnötig die Bootzeit...?
Doch was anderes --> make -j12 bzImage modulesKP97 hat geschrieben:29.11.2020 17:56:21Apropo debug...wie lautet denn Dein Kommando zum Kernelbauen? Hoffentlich doch wohlund nicht irgendwas anderes.Code: Alles auswählen
make -j4 bindeb-pkg
Naja, ich hab das so "gelernt", resp. erg00glet ...
Aber die Debuggs kann man doch in der Konfig abwählen? So hab ich es ja auch gemacht. Oder handelt es sich hierbei um "andere" DebugInfos?KP97 hat geschrieben:29.11.2020 17:56:21Das würde evtl. die Größen erklären, wenn da noch die Funktionen für's debuggen enthalten sind.
Übrigens, wie ich eben noch gelesen habe, wird - glaubs ab Kernel 2.x - die initrd nicht mehr benutzt, sondern initramfs. Wieso lautet die entspr. Datei immer noch "initrd"?
Nochmals, vielen Dank für Deine ausführliche Erklärungen!
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Die initrd wird sehr wohl noch benötigt, da diese beim booten weitere Aufgaben erfüllt. Lies mal man initrd.
Zum debug gibt es in den einzelnen Bereichen der config eigene Debugfunktionen, es gibt aber auch den globalen Bereich "Kernel Hacking".
Dieses "bzImage" ist veraltet, nutze lieber bindeb-pkg. Damit werden einzelne Pakete erstellt, die wahlweise mit dpkg -i installiert werden können und nicht am Paketmanager vorbei gehen. Ich installiere immer nur das linux-image, die linux-headers schiebe ich auf meine Backup HDD, falls man die Headers mal braucht, den Rest lösche ich weg.
Zu den Modulen für z.B. bluetooth: Es werden doch immer nur die Module geladen, die auch Deine Hardware erkennen. Alles andere wird gar nicht angesprochen, daher verursachen diese
Module auch keinen zusätzlich Platzverbrauch. Anders ist es, wenn die Auswahl nicht als Modul sondern fest im Kernel erfolgt. Dann werden diese Module auch geladen, egal ob die Hardware vorhanden ist oder nicht. Braucht natürlich auch wieder zusätzlichen Platz.
Du siehst schon, Kernelbacken ist nicht so simpel...man muß gut überlegen, was man macht...
Ach ja, noch was:
Wähle in der /etc/initramfs-tools/initramfs.conf
MODULES=dep
und
COMPRESS=xz
und anschließend eine neue initrd bauen. Das verkleinert die Datei auch.
Zum debug gibt es in den einzelnen Bereichen der config eigene Debugfunktionen, es gibt aber auch den globalen Bereich "Kernel Hacking".
Dieses "bzImage" ist veraltet, nutze lieber bindeb-pkg. Damit werden einzelne Pakete erstellt, die wahlweise mit dpkg -i installiert werden können und nicht am Paketmanager vorbei gehen. Ich installiere immer nur das linux-image, die linux-headers schiebe ich auf meine Backup HDD, falls man die Headers mal braucht, den Rest lösche ich weg.
Zu den Modulen für z.B. bluetooth: Es werden doch immer nur die Module geladen, die auch Deine Hardware erkennen. Alles andere wird gar nicht angesprochen, daher verursachen diese
Module auch keinen zusätzlich Platzverbrauch. Anders ist es, wenn die Auswahl nicht als Modul sondern fest im Kernel erfolgt. Dann werden diese Module auch geladen, egal ob die Hardware vorhanden ist oder nicht. Braucht natürlich auch wieder zusätzlichen Platz.
Du siehst schon, Kernelbacken ist nicht so simpel...man muß gut überlegen, was man macht...
Ach ja, noch was:
Wähle in der /etc/initramfs-tools/initramfs.conf
MODULES=dep
und
COMPRESS=xz
und anschließend eine neue initrd bauen. Das verkleinert die Datei auch.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Und eben das ist mir etwas schleierhaft...KP97 hat geschrieben:29.11.2020 19:09:56Zu den Modulen für z.B. bluetooth: Es werden doch immer nur die Module geladen, die auch Deine Hardware erkennen. Alles andere wird gar nicht angesprochen, daher verursachen diese Module auch keinen zusätzlich Platzverbrauch.
Ich habe bei den letzten Kompilier-Versuchen nur wenig in den Kernel fest einkompiliert und viel als Module. Die initrd wurde trotzdem um ein vielfaches grösser als das "Original", der Kernel nur minimal grösser.
Klar, es werden nur die Module vom Kernel geladen, die zur Hardware passen, aber kompiliert wird alles was entweder als fest-im-Kernel, oder als Modul angegeben wurde:
1. und anhand von welchen Kriterien werden also offensichtlich auch Module - vom make - in die initrd übernommen?
2. und anhand von welchen Kriterien werden Module - vom make - ins '/lib/modules/$kernel_version' geschoben?
Wenn alle Module in /lib/modules/$kernel_version landen würden, könnte ich das verstehen, aber anhand meiner Versuche scheint das eben nicht so zu sein. Also gibt es da offensichtlich Kriterien dafür und wenn ja, kann ich diese irgendwie (ausser in /etc/initramfs-tools/initramfs.conf) beeinflussen?
Genau. Und dieser Platz scheint - zumindest teilweise - in der initrd zu sein und das bringt mich wieder zu der Frage nach dem "Auswahlkriterium" ...KP97 hat geschrieben:29.11.2020 19:09:56Anders ist es, wenn die Auswahl nicht als Modul sondern fest im Kernel erfolgt. Dann werden diese Module auch geladen, egal ob die Hardware vorhanden ist oder nicht. Braucht natürlich auch wieder zusätzlichen Platz.
Stimmt. Und leider ist es schwierig diesbezüglich gezielte Infos über's Netz zu finden - geschweige denn zu wissen welche Infos bereits veraltet und welche up-to-date sind...KP97 hat geschrieben:29.11.2020 19:09:56Du siehst schon, Kernelbacken ist nicht so simpel...man muß gut überlegen, was man macht...
Jupp, danke.KP97 hat geschrieben:29.11.2020 19:09:56Ach ja, noch was:
Wähle in der /etc/initramfs-tools/initramfs.conf
MODULES=dep
und
COMPRESS=xz
und anschließend eine neue initrd bauen. Das verkleinert die Datei auch.
So wie es scheint ist bei 'COMPRESS' aber die Wahl 'lz4' zu nehmen die im Moment beste. Zumindest laut dem, was in Netz so geschrieben/behauptet wird...
- towo
- Beiträge: 4422
- Registriert: 27.02.2007 19:49:44
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Als kleines Stichwort werfe ich mal ein
ein.
Code: Alles auswählen
make localmodconfig
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Ja, danke Dir. Das ist schön und nett (und war mir bekannt), aber mir geht es:towo hat geschrieben:29.11.2020 20:27:56Als kleines Stichwort werfe ich mal einein.Code: Alles auswählen
make localmodconfig
1. um das Verständnis warum offensichtlich Module mal da und mal dort landen, und
2. darum, dass ich möglichst viel (natürlich nur begrenzte Auswahl) als Module in '/lib/modules/$kernel_version' liegen habe, wenn ich sie dann mal brauche...
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Du schreibst:
Du kannst aber alles komplett abwählen, was Du als Hardware gar nicht hast bzw. brauchst, als da wären Apple-Zeug, AMD-Zeug wenn Du Intel Hardware hast - oder umgekehrt -, Laptop-Hardware und Treiber, die Du nicht hast usw. Es gibt da ja eine ganze Menge an Hardware oder Modulen. Das ist zeitaufwändig, weil man alles durchgehen muß, letztlich schrumpft der Kernel aber auch beträchtlich zusammen. Die jeweiligen Erklärungen, aufzurufen mit dem Fragezeichen sind sehr hilfreich.
Der Standardkernel muß natürlich alles abdecken, daher ist er auch umfangreicher. Warum das bei Dir umgekehrt ist, kann ich mir nicht erklären.
Meine Hardware ist ein Intel NUC i3 mit diesen Größen:
config-5.9.11 = 149,0 KB
initrd.img = 5,6 MB
System.map = 4,2 MB
Kernel = 6,4 MB
Bei lz4 wird die initrd fast doppelt so groß, probiere es aus. Du weißt aber, daß eine hohe Kompression das Booten etwas verzögern kann? Aber das fällt bei den heutigen CPU's nicht ins Gewicht, ich merke das jedenfalls nicht.
Denke auch an den Kompilierbefehl bindeb-pkg...
Ja, so ist es, und ich habe mich etwas mißverständlich ausgedrückt.Klar, es werden nur die Module vom Kernel geladen, die zur Hardware passen, aber kompiliert wird alles was entweder als fest-im-Kernel, oder als Modul angegeben wurde:
Du kannst aber alles komplett abwählen, was Du als Hardware gar nicht hast bzw. brauchst, als da wären Apple-Zeug, AMD-Zeug wenn Du Intel Hardware hast - oder umgekehrt -, Laptop-Hardware und Treiber, die Du nicht hast usw. Es gibt da ja eine ganze Menge an Hardware oder Modulen. Das ist zeitaufwändig, weil man alles durchgehen muß, letztlich schrumpft der Kernel aber auch beträchtlich zusammen. Die jeweiligen Erklärungen, aufzurufen mit dem Fragezeichen sind sehr hilfreich.
Der Standardkernel muß natürlich alles abdecken, daher ist er auch umfangreicher. Warum das bei Dir umgekehrt ist, kann ich mir nicht erklären.
Meine Hardware ist ein Intel NUC i3 mit diesen Größen:
config-5.9.11 = 149,0 KB
initrd.img = 5,6 MB
System.map = 4,2 MB
Kernel = 6,4 MB
Nein, das ist nicht so. xz ist das beste Format mit dem besten Wert.So wie es scheint ist bei 'COMPRESS' aber die Wahl 'lz4' zu nehmen die im Moment beste.
Bei lz4 wird die initrd fast doppelt so groß, probiere es aus. Du weißt aber, daß eine hohe Kompression das Booten etwas verzögern kann? Aber das fällt bei den heutigen CPU's nicht ins Gewicht, ich merke das jedenfalls nicht.
Denke auch an den Kompilierbefehl bindeb-pkg...
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Genau so habe ich das alles auch mehrmals(!) *schwitz * gemacht. Das ist wirklich sehr zeitaufwendig...!KP97 hat geschrieben:30.11.2020 13:33:44Du kannst aber alles komplett abwählen, was Du als Hardware gar nicht hast bzw. brauchst, als da wären Apple-Zeug, AMD-Zeug wenn Du Intel Hardware hast - oder umgekehrt -, Laptop-Hardware und Treiber, die Du nicht hast usw. Es gibt da ja eine ganze Menge an Hardware oder Modulen. Das ist zeitaufwändig, weil man alles durchgehen muß, letztlich schrumpft der Kernel aber auch beträchtlich zusammen. Die jeweiligen Erklärungen, aufzurufen mit dem Fragezeichen sind sehr hilfreich.
Aber gemacht habe ich es...
Trotzdem bleibt meine Frage leider unbeantwortet: Anhand welcher Kriterien ausgewählte Module direkt in der initrd, oder im Kernel landen (falls überhaupt meine Annahme, dass manche Module im Kernel landen, richtig ist)?
Ich denke nicht, dass es bei mir umgekehrt ist(?). Der Standardkernel beinhalet ja Zeugs wie das AMD-Zeugt, etc. ...KP97 hat geschrieben:30.11.2020 13:33:44Der Standardkernel muß natürlich alles abdecken, daher ist er auch umfangreicher. Warum das bei Dir umgekehrt ist, kann ich mir nicht erklären.
Jupp, das ist so. Ich denke, da muss man abwägen, anhand von dem welche Hardware resp. CPU man hat.KP97 hat geschrieben:30.11.2020 13:33:44Nein, das ist nicht so. xz ist das beste Format mit dem besten Wert.worker777 hat geschrieben:So wie es scheint ist bei 'COMPRESS' aber die Wahl 'lz4' zu nehmen die im Moment beste.
Bei lz4 wird die initrd fast doppelt so groß, probiere es aus. Du weißt aber, daß eine hohe Kompression das Booten etwas verzögern kann? Aber das fällt bei den heutigen CPU's nicht ins Gewicht, ich merke das jedenfalls nicht.
So wie ich das gelesen habe ist eben LZ4 am schnellsten beim dekomprimieren, drum habe ich es genommen, da ich mein OS auf ner SSD habe und die CPU eine i7-8700K (6 Kerne) ist. Also ist die Grösse wohl nicht so entscheidend (da SSD) und die Dekomprimierung zusammen mit meiner CPU dürfe wohl am flottesten sein(?)...
Wie auch immer - mir ging es nicht direkt um Komprimierungstuning, sondern darum, dass möglichst alle in der Konfig angegebene Module im '/lib/modules/$kernel_version' landen.
Sir, ja Sir!
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Zu den Auswahlkriterien bin ich überfragt. Ich vermute, daß z.B. Module, die direkt der Kernel steuert, auch im Kernel bzw. der initrd verbleiben, während sich z.B. Firmware "extern" in den /lib/modules wiederfindet. Andererseits stehen in den Textdokumenten alle möglichen Module, geordnet nach Bereichen. Aber wie gesagt, alles reine Vermutung von mir.
Vielleicht kann @towo was dazu sagen, er macht ja die Kernel für Siduction und hat da sicher mehr Einblick.
Vielleicht kann @towo was dazu sagen, er macht ja die Kernel für Siduction und hat da sicher mehr Einblick.
Diese Aussage von Dir machte mich stutzig, daher mein Verweis auf die Kompression und Abwahl der Module. Ist das jetzt immer noch so?...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...
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Okay, verstehe. Ja, vermute ich auch, aber eben die initrd-Grösse ...KP97 hat geschrieben:30.11.2020 16:10:13Zu den Auswahlkriterien bin ich überfragt. Ich vermute, daß z.B. Module, die direkt der Kernel steuert, auch im Kernel bzw. der initrd verbleiben, während sich z.B. Firmware "extern" in den /lib/modules wiederfindet. Andererseits stehen in den Textdokumenten alle möglichen Module, geordnet nach Bereichen. Aber wie gesagt, alles reine Vermutung von mir.
Trotzdem vielen Dank für Deine Hilfe
Sobald ich es wieder testen kann, bescheide ich ...KP97 hat geschrieben:30.11.2020 16:10:13Diese Aussage von Dir machte mich stutzig, daher mein Verweis auf die Kompression und Abwahl der Module. Ist das jetzt immer noch so?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...
- towo
- Beiträge: 4422
- Registriert: 27.02.2007 19:49:44
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Alles, was als Modul konfiguriert wird, landet in /lib/modules/$(uname -r)/kernel.
Was in der Ramdisk landet, wird nicht von Kernel bestimmt, sondern von den initramfs-tools.
Was in der Ramdisk landet, wird nicht von Kernel bestimmt, sondern von den initramfs-tools.
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Dann lass sie doch weg. Aber du hast bisher, soweit ich das verfolge, noch nirgends erklärt, was du eigentlich erreichen willst mit deinem selbstgebauten Kern. Dein Focus initrd vs. lib/modules/... ist wenig sinnvoll, siehe towo.worker777 hat geschrieben:Ja, vermute ich auch, aber eben die initrd-Grösse ...
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Okay ... *grübel*towo hat geschrieben:30.11.2020 16:58:58Alles, was als Modul konfiguriert wird, landet in /lib/modules/$(uname -r)/kernel.
Dann frage ich mich, wieso meine initrd immer so gross wird...muss das nochmal checken...
Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?towo hat geschrieben:30.11.2020 16:58:58Was in der Ramdisk landet, wird nicht von Kernel bestimmt, sondern von den initramfs-tools.
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)?
Ja, darauf arbeite ich - letztendlich - hin, aber ein Verständnis-Schritt nach dem anderen ...fischic hat geschrieben: Dann lass sie doch weg.
Najafischic hat geschrieben: Aber du hast bisher, soweit ich das verfolge, noch nirgends erklärt, was du eigentlich erreichen willst mit deinem selbstgebauten Kern.
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) ...
Verstehe ich nicht...fischic hat geschrieben: Dein Focus initrd vs. lib/modules/... ist wenig sinnvoll, siehe towo.
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...?
- towo
- Beiträge: 4422
- Registriert: 27.02.2007 19:49:44
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Was hast Du immer mit make?Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?
Wärend des Kernel-Baus wird keine initrd erzeugt. Das passiert erst beim installieren des Kernels.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Na, 'make install' installiert doch den Kernel, bzw. leitet die Installation ein..?towo hat geschrieben:30.11.2020 18:05:04Was hast Du immer mit make?Also ruft 'make' die 'initramfs-tools' auf und 'initramfs-tools' bestimmt was in der RamDisk landet..?
Wärend des Kernel-Baus wird keine initrd erzeugt. Das passiert erst beim installieren des Kernels.
- towo
- Beiträge: 4422
- Registriert: 27.02.2007 19:49:44
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
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.
Nochmal, diese wird durch einen hook von dpkg beim Installieren des Kernel-Paketes mittels der initramfs-tools erzeugt.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
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:30.11.2020 18:16:12Wenn 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.
Aha(!), okay.towo hat geschrieben:30.11.2020 18:16:12Nochmal, diese wird durch einen hook von dpkg beim Installieren des Kernel-Paketes mittels der initramfs-tools erzeugt.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
worker777 hat geschrieben:Sobald ich es wieder testen kann, bescheide ich ...KP97 hat geschrieben:30.11.2020 16:10:13Diese Aussage von Dir machte mich stutzig, daher mein Verweis auf die Kompression und Abwahl der Module. Ist das jetzt immer noch so?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...
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 ...
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 ... 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.
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
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.worker777 hat geschrieben:ich habe das Gefühl, dass sich wohl manch User (nicht Du KP97) an meinen Fragen "stört"
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
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
oder aber via
Code: Alles auswählen
make defconfig
Diese erfolgt in der Regel via
Code: Alles auswählen
make menuconfig
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
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.
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Gut möglich. Demfall ist ja eine Nachfrage eine echte Alternative [zum Schweigen, etc.], finde ich ...fischic hat geschrieben: Das liegt möglicherweise daran, dass man deine Fragen nicht recht versteht.
Jupp, das wurde mir dann schon klar.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.
Auch inzwischen 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.
Vielen Dank für Deine ausführliche Erklärung - war mir [in etwa] auch klar gewesen.
Danke, das ist genau das was ich mein[t]e...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.
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 ).
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 ...
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Das ist aber wieder diese sinnlose Entgegensetzung von initrd und /lib/modules/. Die initrams-tools entscheiden, was in die initrd kommt. Punkt. Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.wie [...] die initramfs-tools entscheiden was in der initrd und was als ladbares Modul in '/lib/modules/...' landet...
Re: Kernelkonfiguration, initrd und /lib/modules - Verständnisfrage
Nun das ist [D]eine Meinung und ich gönne sie Dir auch, aber erklären tut es nicht viel...fischic hat geschrieben:06.12.2020 15:50:01Das ist aber wieder diese sinnlose Entgegensetzung von initrd und /lib/modules/. Die initrams-tools entscheiden, was in die initrd kommt.wie [...] die initramfs-tools entscheiden was in der initrd und was als ladbares Modul in '/lib/modules/...' landet...
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.fischic hat geschrieben: Punkt.
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 ...
Ja, Dich vielleicht nicht, aber mich schon. Das ist ja auch okay, aber sorry, demfall wäre keine Antwort wohl besser als so eine.fischic hat geschrieben: Ob das nun fest im Kern installiert ist oder unter /lib/modules/ liegt, interessiert die dabei nicht.
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...?