A2 Manuelle Konfiguration des Kernels I

[pietinger]

(Dieser Post ist Teil einer Installation-Anleitung. Falls nicht schon geschehen lies bitte: Installation Guide for Paranoid Dummies)



A.2 Manuelle Konfiguration des Kernels I.

Ich habe diesen Teil vom ersten und dritten Teil getrennt, weil er vermutlich der am längsten dauernde Part der Installation sein wird. Gleich vorweg: Versuche nicht im ersten Anlauf einen "perfekten" Kernel zu konfigurieren. Das dürfte kaum möglich sein und ist auch gar nicht notwendig. Das wichtigste für den Anfang ist, dass er überhaupt bootet. Wenn da der Sound noch nicht funktioniert, ist das kein Problem - das kann man alles nachholen. Der Sound ist auch das häufigste Problem einer Kernel Konfiguration; wenn der nicht gleich auf Anhieb funktioniert bist Du in bester Gesellschaft und musst nicht gleich frustriert sein; bis jetzt haben wir aber noch jedes exotische Teil zum Laufen gebracht. Je öfter Du die Konfiguration des Kernels "aufsuchst", desto größer wird das Verständnis, wo, welche Teile, wie zusammen gehören.

Für den Anfang musst Du folgendes beachten:

1. Alles was der Kernel benötigt um seine Root-Partition zu finden MUSS statisch = fest in den Kernel eingebunden werden; also NICHT als Modul ! Was das ist MÜSSEN wir also wissen.
2. Alles wovon wir wissen, dass wir es (immer) benötigen, binden wir ebenso nicht als Modul ein, sondern statisch. Das hilft später, die Übersicht nach einem "lsmod" zu bewahren; noch später (in B.2) werden wir das tun um einen monolithischen Kernel zu basteln.
3. Wenn wir nicht wissen, was wir vielleicht zusätzlich benötigen, aktivieren wir alle relevanten Module und prüfen nach einem Neustart welche geladen wurden. Je weniger Module wir aber (unnötigerweise) mitcompilieren, desto schneller wird unser "make all".
4. Wenn wir wissen, das wir etwas nicht brauchen, schmeissen wir es sofort raus.
5. Editiere niemals die .config manuell ! Mache Änderungen an der Kernel-Konfig NUR über "make menuconfig". Du kannst gerne in der .config nach den vorhandenen Einstellungen suchen; manuell ändern darfst Du nichts ! Nur Gucken - nicht anfassen ! Grund: Viele Parameter beeinflussen (=aktivieren) andere Parameter - meist sogar unsichtbare ! Wenn Du neugierig bist kannst Du Dir diese Unsichtbaren anzeigen lassen, indem Du "z" in der "make menuconfig" drückst. Drücke danach nochmal "z" (toggle-funktion) um diese Anzeige wieder auszuschalten. Du brauchst das nicht und sie würden Dich nur verwirren (sie sind bei mir auch ausgeschaltet; das brauchen nur die Kernel-Entwickler oder wenn Du etwas suchst, was bisher unsichtbar ist). Lese dazu auch nochmal den Post Nr. 7 dieses Threads ...

Edit 2022-03-28: In diesem kurzen Artikel beschreibt @NeddySeagoon den Boot-Prozess einfach und verständlich. Lese es wenn Du noch nie einen Kernel konfiguriert hast:
https://wiki.gentoo.org/wiki/User:NeddySeagoon/PC_Boot_Process
(Wir benötigen kein initrd/initramfs weil wir unserem Kernel alles mitgeben, was er benötigt um seine Root-Partition zu finden)

Wir werden erst in A.3 einen Reboot durchführen. Sollte dann Dein Kernel nicht "durch-booten", führe bitte erneut folgende Schritte aus (oder falls Du jetzt eine Pause machen willst, um morgen weiter zu machen und Du den PC ausschaltest):

[pietinger]

Google Deine Hardware

1. Jeder Hersteller Deines Motherboards gibt Dir exakte Informationen über die verwendeten Chipsätze. Diese benötigst Du mindestens für Deine Soundkarte, da Du im Kernel den notwendigen Codec enabeln musst, Du diesen aber in keiner lspci-Abfrage siehst. Wenn Du für Deine Soundkarte vom Hersteller die Information "ALCxxxx" bekommst, weisst Du sofort, dass Du die "Realtek-Codecs" enabeln musst.

2. Die zweite Anlaufstelle ist "cateee.net". Mache diese Abfrage (das "n" ist wichtig):

[pietinger]

Vielen Dank an @mike155 der hier https://forums.gentoo.org/viewtopic-p-8517143.html#8517143 diesen einfachen und genialen Tip gab, den ich einfach 1zu1 hier reinkopiere:

[pietinger]

Aus aktuellem Anlass möchte ich noch einmal darauf hinweisen, warum es unter dem Gesichtspunkt der Sicherheit so wichtig ist, einen möglichst schlanken Kernel zu haben ... RAPL braucht kein privater User mit einem Desktop, sondern nur Server oder Mainframes - wenn überhaupt ...
Siehe aktuell: https://www.heise.de/news/Platypus-Sicherheitsluecke-missbraucht-Messfunktion-von-Intel-Prozessoren-4953484.html

Gerade kam ein Kernel-Update von 5.9.7 auf 5.9.8 herein, welches nur aus einem einzigen Patch besteht:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.9.y&id=b72aaa9506b38e68f3476a642d0e42b3071f82bb

Für mich kein Grund den sofort einzuarbeiten, denn ich habe:

# CONFIG_PERF_EVENTS_INTEL_RAPL is not set

... ich schreibe das einfach nur, weil es leider so oft die Meinung gibt, so viel wie möglich enabeln zu müssen ...

[pietinger]

Warum habe ich einen Unstable-Kernel mit Dir installiert ?

Zu dem Zeitpunkt der Erstellung dieser Doku-Reihe waren im damaligen stable Kernel noch nicht alle benötigten Features. Diese haben wir jetzt aber in allen 5.9er und dem jetzigen 5.10er. Ich werde weiterhin zu Testzwecken den neuesten Kernel installieren, doch möglicherweise ist es für Dich sinnvoll auf einen LTS kernel zu gehen. Hier findest Du eine Übersicht der derzeitigen long term support kernels:
https://www.kernel.org/category/releases.html

Wenn Du also auf dem jetzigen 5.10.x bleiben willst, musst Du nur alle neueren Kernels maskieren:

[pietinger]

I want it all, I want it all, and I want it now
[(c) by Queen]

Du hast schon viel Erfahrung in der Konfiguration eines Kernels und willst auch alles aus diesem Guide umsetzen. Weil Du aber nicht X-mal in die Kernel Konfiguration rein willst, möchtest Du deswegen gleich mal alles auf einmal im Kernel konfigurieren.

Das wäre theoretisch möglich wenn Du wüsstest welche Netfilter-Module Du für Deine FireWall-Konfiguration brauchst (Du weisst ja sicherlich, dass je nach FW-Konfiguration unterschiedliche Netfilter-Module benötigt werden). Ehrlich - ich weiß selbst nicht auswendig welche benötigt/angezogen werden. Deshalb habe ich es auch tatsächlich so gemacht, dass ich erstmal alle mit [M] reingenommen habe, und nach dem Abarbeiten von B.1 mit "lsmod" geprüft habe, welche angezogen wurden. Meiner Meinung nach ist es deswegen nötig, dass Du mindestens zweimal in die Kernel Konfiguration rein gehst/musst ... Wie könnte man dabei vorgehen ?

Beim ersten Mal (also hier/jetzt bei der Initialen Kernel Konfig) kannst Du auf einen Schlag folgendes konfigurieren:

1. Alles von A.2 (= hier 1.Post)
2. Alle Netfilter-Module mit [M] reinnehmen (wie in B.1 beschrieben)
3. Falls Du für Dein Notebook B.4 machen möchtest, gleich die dortig beschriebene Kernel-Konfig
4. Das 1. Kapitel von C.2 (hilft auch gleich für B.2 und D.2)
5. Alles von B.2 ausser das Disabeln des Modules-Support. Der bleibt erstmal drin ! Außerdem darfst Du LOCKDOWN erst enablen sobald Du entweder einen monolithischen Kernel hast, oder Du Deine Module signierst.
6. D.2 komplett (*)

Danach machst Du einfach Deine Grundinstallation nach A.3 weiter. Danach erledigst Du B.1 und weißt jetzt welche Netfilter-Module Du brauchst.

Zweiter Run:

1. Diese Netfilter-Module nimmst Du fest in den Kernel rein (und schmeißt die anderen unbenötigten raus).
2. Du disablest den Module Support und hast nun einen monolithischen Kernel
3. Den Rest von C.2


Als Experte erkennst Du sicherlich, dass einiges vom 1. Run in den 2. verschoben werden kann.

Minimum für den ersten wäre somit:

1. Die "MUSS" aus A.2
2. Alle Netfilter-Module mit [M] reinnehmen (wie in B.1 beschrieben)
3. Falls Du für Dein Notebook B.4 machen möchtest, gleich die dortig beschriebene Kernel-Konfig

Den Rest dann im zweiten Durchlauf ...


* Rückblickend muss ich feststellen, dass es einfacher (und damit sinnvoller) ist, zuerst D.AppArmor zu installieren und danach erst C.IMA zu machen. Das will ich Dir deshalb jetzt gleich empfehlen.



Ja ... für C.3 musst Du leider wirklich noch zweimal in die ... geht leider nicht anders ... Minimum ist deshalb 4 mal ...

.

[pietinger]

Folgendes muss ich einfach hier rüber kopieren, da ich es niemals so perfekt ausdrücken könnte wie unser @NeddySeagon:

[pietinger]

Update von 5.10.x auf 5.15.x

Heute hatte ich endlich mal Zeit dieses Update vorzunehmen. Die meisten neuen Optionen die beim "make oldconfig" abgefragt werden, sind mit "N" vorbelegt und können einfach mit <return> übernommen werden. Interessanterweise gab es zwei neue Optionen, die (im Hilfetext) von den Kernel Entwicklern empfohlen werden, als Default aber auch mit "N" vorbelegt sind. Ich bin dieser Empfehlung gefolgt und habe abweichend vom Default diese beiden enabled (den SimpleFB sollte man sowieso immer haben):

[pietinger]

Moderne Notebooks und ein Touchpad ...

... welches über i2c angesteuert wird kann zu Problemen führen. Falls es für Dein Notebook bereits eine Beschreibung gibt welche Kernel Module benötigt werden, lass' Dich davon leiten. Suche am besten erstmal in unserem Gentoo Wiki:
https://wiki.gentoo.org/wiki/Category:Laptops

Gerade die Thinkpads benötigen manchmal sehr ungewöhnliche Kernel Optionen; Beispiel: https://wiki.gentoo.org/wiki/Lenovo_ThinkPad_X1_Carbon_7th_generation
Während manche Intel Systeme sehr genügsam sind; Beispiel: https://wiki.gentoo.org/wiki/Dell_Latitude_5491#Touchpad
Ein weiteres Beispiel für ein AMD System: https://wiki.gentoo.org/wiki/Asus_Tuf_Gaming_fx505dy#Touchpad
Ein Dell XPS 9520 war sehr gemein: Wir dachten er benötigt PINCTR_ALDERLAKE, es war aber PINCTRL_TIGERLAKE. Was er sonst noch benötigt findest Du hier: https://forums.gentoo.org/viewtopic-p-8737053.html#8737053 (Wo Du diese Optionen einstellst findest Du hier weiter unten).
Das gleiche erneut bei einem System76 Darter Pro 8: https://forums.gentoo.org/viewtopic-t-1157071-highlight-.html
Und schon wieder bei einem MSI Katana GF66: https://forums.gentoo.org/viewtopic-t-1167454-highlight-.html

Wenn es keine Beschreibung für Dein Notebook gibt bleibt meist nur ein Suchen der benötigten Module. Hier kann folgendes helfen: Boote mit einer LiveCD von Ubuntu, oder der SystemRescueCD; prüfe dann aber in jedem Fall ob dort Dein Touchpad richtig erkannt wird; falls ja mache dann folgende Abfragen:

[pietinger]

Kernel Command Line Paramter: earlycon=efifb

Falls Du mal in die Verlegenheit kommen solltest, dass ein Kernel Developer Dir sagt Du sollst obigen Parameter aktivieren, dann könnte es Dir wie mir gehen: Es bewirkt NICHTS und Du hast im Systemlog:

[pietinger]

Update auf 6.1

Die Version 6.1 soll der nächste LTS Kernel werden, auch wenn es hier noch nicht gelistet ist (Stand:heute):
Edit 2023-02-07: Version 6.1 ist seit heute der neueste LTS Kernel:
https://www.kernel.org/category/releases.html
Mehr Infos dazu hier: https://www.phoronix.com/news/Linux-6.1-LTS-Official

Normalerweise würde ich mehrere (4,5,6,?) Minor-Versionen warten, bevor ich auf eine neue Major-Version wechsle. Das empfehle ich auch sonst immer jedem ! Gentoo macht das auch für stable Diesmal war ich aber ein wenig ungeduldiger, weil ich neugierig auf die neuen Security Optionen war. Außerdem habe ich mir die in 6.1.1 enthaltenen Patches angesehen und mit Freude festgestellt, dass keine - für mich - relevanten Patches enthalten sind. Auch die Anzahl der Patches war/ist erstaunlich klein. Tja ...

Meine erste Umstellung von 5.15.82 auf 6.1.1 war enttäuschend. Kein Sound mehr (der bei mir per DisplayPort direkt an den Monitor geht) ! Und das mit einer puren ALSA Konfiguration (= kein pulseaudio oder pipewire). Ich suchte nach der Ursache und dachte ich wäre von diesem Bug betroffen:
https://bugzilla.kernel.org/show_bug.cgi?id=216836
Nun ja, indirekt war ich schon betroffen von diesem Patch:
https://github.com/torvalds/linux/commit/ef6f5494faf6a37c74990689a3bb3cee76d2544c

Denn mein erster Boot mit 6.1 brachte mir vom ALSA RC-Script (alsasound) mehrere Fehler: [...] failed to obtain info for control #65 (No such file or directory)

Ursache war dann, dass tatsächlich einige Devices dank diesem Patch weggefallen sind und ich meine /etc/asound.conf anpassen musste: Statt 7 war mein HDMI-Ausgang nun 3:

[pietinger]

Update auf 6.6


Da bereits feststeht dass Version 6.6 ein LTS Kernel ist, habe ich wieder sehr früh auf diesen geupdated ... weil hier wieder neue Security Optionen verfügbar sind. Die Änderungen in der Kernel Konfiguration im Vergleich zum 6.1-er sind ziemlich überschaubar:

Der KEXEC ist von "Processor type and features" nach "General setup -> Kexec and crash features" gewandert. Man kann keinen Microcode mehr enablen ... weil er standardmäßig bereits (unsichtbar) enabled ist. Und das Menu "Framebuffer" ist umgeschichtet worden.

make oldconfig

Im folgenden werde ich wieder nur die Optionen beschreiben (in der Reihenfolge wie es beim "make oldconfig" auftritt/abgefragt wird):

a) wo ich vom Default abgewichen bin, oder
b) wo Du den Default unbedingt übernehmen solltest, oder
c) die nur für Dich interessant sein könnten, oder
d) aus einem sonstigen Grund.

Wieder gilt: Es sind einige neue Module für Notebooks dazu gekommen. Sobald also beim "make oldconfig" die Driver-Sektion startet, solltest Du etwas genauer hinschauen, wenn irgendwo etwas mit "MSI" oder anderen abgefragt wird (und Du dieses Teil hast).

[mortonP]

[pietinger]