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

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

Beitrag von worker777 » 29.11.2020 13:41:29

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 :roll: ) 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

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

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

Beitrag von KP97 » 29.11.2020 17:56:21

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 wohl

Code: Alles auswählen

make -j4 bindeb-pkg
und 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.

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 » 29.11.2020 18:14:21

Wenn Du keine initrd nutzen willst, mußt Du alle benötigten Module fest in den Kernel aufnehmen.
Da irrst du, KP97, leider.
Nur fällt ohne initrd auch udev weg, aber das lässt sich auch über einen dummy und /etc/modules lösen.

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

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

Beitrag von KP97 » 29.11.2020 18:33:14

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.

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

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

Beitrag von worker777 » 29.11.2020 18:33:14

Hallo KP97,

vielen Dank für Deine Antwort.
KP97 hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 17:56:21
Die initrd selbst kannst Du beim eigenen Kernel nicht "befüllen", Du kannst nur wählen, ob Dein Kernel eine haben soll oder nicht.
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: ↑ zum Beitrag ↑
29.11.2020 17:56:21
Du könntest die debug-Funktionen herausnehmen, das verkleinert den Kernel auch.
Ja, das habe ich auch schon getan - da wurde die Grösse des Kernel schon kleiner...
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...?
KP97 hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 17:56:21
Apropo debug...wie lautet denn Dein Kommando zum Kernelbauen? Hoffentlich doch wohl

Code: Alles auswählen

make -j4 bindeb-pkg
und nicht irgendwas anderes.
Doch was anderes :D --> make -j12 bzImage modules
Naja, ich hab das so "gelernt", resp. erg00glet :D ...
KP97 hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 17:56:21
Das würde evtl. die Größen erklären, wenn da noch die Funktionen für's debuggen enthalten sind.
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?

Ü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! :THX:

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

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

Beitrag von KP97 » 29.11.2020 19:09:56

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.

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

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

Beitrag von worker777 » 29.11.2020 20:25:32

KP97 hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 19:09:56
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.
Und eben das ist mir etwas schleierhaft...
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?
KP97 hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 19:09:56
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.
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: ↑ zum Beitrag ↑
29.11.2020 19:09:56
Du siehst schon, Kernelbacken ist nicht so simpel...man muß gut überlegen, was man macht...
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: ↑ zum Beitrag ↑
29.11.2020 19:09:56
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.
Jupp, danke.
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...

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 » 29.11.2020 20:27:56

Als kleines Stichwort werfe ich mal ein

Code: Alles auswählen

make localmodconfig
ein.

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

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

Beitrag von worker777 » 29.11.2020 20:34:26

towo hat geschrieben: ↑ zum Beitrag ↑
29.11.2020 20:27:56
Als kleines Stichwort werfe ich mal ein

Code: Alles auswählen

make localmodconfig
ein.
Ja, danke Dir. Das ist schön und nett (und war mir bekannt), aber mir geht es:
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...

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

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

Beitrag von KP97 » 30.11.2020 13:33:44

Du schreibst:
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:
Ja, so ist es, und ich habe mich etwas mißverständlich ausgedrückt.
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
So wie es scheint ist bei 'COMPRESS' aber die Wahl 'lz4' zu nehmen die im Moment beste.
Nein, das ist nicht so. xz ist das beste Format mit dem besten Wert.
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...

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 15:28:42

KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 13:33:44
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.
Genau so habe ich das alles auch mehrmals(!) *schwitz :D* gemacht. Das ist wirklich sehr zeitaufwendig...!
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)?
KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 13:33:44
Der Standardkernel muß natürlich alles abdecken, daher ist er auch umfangreicher. Warum das bei Dir umgekehrt ist, kann ich mir nicht erklären.
Ich denke nicht, dass es bei mir umgekehrt ist(?). Der Standardkernel beinhalet ja Zeugs wie das AMD-Zeugt, etc. ...
KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 13:33:44
worker777 hat geschrieben:So wie es scheint ist bei 'COMPRESS' aber die Wahl 'lz4' zu nehmen die im Moment beste.
Nein, das ist nicht so. xz ist das beste Format mit dem besten Wert.
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.
Jupp, das ist so. Ich denke, da muss man abwägen, anhand von dem welche Hardware resp. CPU man hat.
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.
KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 13:33:44
Denke auch an den Kompilierbefehl bindeb-pkg...
Sir, ja Sir! :D ;)

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

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

Beitrag von KP97 » 30.11.2020 16:10:13

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.
...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?

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 16:23:28

KP97 hat geschrieben: ↑ zum Beitrag ↑
30.11.2020 16:10:13
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.
Okay, verstehe. Ja, vermute ich auch, aber eben die initrd-Grösse ... :roll: :D
Trotzdem vielen Dank für Deine Hilfe :THX:
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 :) ...

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 16:58:58

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.

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 » 30.11.2020 17:01:54

worker777 hat geschrieben:Ja, vermute ich auch, aber eben die initrd-Grösse ...
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
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...?

Antworten