* On Mon, 05 Jan 2004 at 9:11 +0100, David Haller wrote:
Am Mon, 05 Jan 2004, Adalbert Michelic schrieb:
* On Mon, 05 Jan 2004 at 5:00 +0100, David Haller wrote:
IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1] [...] IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module.
Nein, warum?
Darum. *eg* [Argumente findest du unten und in anderen Mails von mir, wenn du mich ganz lieb bittest kann ich die auch nochmal explizit auffuehren]
Ich kenne die Mails. Nur lassen sich für alle Begründungen, Gegenbeispiele finden.
Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen,
Probierst Du bitte mal / mittels LVM zu verwalten oder auch blos das /-Volume zu verschlüsseln und davon auch zu booten? Ohne initrd.
Geht nicht. Zumindest wenn /lib/modules/`uname -r` auf / also auf dem LVM residiert. LVM hatte ich nur mal kurz im Test. Aber bei Bedarf, d.h. bei Zugriff, sollte [...] Dein Argument das noch uebrig bleibt ist?
Hint: Die initrd eignet sich nicht nur für Module.
Wer von LVM / ner verschluesselten Partition booten will, der muss lvm/loop (+cryptozeug)
a) fest in den Kernel, oder
b) in die initrd packen
Egal, wie LVM oder cryptoloop jetzt vorliegt: a) bevor jemand ein von LVM verwaltetes Volume mountet, sollte jemand andere die entsprechende Volumegroup mittels 'vgchange -a y' aktivieren. b) bevor jemand ein verschlüsseltes Device mountet, sollte bitte das loop-Device mit losetup aufgesetzt werden (inkl. Passworteingabe).
-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)...
Framebuffer-Treiber, der auch wieder mal wieder raus soll, weil er sich u.U. mit was anderem in die Haare kriegt?
Ok, das koennte (in der Praxis(!)) eine Ausnahme sein, ja. Gegen solche begruendeten Ausnahmen hab ich auch nix. matroxfb ist aber z.B. sauber programmiert. Da greift also der Nachsatz: wenn z.B. rivafb oder sonstwas so schlecht ist, dass es Konflikte gibt, dann sollte man den Treiber den Entwicklern um die Ohren hauen, oder den Entwicklern dessen, mit dem sich der Treiber in die Haare kriegt.
Nein. Steuere die gleiche Karte einmal mit matroxfb, einmal mit vesafb (oder wie heisst der?) an. Das knirscht, wenn beide gleichzeitig laufen.
Oder andere Sachen, die nach dem Booten verfügbar sein sollen, später aber u.U. wieder raus sollen?
Dafuer sorgt modprobe. Ich kann problemlos z.B. per 'mount /cdrom' das automatische laden von 'sr_mod + cdrom + scsi_mod + ide-scsi' anstossen, und nach nem 'umount /cdrom' problemlos die (noch nicht automatisch entladenen) Module per 'modprobe sr_mod cdrom ide-scsi scsi_mod' auch wieder entladen...
Wo also ist das Problem?
Siehe z.B. die Situation oben: / liegt auf einem verschlüsselten Volume. Verschärfend kommt dazu, daß der zum Mounten erforderliche Schlüssel in Binärform z.B. auf einem USB-Stick liegt. usb-storage soll aber trotzdem nicht permanent im Kernel rumhängen, genauso das restliche SCSI-Subsystem nicht. Du kannst jetzt entweder einen kompletten /lib/modules/ehschonwissen-Baum auf der initrd nachbauen, oder das Modul platzsparend per insmod laden. Egal, in beiden Fällen hast Du wieder Module auf der initrd. Oder: wechsle im Betrieb zwischen APM und ACPI. Beides sind Teile, deren Bedarf sich nicht am Kriterien, die in modules.conf festhaltbar sind, festnageln lässt. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at