udev-103 läd dvb-module in falscher Reihenfolge

Hi
Ich habe gestern ein Update auf meinem Server gemacht.
Ist es nicht so, daß sich ab udev98 udev und coldplug gegenseitig blocken ?
Ich mußte Coldplug unmergen, damit udev98 upgedatet werden konnte.
Laut den gentoo-Foren, soll ab udev98 die Coldplug-Funktionalität komplett übernommen worden sein.
Lange Rede , kurzer Sinn. Nach dem unmergen von Coldplug und dem Update von udev lief Server immer noch :=)
MfG
gehlhajo

Zitat

Original von Zzam
Hallo!

Mir ist das heute passiert, nach dem Update auf das stabile udev-103 wurden die dvb-Module automatisch geladen, noch vor dem Anwenden von /etc/modules.autoload.d/kernel-2.6.

Das heißt die DVB-Module wurden bei mir in einer anderen Reihenfolge als gedacht geladen. Das verträgt sich aber nicht so gut mit sourcecaps und bestimmt auch nicht mit Sendern die anderweitig speziell an einzelne DVB-Karten gebunden sind (CA).

Am Ende half dann RC_COLDPLUG="no" in /etc/conf.d/rc.

Aber eigentlich sollte es da doch bessere Lösungen geben, oder?

Zzam

Alles anzeigen

Darüber bin ich beim heutigen update auch gestolpert. Die Methode mit dem RC_COLDPLUG sorgt leider dafür, dass z.B. auch die Treiber für den USB-Controller nicht mehr automatisch geladen werden.

Inzwischen hab ich dazu ein bischen was rausgefunden.

Man kann die DVB-Module in der "/etc/modprobe.conf" bzw. in den einzelnen Datein in "/etc/modprobe.d/" blacklisten. Bei mir wäre das z.B.

blacklist dvb-ttpci
blacklist cinergyT2

Da das "update-modules" script die blacklist-Zeilen beim Erstellen der modprobe.conf herrausfiltert und die Dateien in "/etc/modprobe.d/" ignoriert werden wenn es eine modprobe.conf gibt, muss man hier leider selbst Hand anlegen. Also entweder die Zeilen in "/etc/modprobe.conf" eintragen oder die Datei löschen, falls in "/etc/modprobe.d/" die nötigen Dateien vorhanden sind (Die meisten ebuilds scheinen die Sachen immer noch nach "/etc/modules.d" zu installieren) .

Zumindest das erstere wäre einfach mit nem Patch für vdr machbar.

ich habe gerade herausgefunden, dass ich das gleiche problem habe und das deshalb das avards plugin bei mir nicht funzt. ich habs jetzt genauso gelöst wie zzam.
wenn udev die module lädt könnte man doch vll eine udev rule schreiben, die dann die entsprechende devices anlegt. z.b.

/dev/dvb/fullfeatured/... und
/dev/dvb/budget/...

dann wüsste man immer genau, welches device welches ist. allerdings müsste man wahrscheinlich relativ viele stellen in plugins usw patchen

aber ich hoffe, man versteht die idee dahinter und vll hat einer von euch ja eine idee, wie man etwas in die richtung umsetzen könnte.

Zitat

Original von Zzam
So, mittlerweile hab ich im ~arch udev das Modul laden so verändert, dass die Reihenfolge aus modules.autoload.d beachtet wird

bahnhof! was heißt das für mich? update world und es sollte auch mit coldplug funzen?

Zitat

Original von Zzam
Sobald du die Module in modules.autoload.d einträgst werden sie in der Eintrag-Reihenfolge geladen.

das hab ich. das heißt, wenn ich mein system auf den neusten stand bringe, sollte alles klappen? oder muss ich irgendwelche overlays o.ä. aktivieren?

Zzam?

Hi,

Zitat

Original von hampelratte

das hab ich. das heißt, wenn ich mein system auf den neusten stand bringe, sollte alles klappen? oder muss ich irgendwelche overlays o.ä. aktivieren?

udev auf den neuesten Stand bringen.
mfg

danke

Ich muss den alten Thread mal ausgraben.
Seit dem Update auf udev-119 unter x86 funktioniert das automatische blacklisten bei mir nicht mehr.
Zuvor hat er sich beim Start immer schoen an die Reihenfolge in der kernel-2.6 Datei
unter modules.autoload.d gehalten.
Nun werden die Module aber wieder in einer anderen Reihenfolge geladen.

Darum meine Frage, ob dies bei jemand anderem auch aufgetreten ist und die Funktion wieder
aus udev entfernt wurde.
Wenn nein, dann hat sich wohl bei mir in der Konfiguration etwas verstellt.

Und wie lautet die neue Lösung? Ich glaube nämlich, dass ich das gleiche Problem haben werde.

Zitat

Original von hampelratte
Und wie lautet die neue Lösung? Ich glaube nämlich, dass ich das gleiche Problem haben werde.

Naja ich denke mal die neue/alte Lösung ist es, die Module einfach wieder zB in der /etc/modules.d/blacklist zu blacklisten (update-modules nicht vergessen). Zumindest bei mir lädt er dann die Treiber weiterhin in der Reihenfolge wie ich es haben will.

Zitat

Original von Zzam
Hi Frost!

Ja diese Funktion wurde wieder entfernt.

Ah, ok das erklaert das neue Verhalten.
Schade, die Funktionalitaet war naemlich wirklich sehr komfortabel gemacht gewesen.

Zitat

Original von Zzam
Nächstes Mal kannst du das mit einem Blick in /usr/portage/sys-fs/udev/ChangeLog auch selber rausfinden

Gruß
Zzam

Ups, voll in die Falle gelaufen. Jetzt habe ich es auch gefunden, steht bei Version udev-115-r3.
So weit unten hatte ich garnicht gesucht aber der Sprung bei Stable war ja von 115-r1 auf 119.
Muss ich das naechste mal gruendlicher lesen
So hatte ich bei Google gesucht und bin auf diesen Thread gestossen.
Aber danke fuer die Antwort, in der Zwischenzeit habe ich durch explizites Blacklisting der Module
das alte Verhalten wieder herstellen koennen.
Denn die Startreihenfolge der Module durch udev wird scheinbar weiterhin durch die Datei unter
modules.autoload.d beeinflusst, dies gibt er ja im Log auch richtig aus.