Mailinglist Archive: opensuse-de (5499 mails)

[Adalbert Michelic <adalbert+list@xxxxxxxx>]

* 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@xxxxxxxx