Vanilla Eigenbau 4.19

[fischig]

Ich versuche einen Vanilla-Kern 4.19 für HP Pavilion dm1 (1) ohne initrd zubauen. Der Kern hängt beim Booten (lilo) mit

Code: Alles auswählen

unable to mount root fs on unknown-block (8,5)

In lilo.conf steht root=/dev/sda5. Der Standardkern 4.19 bootet damit. ext4, devtmpfs und devtmpfs_mount sind fest im Kern einprogrammiert (kein Modul). Weiß nicht mehr weiter.

(1) Datenblatt: https://support.hp.com/at-de/document/c03635346 keine Ahnung, ob der Zusatz 4400sg bei der Modellbezeichnung relevant ist

[fischig]

Die erste mit defconfig erstellte Version bootet schon mal durch.

Was oder wo ist "the ARCH supplied defconfig file"?

[Tintom]

Wie sieht denn die config des Kernels aus?

[fischig]

Es wird noch eine Weile dauern, ich kämpfe gerade gegen iptables. Irgendwas ist mit „conntrack“.

Hier schon mal die letzte config: (1)
(1) pastebin/?mode=view&s=41372

Bei Benutzung eines mit dieser config kompilierten Kerns werden die relevanten Netzwerkkarten eth0,eth1,wlan3 konfiguriert (kontrolliert mit ip a). Was bisher nicht funktioniert ist der Internet-Zugang üer den DSL-Router.

Der Versuch, diese iptables-Regel einzugeben:

Code: Alles auswählen

# iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

scheitert mit:

Code: Alles auswählen

Couldn't load match `conntrack':No such file or directory

Aber „conntrack“ ist für Laien offenbar ein weites Feld in der Kern-Konfiguration.

[Tintom]

Ich verstehe jetzt nicht: Bootet der Kernel mit der letzten config oder nicht? Die Fehlermeldung über das nicht erkannte Blockgerät ist damit verschwunden?

[fischig]

Tut mir leid, da habe ich einiges ausgelassen, was zwar in meinem Kopf war, aber nicht hingeschrieben wurde. „Normalerweise“ nehme ich die config eines anderen für einigermaßen passend gehaltenen Eigenbau-Kerns und passe die via oldconfig an. Das hatte ich eingangs gemacht und das erzeugte die erste Fehlermeldung. Zwischen meinem ersten Post und meinem zweiten liegen knapp 6 Stunden ohne Antwort (was ich niemanden vorwerfe!). (Woran die Meldung lag, ist mir weiterhin unklar.) Zwischenzeitlich habe ich aber natürlich weitere Kompilationen probiert und bin letztlich von oldconfig abgekommen und habe es mit defconfig versucht. Das brachte dann insofern den gewünschten Erfolg, dass der damit erzeugte Kern wenigstens durchbootete. Insofern: Ja, die Fehlermeldung „ist damit verschwunden“. Die Kern-Vorbereitungen für die Konfiguration der Netzwerkkarten habe ich darüber ebenfalls geschafft. Das ist jetzt Stand der Dinge. Der Kern soll auf einem HP Pavilion als Linux-Router mit iptables arbeiten. Das funktioniert noch nicht.

Wenn ich lsmod beim Debian Standard-Kern (4.19) laufen lasse, kriege ich u.a. das Modul „ip_tables“ genannt. Das findet sich dann weder in der config dieses Kerns, noch findet es die Suche mit menuconfig. Das mag Gründe haben. Da ich kein Profi bin und die nicht kenne, bleibt für mich nur Verwirrung. Habe ich auch schon bei anderen Modulen erlebt.

[fischig]

Wenn ich versuche, dieses Kommando abzusetzen:

Code: Alles auswählen

# iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

kommt:

Code: Alles auswählen

iptables v1.8.2 (nf_tables): Couldn't load match `conntrack':No such file or directory

Der 4.19-Standard-Kern akzeptiert das Kommando.

[towo]

Nuja,

Code: Alles auswählen

grep -i conntrack /boot/config-$(uname -r)

dürfte erhellend sein.

[fischig]

Danke!
Erhellend? nun ja:
grep -i conntrack /boot/config-4.19.0-16-amd64:

Code: Alles auswählen

 
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CONNTRACK_TIMEOUT=y
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_LABELS=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_SNMP=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

grep -i conntrack /boot/config-4.19.190def.4

Code: Alles auswählen

CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_PROCFS=y
# CONFIG_NF_CONNTRACK_LABELS is not set
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_IRC=m
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

Alles was ich sehe, ist: Der Standard-Kern hat deutlich mehr „conntrack“ -Module als mein selbst gebauter. Und die fehlenden nun ALLE zu aktivieren, schmeckt mir noch nicht so richtig, es sei denn man sagt mir, die werden auf meinem Pavilion-Router auch ALLE benötigt.

Zusatzfrage: der Namensbestandteil „nf“ isteine Abkürzung von/für „netfilter“ - richtig?

[Tintom]

Ich würde aus eigener Erfahrung empfehlen von einem kastrierten Eigenbaukern für einen Router abzusehen. Zum einen, sofern du nicht 100% weißt was du tust, bekommst du im laufenden Betrieb unerklärliche Aussetzer, Fehlermeldungen o.ä. weil ein Modul fehlt oder eine Option falsch gesetzt ist (wie hier geschehen). Zum anderen musst du bei jedem Sicherheitsupdate des Kernels einschätzen können ob dein Kern davon auch betroffen ist und ggf. neu bauen.
Damit ersteres nicht geschieht kannst du den Kernel bauen, in dem du den Standardkern aus Debian startest und aus dem laufenden Betrieb ein make localmodconfig oder - wenn du keine Module laden willst - ein make localyesconfig abfeuerst. Beim zweiten Punkt wäre das Abo der Debian-Security Mailingliste empfehlenswert (ist es übrigens immer, also auch ohne Eigenbau-Router )

Was deine Fehlermeldung angeht würde ich auf die Option CONFIG_NF_CONNTRACK_LABELS=y tippen, diese fehlt bei dir. Erläuterung siehe hier:
https://github.com/torvalds/linux/blob/ ... #L165-L170

[fischig]

Ich praktiziere das eigentlich seit Jahren - auch auf von mir zu Linux-Routern umfunktionierten Klapprechnern. An „unerklärliche Aussetzer, Fehlermeldungen o.ä.“ erinnere ich mich nicht. Muss nichts heißen, ist mir auch klar. Localmodconfig war mir bekannt, hatte ich aber im gegebenen Zusammenhang gar nicht im Kopf. Danke für den Hinweis!

Bei der näheren Beschäftigung ist mir die Funktionsweise noch nicht ganz klar:

es greift sich die Konfigurationsdatei des Distributionskernels als Basis und deaktiviert die Konfigurationseinträge für Module, die das jeweilige System nicht benötigt; den Rest der Konfigurationsdatei lässt es unverändert.

(1)
Heißt erst mal:Zumindest die Konfiguration muss auf der gleichen Maschine laufen, auf der auch der angepasste Kern laufen soll - richtig? - Die Kompilation auch?

"make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loaded modules.

(2)

Ich verstehe das so, dass alle geladenen Module mitgebaut werden, auch wenn sie vielleicht gar nicht benötigt werden. Das schmeckte mir weinger und wäre dann etwas anderes, als das, was inder c't behauptet wird.

Lese ich falsch oder was gilt?

Was deine Fehlermeldung angeht, würde ich auf die Option CONFIG_NF_CONNTRACK_LABELS=y tippen

Werde ich nachschauen. Der zughörige Link sagt mir nicht mehr, als ich auch in der Menuconfig-Hilfe lese.

(1) https://www.heise.de/ct/artikel/Linux-K ... 02386.html
(2) https://itectec.com/unixlinux/linux-wha ... config-do/

[towo]

Ich verstehe das so, dass alle geladenen Module mitgebaut werden, auch wenn sie vielleicht gar nicht benötigt werden. Das schmeckte mir weinger und wäre dann etwas anderes, als das, was inder c't behauptet wird.

Dir is schon klar, dass Module nur geladen werden, wenn sie benötigt werden?

[fischig]

Dir is schon klar, dass Module nur geladen werden, wenn sie benötigt werden?

Nein, ist es nicht, und zweifle ich auch in dieser Allgemeinheit erst mal an.

Wichtiger wäre mir auch eine Antwort auf die andere Frage: Was die Kompilation angeht, dann machte ich das lieber auf einer Maschine, die dafür besser geeignet ist. Der Pavilion ist dabei ziemlich lahm und auch ziemlich gestresst.

edit:
Es sind zwar keine Module, aber wie ich bei der Anwendung von localmodconfig feststelle: der Debian-Kern enthält z.B. offenbar eine ganze Reihe von fest einkompilierten Treibern für WLAN-Karten, die gar nicht genutzt werden, die aber mit localmodconfig alle wieder einkonfiguriert werden. Ich frage mich, ob sowas analog auch für Module zu bedenken ist.

[MSfree]

grep -i conntrack /boot/config-4.19.190def.4

Code: Alles auswählen

CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_PROCFS=y
# CONFIG_NF_CONNTRACK_LABELS is not set
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_IRC=m
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

Für mich ist das ein wenig widersprüchlich. Module, die mit "y" markiert sind, weiden statisch in den Kernel kompiliert, Module, die mit "m" markiert sind, werden als seperates Kernelmodul (vulgo ladbarer Treiber) erzeugt und in den Dateibaum unter /lib/modules kopiert.

Du hast aber z.B. CONFIG_NF_CONNTRACK_SECMARK=y statisch während du CONFIG_NF_CONNTRACK=m ladbar kompilierst. Da CONFIG_NF_CONNTRACK sozusagen die Mutter aller Conntracks ist, sollte das ebenfalls statisch kompiliert werden oder eben alle Kindmodule ebenfalls ladbar. Dieser Mischmasch dürfte zumindest ein Teil deines Problems sein. Das kann man zwar lösen, indem man das nf_conntrack Modul in die Datei /etc/modules einträgt und so das Laden erzwingt, aber automatisches Laden dürfte in dieser Konstellation fehlschlagen.

[fischig]

Dieser Mischmasch dürfte zumindest ein Teil deines Problems sein.

Was daran liegt, das ich natürlich versuche, mich bezüglich der Paketfilterung an der Konfiguration des Standard-Kern zumindest zu orientieren. Das Gelände ist halt für mich ziemlich unübersichtlich. Aber es ist das einzige, was nicht funktioniert. Und ich möchte fast wetten, dass da einiges im Standard-Kern herumschwirrt, was ich auf meinem Router nicht benötige. (Das ist hier ein popeliges Heimnetz - ich biete nichts, gar nichts, als Dienst im Internet an - ich glaube meine Grenzen zu kennen).

Im Augenblick verfolge ich den Ansatz mit localmodconfig. Mal sehen, was dabei herauskommt.

Noch was zu towo: Der Standard-Kern lädt den gesamten Sound Kram. Ich kann mir nicht vorstellen, dass mein Router den benötigt.

[towo]

Dieser Mischmasch dürfte zumindest ein Teil deines Problems sein.

Wohl kaum, da Debian das auch so macht.

[MSfree]

Dieser Mischmasch dürfte zumindest ein Teil deines Problems sein.

Wohl kaum, da Debian das auch so macht.

Ich hatte irgendwann mal das Problem, daß ich ein Parentmodul als Modul und das Childmodul statisch gebaut hatte. Das Parentmodul wurde dann nicht automatisch in den Kernel geladen, wenn man die Funktionen des Childmoduls benutzen wollte. Frag mich nicht, welche Kernelversion das war, gut möglich, daß das heute funktioniert.

[Tintom]

edit:
Es sind zwar keine Module, aber wie ich bei der Anwendung von localmodconfig feststelle: der Debian-Kern enthält z.B. offenbar eine ganze Reihe von fest einkompilierten Treibern für WLAN-Karten, die gar nicht genutzt werden, die aber mit localmodconfig alle wieder einkonfiguriert werden. Ich frage mich, ob sowas analog auch für Module zu bedenken ist.

Ich habe das oben nicht weiter ausgeführt, weil ich dachte es wäre soweit klar: Mit make localmodconfig bekommst du eine config, mit der du einen funktionierenden Kern backen kannst. Das ist sinnvoll bei Problemen, wie sie in diesem Thread behandelt werden, also wenn du nicht sicher bist ob ein Modul benötigt wird oder nicht. Es ist jedoch nicht der Weisheit letzter Schluss. Will heißen: Danach musst do sowieso noch händisch alles rausnehmen, was du nicht haben willst, weil du sicher bist, dass du es nicht brauchst (z.B. Sound). Gegenüber dem händischen Ausmisten der Standardconfig von Debian sparst du so aber einiges an Zeit.

[fischig]

Den „funktionierenden“ Kern (funktionierend im Sinne von bootend) bekomme ich auch mit defconfig und welche Treiber ich für die NICs ich benötige, weiß ich inzwischen. (Ob der Kern dann schlanker funktioniert, bezweifle ich inzwischen.) Ich hatte es mir in meiner Einfalt einfacher vorgestellt, „das bisschen netfilter“ nachzuinstallieren. Aber im Grunde sehe ich voll ein: Wenn man sich da nicht wirklich auskennt, bleibt einem nichts anderes übrig, als alles via localmodconfig zu übernehmen und nachzuarbeiten. Ob das schneller geht, zumindest bei meiner Wenigkeit, lasse ich mal offen: Mittlerweile läuft die dritte Kompilation, weil ich wieder mal was Nachzuarbeitendes vergessen hatte.

[towo]

Die wichtigste Frage ist, was versprichst Du Dir eigentlich davon, unbedingt einen Kernel selber zu bauen?

[fischig]

Ob das die wichtigste Frage ist, sei mal dahingestellt und die Antwort geht für mich eigentlich aus dem vorangehenden hervor, aber ich beantworte sie trotzdem nochmal: Ein schlankerer, maßgeschneideter Kern und um ein anderweitig genanntes Argument unames aufzugreifen: Was nicht existiert, kann nicht kaputtgehen und auch nicht angegriffen werden.

Um nicht missverstanden zu werden: Ich bezeifle keinesfalls die Sinnhaftigkeit eines Standard-Kerns.

[fischig]

Tja, nun habe ich so'n typisches Henne-Ei-Problem: Ich will die initrd vermeiden. Via defconfig gelingt das, weil damit das Benötigte fest einkompiliert wird. Mit localmodconfig gelingt das nicht, weil das sich halt am Standard-Kern orientiert. Und localsysconfig möchte ich einstweilen vermeiden.

[towo]

hint *localyesconfig*

[fischig]

hint *localyesconfig*

Hatte ich schon vorher im Kopf, hab's aber leider verschrieben: „localsysconfig“
Wuppt! auch mit den beiden iptables-Regeln. Danke!

Schmeckte mir halt nicht besonders, insbesondere weil ich noch nicht abschätzen kann, wie aussagekräftig/hilfreich jetzt noch die Ausgaben von lsmod für diesen Kern sind.