/etc/modules, /var/loog/boot (gelöst)

[fischig]

# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

Passiert aber nicht, was im 2.Satz steht. Wieso? Eigenbaukern 6.1, System ohne udev

[towo]

Tja, is halt so, wenn man meint, ohne udev fährt man besser.

[bluestar]

# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

Passiert aber nicht, was im 2.Satz steht. Wieso? Eigenbaukern 6.1, System ohne udev

Ist das nicht gerade ein Feature von OpenSource? Du kannst dein System genau nach deinen Wünschen umbauen. Ich stelle mir ein wenig die Frage nach dem Sinn deines Posts.

[fischig]

https://de.wikipedia.org/wiki/Der_eindi ... ale_Mensch
Wenn ich mir towos Reaktion anschaue, dann scheinen mir schlichte Fragen schlicht unerwünscht zu sein. Was soll ich mit so'ner Aussage anfangen? Lass die Finger von deinem System, wir wissen besser, was gut für dich ist (towo hat sich selbst hier als Kernel-Entwickler/Betreuer geoutet) Rechner verkaufen? Strick nehmen?.

Du kannst dein System genau nach deinen Wünschen umbauen.

Genau das habe ich vor. Wenn ich richtig informiert bin, haben Einträge in /etc/modules den Zweck, Module beim Booten (auch unabhängig von udev) zu laden. Bei Benutzung von udev sind Einträge in der Regel überflüssig. (In meiner Datei stehen Module drin, die ich glaube nicht (mehr) zu benötigen und die ich im Verdacht habe, das Booten meiner Eigenbau-Kerne zu behindern. Im Verdacht, wohlgemrkt, vielleicht täusche ich mich ja.) Wenn ich den zweiten Satz richtig lese, dann räumt der mir doch genau diese Möglichkeit ein: Laden angegebener Module beim Booten (z.B. testweise, auch ohne Umbau) zu verhindern. Und nun frage ich, warum das nicht passiert. Entweder lese ich falsch oder ich mache einen anderen Fehler. Das hätte ich gerne geklärt, falls sich jemand zu einer Klärung in der Lage sieht.

Ich kann's ja nochmal anders formulieren: Warum werden Kernel-Module geladen, obwohl sie in /etc/modules auskommentiert sind?

Waren jetzt meine vorstehenden Erläuterungen für die Beantwortung der Frage wirklich nötig?

edit:
Autor des Zitates korrigiert!

[MSfree]

Genau das habe ich vor. Wenn ich richtig informiert bin, haben Einträge in /etc/modules den Zweck, Module beim Booten (auch unabhängig von udev) zu laden.

Die Liste der Module, die du in /etc/modules einträgst, wird aber nicht automatisch vom Kernel abgearbeitet. systemd hat dazu einen eigenen Service (modprobe@.service), der die aufgeführten Module per modprobe lädt. Analog gab es ein Skript in /etc/init.d, das das Gleiche unter SysV-Init gemacht hat.

[JTH]

Ich kann's ja nochmal anders formulieren: Warum werden Kernel-Module geladen, obwohl sie in /etc/modules auskommentiert sind?

In /etc/modules kannst du manuell Module eintragen, die durch modprobe zusätzlich zu den an anderer Stelle automatisch für deine Hardware ausgewählten geladen werden sollen. Ein Auskommentieren dort kommt nicht einem Blacklisten gleich. Letzteres müsstest du mittels einer .conf-Datei in /etc/modprobe.d/ tun, siehe man modprobe.d dazu.

Ich weiß zugegebenermaßen nicht genau, wie der Funktionsweg auf einem System ohne udev ist. Nehme aber mal stark an, dass zumindest modprobe dort auf vergleichbare Weise ins Spiel kommt und obiges Blacklisten daher auch dort gilt und funktioniert.

Der Vollständigkeit halber: Auf einem System mit systemd könnte man gleichwertig /etc/modules-load.d/ vom systemd-modules-load.service benutzen.

[fischig]

In /etc/modules kannst du manuell Module eintragen, die durch modprobe zusätzlich zu den an anderer Stelle automatisch für deine Hardware ausgewählten geladen werden sollen.

Danke sehr! Dann habe ich die Info in der Datei wohl falsch interpretiert. Aber wenn das so ist, dann kann ich keinen darin Sinn erkennen, Module auszukommentieren.

Ich meine immer noch, mal gelesen zu haben, dass alle Module, die bei Verzicht auf udev beim Booten geladen werden müssen, zwingend in /etc/modules aufgeführt sein müssen. Und da lag für mich in Verbindung mit diesem Kurzkommentar der Schluss nahe, dass Module, die nicht geladen werden sollen, auf diese Weise auskommentiert werden können. Wie lange das her ist, dass ich das gelesen habe, und ob das noch gilt, weiß ich nicht. Entfernen werde ich die mit dem nächsten Kernel sowieso. Ich wollt' halt vorher mal schauen, was beim Booten passiert, wenn ich sie auskommentiere.

[JTH]

Aber wenn das so ist, dann kann ich keinen darin Sinn erkennen, Module auszukommentieren.

modprobe ist das egal, was die Datei hinter den # als Kommentare enthält. Das kann der Name eines gerade nicht ausdrücklich gebrauchten Modules

Code: Alles auswählen

#efivarfs

oder eine Gedächnisstütze

Code: Alles auswählen

# Das folgende Modul X wird für Y benoetigt:

oder ein Gedicht sein. Kommentare sind – wie überall – ein Angebot an dich, dort etwas ohne vorgeschriebene Form reinzuschreiben, was das verarbeitende Programm später ignoriert ohne sich irritieren zu lassen. Nicht mehr, nicht weniger. Eine Funktion hat der Text eines Kommentars damit ausdrücklich nicht.

Das Auskommentieren hat hier (= in /etc/modules) also den Effekt „ich bestehe nicht (mehr) auf diesem Modul“, nicht „ich will dieses Modul auf keinen Fall (mehr) geladen haben“.

Ich meine immer noch, mal gelesen zu haben, dass alle Module, die bei Verzicht auf udev beim Booten geladen werden müssen, zwingend in /etc/modules aufgeführt sein müssen.

Mit dem Szenario kenn ich mich, wie gesagt, nicht aus. Das mag (weiterhin) notwendig sein. Falls dir ohne Eintrag was wichtiges fehlt, wirst du es ja beim nächsten Boot merken

[fischig]

Dass modprobe im Boot-Prozess eine Rolle spielen könnte, war mir bisher überhaupt nicht bewusst. Ich hielt das immer für ein Kommando, mit dem der User händisch irgendwelche Kernel-Module temporär (nach)laden könnte, die im Kernel zwar vorhanden, aber aus welchen Gründen auch immer beim Booten nicht geladen werden.
Die fraglichen Module sind parport, parport_pc, ppdev, ( lp). Ich habe den Vanilla-Kern 4.19.297 ohne diese Module neu kompiliert und in /etc/modules eliminiert. Das System bootet durch und tut was es soll (Druckserer), unabhängig davon, ob ich nun udev installiert habe oder nicht. In /var/log/boot finden sich aber nach wie vor diese Meldungen:

Code: Alles auswählen

Tue Oct 31 11:07:20 2023: modprobe: FATAL: Module lp not found in directory /lib/modules/4.19.297
Tue Oct 31 11:07:20 2023: Loading kernel module ppdev.
Tue Oct 31 11:07:20 2023: modprobe: FATAL: Module ppdev not found in directory /lib/modules/4.19.297
Tue Oct 31 11:07:20 2023: Loading kernel module parport_pc.
Tue Oct 31 11:07:21 2023: modprobe: FATAL: Module parport_pc not found in directory /lib/modules/4.19.297
Tue Oct 31 11:07:21 2023: Loading kernel module lp.
Tue Oct 31 11:07:21 2023: modprobe: FATAL: Module lp not found in directory /lib/modules/4.19.297

(System zuletzt mit udev. Korrekterweise müsste man wohl sagen: mit systemd-udev. Meines Wissens ist udev seit geraumer Zeit Bestandteil der systemd-Projekts, wie integral weiß ich nicht).

Wie erklärt sich das? (Wenn die Frage erlaubt ist.) Wieso versucht modprobe beim Booten Module zu laden, die weder einkompiliert noch in /etc/modules eingetragen sind?
Am Verzicht auf udev hängt mein Herz nicht, ich hatte das ursprünglich eigentlich nur erwähnt, um möglichen Vorwürfen einer „Salami-Informations-Taktik“ vorzubeugen (gebranntes Kind scheut das Feuer, aber wie man's macht, macht man's falsch, jedenfalls für towo).

Hintergrund des Threads:
Ich versuche herauszufinden, warum ein auf der Basis der config des funktionierenden 4.19.297-Vanilla-Kernels gebauter aktuellerer Vanilla-Kern-6.1.53 beim Booten hängenbleibt. Und mittlerweile denke ich, dass die hier in Rede stehenden Module dabei keine Rolle spielen, aber das ist dann Thema eines neuen Threads.

[MSfree]

Möglicherweise kommen die modprobes durch die initrd.

[fischig]

Wenn damit initrd.img gemeint ist: Die gibt's nicht/wird ohne udev meines Wissens nicht benötigt. Einer der Gründe, warum ich mir meistens eigene Kerne baue.

[MSfree]

Wenn damit initrd.img gemeint ist: Die gibt's nicht/wird ohne udev meines Wissens nicht benötigt.

initrd hat nichts mit udev zu tun. Die initrd wird auf jeden Fall benötigt, wenn Kernelmodule geladen werden sollen, die Firmware anziehen (z.B. Intelgraphik, WLAN...).

Was mir aber auffält, ist:

Code: Alles auswählen

Tue Oct 31 11:07:20 2023: modprobe: FATAL: Module lp not found in directory /lib/modules/4.19.297

Wieso wird da versucht, wtwas aus /lib/modules/4.19.297 zu laden, wenn du dir den Kernel 6.1 baust?

[fischig]

Die initrd wird auf jeden Fall benötigt, wenn Kernelmodule geladen werden sollen, die Firmware anziehen (z.B. Intelgraphik, WLAN...).

Hmmm,
Mein Vanilla-Kernel 4.19.297 funktioniert (wie alle meine Eigenbau-Kerne) ohne initrd.img.
Über die Firmware habe ich dabei noch nie nachgedacht.

[edit]

Wieso wird da versucht, etwas aus /lib/modules/4.19.297 zu laden, wenn du dir den Kernel 6.1 baust?

Das hast du missverstanden. Vergiss meinen „Hintergrund“. Ich sagte ja, das ist ein anderes Thema. In diesem Thread geht's nur um 4.19.297

[Tintom]

initrd hat nichts mit udev zu tun. Die initrd wird auf jeden Fall benötigt, wenn Kernelmodule geladen werden sollen, die Firmware anziehen (z.B. Intelgraphik, WLAN...).

Hm, hat sich da was geändert? Hast du eine Quelle?
Das Konzept der Initrd war ja, eine Ramdisk mit notwendigen Kernelmodulen bereitzustellen, die für den Kernel in der ersten Bootphase unerlässlich sind. Sobald das Root-FS geladen ist und der Kernel Zugriff auf seine Module hat, ist die Initrd überflüssig. Wenn für diese notwendigen Kernelmodule eine Firmware notwendig ist (z.B. Maschine bootet über Netzwerk und Netzwerkkarte braucht Firmware) stimme ich dir zu, die Firmware kann man in die Initrd mit einbauen.

Ich meine aber mich dunkel zu erinnern, dass meine Eigenbaukerne ohne Initrd gelaufen sind und das Firmware im weiteren Bootprozess durch das jeweilige Kernelmodul nachgeladen wurden. Das ist aber >10 Jahre her, mag sein, dass meine Erinnerung mir da einen Streich spielt.

Seinerzeit bekam ich aber bei meinen Eigenbaukernen einen schwarzen Bildschirm, wenn das Framebuffer-Modul nicht inkludiert war. Das eigentliche Modul für die Grafikkarte war aber immer modular.

@fischig Hast du versucht die verbose level heraufzusetzen?

[fischig]

Ich meine aber mich dunkel zu erinnern, dass meine Eigenbaukerne ohne Initrd gelaufen sind.

Meine laufen aktuell so. Wir reden vom jeweiligen initrd-image (/boot/initrd.img)?

Hast du versucht die verbose level heraufzusetzen?

Wie mache ich das?

Und nochmal: Im Moment beschäftigt mich, warum beim vollständig bootenden Vanilla-Kern 4.19.297 unter /var/log/boot die parport-Module als fatal fehlend moniert werden, obwohl die weder einkompiliert noch in /etc/modules gelistet sind und auch kein initrd.img vorhanden ist.

[Livingston]

Vanilla 4.19.297?
Also naturbelassen von kernel.org, ohne patches und ohne Veränderung der config?
Oder Vanilla, wie man früher verwirrendermaßen mal Debian-Kernels nannte, sofern man ihre config nicht geändert hat.
Ich frage, weil Debian schon immer dem Original-Kernel ne Menge Patches verpasst hat (und dies auch immer noch tut), und auch zu diesem weiterentwickelten Produkt gerne "Vanilla" gesagt wird.
Davon mag abhängen, was von diversen Init- oder Systemd-Konfigurationen erwartet wird. Wenn Dein Vanilla bspw. kein parport-Modul bereitstellt (z.B. weil diese Codeabschnitte in den monolithischen Kernel einkompiliert sind), dann kann vielleicht ein Init-Skript, das von seinem Vorhandensein ausgeht, modprobe aufrufen und folgerichtig scheitern.
Ich stocher hier ein wenig im Nebel, weil mir nicht klar ist, was Du hier konkret mit Vanilla meinst. Ich verstehe darunter:

• unverändert
• nix selbst kompiliert.

Meinen wir das selbe? Wenn ja, von welcher Quelle: kernel.org oder Debian? Wenn letzeres: Welches Release? (Ist schon etwas länger her, dass ich was mit der 4er-Reihe zu tun hatte.)

[Tintom]

Hintergrund des Threads:
Ich versuche herauszufinden, warum ein auf der Basis der config des funktionierenden 4.19.297-Vanilla-Kernels gebauter aktuellerer Vanilla-Kern-6.1.53 beim Booten hängenbleibt. Und mittlerweile denke ich, dass die hier in Rede stehenden Module dabei keine Rolle spielen, aber das ist dann Thema eines neuen Threads.

Und nochmal: Im Moment beschäftigt mich, warum beim vollständig bootenden Vanilla-Kern 4.19.297 unter /var/log/boot die parport-Module als fatal fehlend moniert werden, obwohl die weder einkompiliert noch in /etc/modules gelistet sind und auch kein initrd.img vorhanden ist.

Du siehst ja an den Zeitstempeln, dass hier nicht das Problem liegen kann. In dem Moment, wo die Fatal-Meldung kommt, ist das Versuchen des Ladens der Module abgeschlossen und der Bootprozess ist im nächsten Schritt.

Wie mache ich das?

Im ersten Schritt in der cmdline das Wort quiet entfernen. Wenn das nicht hilft, dann die Option debug probieren.

[fischig]

@Livingston

mir nicht klar ist, was Du hier konkret mit Vanilla meinst.

Diese Bedeutungsunterschiede waren mir nicht bewusst. Ich habe den Begriff bisher immer im Sinne eines auf der Basis der Quellen von kernel.org selbst kompilierten kernels verwendet. „Verändert“ habe ich den dabei immer. Ich benötige ja eine config für die Kompilation der Quellen und eine vorgefertigte liefert kernel.org meines Wissens nicht.

Ich kann mir auch deine 1. Frage hernehmen

naturbelassen von kernel.org, ohne patches und ohne Veränderung der config?

naturbelassen: ja
von kernel.org: ja
ohne patches: ja
ohne Veränderung der config: es gibt meines Wissens keine von kernel.org gelieferte config.

Ich nehme immer die config eines auf dem System funktionierenden Kernels und passe die via make oldconfig und make menuconfig an die neuen Quellen an. Wobei diese configs letztlich vermutlich von einer vor ca. 15-20 Jahren mit make defconfig erstellten Version abstammen. Quellen immer von kernel.org. Debian-Quellen habe ich dabei nie benutzt. Von woody, vielleicht auch sarge bis buster (4.19) habe ich das immer zum Laufen gekriegt. Seit bullseye (5.10) kriege ich das nicht mehr durchgängig hin. Aber letzteres ist, wie ich schon sagte, ein weiteres Thema.

@TinTom

Im ersten Schritt in der cmdline das Wort quiet entfernen. Wenn das nicht hilft, dann die Option debug probieren.

Probiere ich und melde mich dann.

[Livingston]

Mal abgesehen davon, dass der Vorschlag mit dem Loglevel ein paar neue Erkenntnisse bringen kann, lasse ich mal die Gedanken zum Modulladen frei kreisen.

Wo und wann werden Module geladen?

1. In der initrd... können wir in Deinem Fall wohl ausschließen.
2. In der frühen Boot-Phase "melden" sich über den PCI-Bus "neue" Geräte. In der Regel stecken sie schon im Rechner (z.B. interne Festplatte), aber sie müssen initial erst mal registriert werden. Was da gefunden wird, bezeichnet man als "Cold Plug"-Geräte. (Später, wenn USB und Co laufen, kommen noch "Hot Plugs" dazu.) Diese Registrierungen werden "events" genannt, die nun von udev abgerufen und verarztet werden können. In der Regel führt das dazu, dass udev Geräte unter /dev bekannt macht und benennt und letztlich nach passenden Modulen sucht. Es schaut dabei nicht in /etc/modules nach. Soweit gefunden wird udev die besagten Module mit Hilfe von insmod oder modprobe laden. Modprobe schaut dabei immer in die Inhalte der Dateien unter /etc/modprobe.d/ (und seit einiger Zeit auch unter /etc/modules-load.d/ [1] ). Entsprechende Anweisungen darin werden berücksichtigt (Blacklisting, Optionen, Aliase, etc.).
3. Nach dieser Phase können Bootscripte verschiedener Softwarepakete aktiv werden und ggf. Module nachladen. Je nach init-System sind das Scripte unter /etc/rcXXX oder aus dem systemd-Universum. Hier könnten sich Bugs einschleichen, z.B. dass ein Paket das Vorhandensein bestimmter Module erwartet, obwohl sie auch fest im Kernel einkompiliert sein können. Letztlich bedienen sich auch die Scripte der Programme insmod und/oder modprobe.
4. Die Datei /etc/modules wird auf alle Fälle auch noch von einem Bootscript durchgegangen und für das Vorgefundene modprobe bemüht.
5. Zu guter Letzt, kann man nach Ablauf des Bootens mit root-Rechten manuell modprobe aufrufen, oder KDE/Gnome/wasauchimmer finden einen Grund, dies bspw. über den pkexec-Mechanismus zu veranlassen (und auch hier übernimmt am Ende der Kette modprobe die Arbeit).

Soweit erst mal die vermutlich nicht ganz vollständige Übersicht, wer oder was nach Modulen schreien kann.

[1] /etc/modules-load.d/ kommt zusätzlich durch systemd-modules.load.service ins Spiel. Im Großen und Ganzen ergänzt es also das hier unter Punkt 2 Genannte.

[KP97]

@Livingston
Das hast Du aber wirklich schön beschrieben...

[KP97]

@fischig
Ich habe auf meinem alten Elitebook ohne EFI ebenfalls einen eigenen Kernel ohne initrd, allerdings einen 5.15.135, auch von kernel.org ohne Patches.
Ich habe darin kein bluetooth und auch sonst etwas abgespeckt, aber natürlich funktioniert USB mit allen Geräten.
Zum Vergleichen habe ich mal die config angehängt, vielleicht kannst Du daraus was entnehmen.
42008

[Livingston]

Mal meine obige Ausführung weitergedacht: Angenommen der Kernel entdeckt ein Gerät, das ihm wie ein Parallelport erscheint. Dann erzeugt er dafür o.g. "Event". Sofern udev im Spiel ist (d.h. sobald der udev-Daemon "udevd" durch ein init-/systemd-Script gestartet ist, wird dieses Event abgearbeitet. Ich nehme an, dass dann eine udev-Regel unter /lib/udev/rules.d/ oder /etc/udev/rules.d/ ins Spiel kommt, die nach dem Modul schreit.

Ohne udev passiert gar nichts, events werden nicht verarbeitet. (Ausnahme: Irgendwas ruft gegen alle Regeln die events vom Kernel ab, aber so ein Ding ist mir nicht geläufig.) Der Ruf nach dem Modul muss folglich von einem init- oder systemd-Script stammen, oder aber auf eigenem Wunsch aus /etc/modules.

Ergänzung: cups? Könnte aktiv nach bedeutsamen Schnittstellen suchen und vielleicht versuchen, sowas wie modprobe lp aufzurufen. Ist nur geraten, wäre aber auch eine Möglichkeit.

[KP97]

Tja, ich wüßte es aber auch nicht. Ich habe zwar schon viel rumexperimentiert aber noch nie ein System ohne udev betrieben. Früher mußte man die Gerätedateien selbst anlegen, das war mir aber dann doch zu abgehoben. Und ich glaube nicht, daß das heute noch jemand macht zu systemd-Zeiten.
@fischigs Fehler kann eigentlich nur von einem fehlenden Eintrag in der config herrühren, denn wenn Module nicht geladen würden, dürfte ja überhaupt kein USB funktionieren.

[Livingston]

Eine Anmerkung am Rande für fischig:
Als Freund von Devuan könnte Dich interessieren, dass dort udev nur eine leere Hülle ist, die eudev nachlädt. Dies ist ein fork von udev aus dem Jahre 2015, kurz bevor das Original unter die Fittiche von systemd geriet. eudev wird seitdem unabhängig von udev weiterentwickelt.
Die Debian-Version von udev ist soweit bearbeitet, dass sie keine Bestandteile von systemd benötigt. Gleichwohl ist die Upstream-Quelle Teil von Harry Poetterings systemd-Universum.
Zumindest kann man die Debian-Version als von systemd emanzipiert ansehen.

[KP97]

Ich glaube, ich habe diesen Beitrag mit diesem viewtopic.php?t=187033 zusammengewürfelt.
Hier gehts um Module laden oder auch nicht, da hilft meine config wenig, sorry @fischig