[wino]

@ wino du brauchst kein branch, da wir mld gebrancht haben und so die moduleslist von 301 nicht erweitert wird

Greetz marmic

Ich hatte das etwas anders gemeint. Eventlircd wird doch auch bei MLD-3.0.1 beim online erstellen des ISO zur Auswahl gestellt aber damit kann man dort nichts anfangen. Es trägt wohl eher zur Verwirrung bei.

Deshalb mein Vorschlag das Addon zu löschen und als Branch in Precise neu anzulegen.  

MfG
wino

[wino]

Hi Wino,

ich glaube da hast Du mich falsch verstanden. Ich beziehe mich hier nur auf das Addon "vdr", welches ja im Branch natty (MLD 3.0.1) einen veränderten dvbblocker-patch erhalten hat.

Habe den Beitrag nochmal gelesen. Du  hast Recht. Im VDR Addon von MLD-3.0.1 ist noch die fehlerhafte remote.conf. Bin immer bei der 3.0.2.

MfG
wino

[MarMic]

hi jungs,

habe schon von eurer lösung erfahren -> dagegen spricht das ich nie von usb installiere.

habe nun evtl. ne "echte" lösung gefunden, aber die stellt mich immer noch nicht zufrieden. es deutet nämlich daraufhin das udev seine eigenen regeln nicht richtig verarbeitet!

meine lösung die funktioniert ist /lib/udev/rules.d/75-netgenerator... (weiss den genauen namen nimmer) zu entfernen also den link ins root unter template löschen -> neubauen -> installieren und freuen das man immer netzwerk hat.

das deutet aber daraufhin das die rule NICHT funktioniert, was mir noch mehr sorgen macht... könnten andere rules auch nicht voll funktionieren?

frage: braucht udev irgend ein zusätzliches tool, damit die rules 100% funktionieren und wenn ja welches -> was fehlt der mld

greetz MarMic

@claus, kannst du dir /lib/udev/write_net_rules mal anschauen? ich denke da muss der fehler sein (das die etwas nutzen das die mld als bb ableger anders nutzt)

edit://weitere erkentnisse
als liveboot kann man das nicht mittels udevadm trigger --action=add ausführen
das funktioniert nur wenns installiert ist -> hmmmmm
sobald es installiert ist und man mal mit udevadm monitor | grep net mitschaut
sieht man das ein add -> move ausführt und dadurch das eth device hochgezählt wird. (live nicht)

[wino]

An udev wird nichts geändert. Das funktioniert einwandfrei!

Wer Sonderwege gehen möchte, gerne, aber bitte nicht für die Allgemeinheit.

EDIT: Udev braucht kein zusätzliches Tool und die Rules funktionieren zu 100%. Die sind doch nicht von mir erfunden. Sie werden in jedem Ubuntu oder Debian so eingesetzt. Du hast ein anderes Problem mit Deiner Hardware und das sollte abgeklärt werden.

MfG
wino

[MegaX]

Nach mehreren Tests die ich durchgeführt habe kann ich sagen das es bei mir geht.

Es hatte hier nicht wie ich vermutete mit der Software zu tun sondern mit der Hardware. Installiert habe ich immer über nen USB-Stick auf meine Testplatte, der danach wieder abgezogen wurde. Nachdem der HTPC das erste mal rebootet wurde ist alles brav erkannt worden. Nach dem 2x rebooten wurde jedoch die Netzwerkkarte wieder hoch gezählt.
Habe hier dann gelesen das es bei Pit auch funktioniert und mir gedacht ich versuch es jetzt einfach mal über CD zu installieren. Gesagt, getan und es funktionierte. Das DVD hab ich dabei nur provisorisch in den HTPC reingebaut und dafür meine 1TB HDD abgeklemmt.
Als ich nach der Installation mehrfach gebootet hatte und es funktionierte habe ich das DVD dann wieder abgebaut und meine 1TB HDD angeschlossen, danach den HTPC wieder starten lassen und siehe da er zählte die Netzwerkkarte wieder hoch.

Dies legte bei wino und mir die Vermutung nahe das es irgendwo eine Datei, Datenbank oder was auch immer gibt wo Informationen gespeichert werden die aber beim Start von MLD udev noch nicht zur Verfügung stehen und es deshalb zu dem Fehlverhalten kommt.
Es liegt also definitiv nicht an udev oder den rules, sondern an dem wie MLD aufgebaut ist.

Hoffe ich habe mich einigermaßen verständlich ausgedrückt .


MegaX

[MarMic]

@claus......

auch wenn du dich nicht damit beschäftigen wolltest -> mir gehen die ideen aus. teste seit 2tagen und finde nicht wieso bei mir und megax die devices hochgezählt werden und bei wino udn pit nicht :-(

hast du nen plan?

[wino]

Hallo MarMic,

bei MegaX werden die Device nicht mehr hochgezählt. Er muss nur bestimmte Dinge bei der Installation beachten. Lese bitte noch einmal sein Post über Deinen letzten.

MFG
wino

[MarMic]

hi wino,

für mich liest es sich als wäre da nichts ok -> sobald er seine hdd wieder anklemmt zählt es hoch. und die hdd wird er ja sicherlich brauchen für aufnahmen :-)

oder ich bin echt zu blöd deutsch zu verstehen - könnte auch sein :-)

greetz MarMic

[wino]

hi wino,

für mich liest es sich als wäre da nichts ok -> sobald er seine hdd wieder anklemmt zählt es hoch. und die hdd wird er ja sicherlich brauchen für aufnahmen :-)

greetz MarMic

Die wesentliche Mitteilung steht doch im ersten Satz. <_<

Bei Dir hat es bestimmt etwas mit der Hardware zu tun, wie sie erkannt wird. Udev arbeitet zuverlässig. Man müsste hinter den Anlass für das hochzählen kommen. Die Netzwerkkarte wird bei jedem Bootvorgang als neue Hardware erkannt. Diesem Verhalten muss auf dem Grund gegangen werden. Die Rules kannst Du getrost außen vor lassen. Bei zig tausenden Ubuntu und Debian Installationen funktionieren sie wunderbar.

EDIT: Es wäre sicherlich für die Fehlerfindung günstig, wenn noch mehr User die 3.0.2 testen würden.

MfG
wino

[MarMic]

ein as habe ich noch im ärmel...

baut grade kernel neu :-)

we will see  

[wino]

ein as habe ich noch im ärmel...

baut grade kernel neu :-)

we will see

Eine vage Vermutung hätte ich auch noch anzubieten. Werden die Addons in zufälliger Reihenfolge bei dem Bootvorgang geladen oder nach einem bestimmten Muster? Wenn sie zufällig geladen würden, könnte die Netzwerkkarte jedes Mal ein anderes Device zugewiesen bekommen. Gegen diese Annahme spricht allerdings, dass udev bei drei Usern stabil arbeitet.

MfG
wino

[MarMic]

hi wino,

ich habe das hier noch gefunden -> hat aber auch nichts gebracht WEIL es das wohl nimmer gibt in kernel 3.x

Network device renaming

Sometimes unplugging and replugging a network device (like a USB WiFi card) can rename your net device each time, incrementing the number by one.

When this happens, you'll see it become wlan0, wlan1, wlan2, etc. This is because udev is adding additional rules to its rules file, instead of reloading the existing rules. Since udev watches its rules directory via inotify, you need inotify support in your kernel config:

Code Listing 3.4: Enabling inotify support in the kernel

File systems --->
    [li] Inotify file change notification support
    [li]   Inotify support for userspace

Now udev will retain proper names for your network devices.

das hätte gepasst wie die FAUST aufs auge!!!

quelle ist gentoo doku
doku

wenn ich naher zurück bin schau ich weiter ... das MUSS gefixxed werden!

greetz MarMic

p.s. vllt findet ja jemand anderes noch nen ansatz in der doku

[wino]

das hätte gepasst wie die FAUST aufs auge!!!

Das hätte aber leicht durch eine Udev-Regel gelöst werden können. Ich habe beispielsweise zwei Card-Reader an einem USB-HUB. Da unter keinem Umständen, aus naheliegenden Gründen, jedes Mal ein anderes Device zugewiesen werden darf, habe ich die unten stehenden Regeln geschrieben.

Code: [Select]

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{serial}=="Reader E6CF0D9", SYMLINK+="sky"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{serial}=="Reader C1B065B", SYMLINK+="hdplus"
MfG
wino

[MarMic]

weitere infos:

könnte das auch auf uns zu treffen?
@claus, das müsstest du mal beantworten:

Second, you might have a laptop or other device that only addresses one ethernet device at a time, and you wish it to always appear as eth0 (or whatever). Whenever you plug in a new device it will add another entry and increment the eth(n) by one, and your networking might fail on the new device if you have assigned a fixed IP in /etc/networking. The simple solution is to edit every entry that appears in 70-persistent-net.rules to have the NAME eth0. This will cause no trouble at all as long as you only run one device at a time.

You might run into the same problem after copying a system from one partition to another, or using some kinds of upgrade, or copying a file from one system to the other. The attributes of the device are not necessarily locked, and udev might decide it's not the same device. In that case, it will reassign it as eth1 and your networking fails. Of course, you can just eliminate the old eth0 entry that no longer works and edit the new one to have NAME="eth0" and your problem is solved.

The persistent-net-rules file is therefore something you should habitually check any time your network mysteriously fails. You never know for sure when udev will impishly decide to reassign the device.

insbesondere 2ter absatz

[obelix]

Hallo,

gibt es schon Ideen, wie die Implementierung von mount und umount aussehen soll? Ein Weg wäre nämlich

Code: [Select]

udisks --mount /dev/blablubb
udisks --unmount /dev/blablubb
udisks --mount könnte man mit einem udev - Event verheiraten. udisks --unmount könnte man im vdr per Menüpunkt (und damit auch FB Taste) auslösen und XBMC beherrscht das auch.

Für diese Art von Mounten wird noch

Code: [Select]

/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf
/usr/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service
benötigt. Ich habe diese erst einmal einfach von meinem Linux Mint System genommen. Nach einem Neustart von DBus gibt es beim Mounten folgende Meldung:

Code: [Select]

MLD> udisks --mount /dev/sda1
Cannot find device with major:minor 8:1: Message did not receive a reply (timeout by message bus)
Gruß

Obelix